数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

Posted 优云数智

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数人云架构师:微服务体系中的K8S&Mesos调度与服务发现相关的知识,希望对你有一定的参考价值。



9月10日在K8S GeekGathering Meetup上,数人云架构师保珠做了关于《K8S&mesos之我见》的主题分享,分别介绍了Kubernetes和Mesos对微服务的支撑,以下是本次分享的实录——


本次主要分享主要有以下五个方面:

  • 容器的价值

  • 微服务体系建设

  • Kubernetes对微服务的支撑

  • Mesos对微服务的支撑

  • 总结


关于容器大家可能已经理解或者正在实践使用,所以今天会讲一下容器的价值方面内容,然后是目前比较火的微服务相关:将单体应用解构成微服务后它到底是一个怎样的概念,而后是Kubernetes和Mesos在微服务方面的支撑,最后是基于以上做一个总结。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

容器的价值


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

首先来思考一些问题:


  • Docker现在已经是容器界的事实标准,原因是什么?

  • Docker和VM各自都有什么优势?


2013年,Docker就已经在国内进行发展,2015年本人首次接触Docker是在客户现场进行生产应用部署,后来在和客户分享交流中,被问及的比较多的一点是Docker和VM究竟有什么区别,以及各自的价值是什么?Docker如此之火,难道就是因为轻量化、隔离性安全性以及秒级启动这些原因吗?这些特性VM也可以通过变通的方式做到,那么Docker的价值到底是什么?


请带着这些问题,继续往下看。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

微服务体系建设


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

试想下,目前比较火的微服务是不是和Docker或者说容器的经历很相似?为什么现在大家要用微服务,它都为我们带来了什么?单体应用时用的MVC架构,金融业会把应用切分成七层,接入层、服务层等等,微服务是否还要按照这种分层架构,用了它到底是简单了,还是复杂了,是不是用了Spring Cloud、Dubbo即是微服务了?


随着应用规模的膨胀导致运维规模线性增长,如何解决:有了微服务的概念后,应用可以按照业务模块做切分,做了微服务化切割够,一个小团队去管理开发一个服务,但随之而来的问题是,以前10个系统,5个运维就可以完成任务,使用微服务后可能会变成每个系统有几十个服务,部署的复杂度、团队之间的沟通协调、线上问题追踪,版本控制这些问题需要一些解决办法。


微服务的所有服务之间都是平等的关系,每个服务内部还可以遵循之前的分层架构。


当把系统做了模块化切分后,用Spring Cloud或者Dubbo框架去构建系统,虽然感觉上这就属于微服务的范畴,但随着对于这个体系的了解,其实会发现还远远不够。


〓  微服务体系建设


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

为什么说微服务不是一个简单的框架而是一个体系,因为一个框架并不能解决微服务给我们带来的所有问题,如前面所提到的,其实还有很多,下面是在项目中遇到的一些体系方面建设的罗列,供以参考:


服务化框架:要解决的是服务之间调用的多通讯协议支持,数据交互的数据结构支持。


服务注册和发现:完成服务切分后,服务之间完成解耦,通过服务注册中心对服务统一管理,调用端去调用。


统一配置管理:不同环境如开发、生产、测试等环境的配置肯定不同,如果没有做出相应的改变,那么后续带来的修改以及升级问题是不可想象的。


API网关:服务被拉平后,身份验证、监控、负载均衡、缓存、请求分片与管理、静态相应处理。


监控报警:监控报警之所以重要的原因是因为之前做系统时,觉得开发测试完成后即可上线,但在金融行业并不如此,监控通过提高发现问题的时效性,更早更快地发现问题,从而保证系统稳定性。


文档管理:不同服务做切分后,按直接沟通模式,团队间的沟通成本会很高,若切分了四五个服务还好,都互相知道,但切分了几十个甚至上百个服务,所开发的服务可能都不知道水在调用,因此需要通过契约管理接口,通过文档管理将自己的API开放在一个通用的团里平台上,如Swagger,方便调用查阅。


任务调度系统:在系统当中,除了在线实时交易通过服务之间的调用去做,还有一些金融行业里面跑批的任务,比如日切,凌晨2点要统一跑批,需要任务调度系统去执行,若用其他系统,随着服务的膨胀,机器主机数量增加,后续的管理会产生很大问题。


风控平台:如果有接口是开放的API要被外部调用,不止是在防火墙内部调用,此时如果有人进行攻击,此系统可以帮助保持稳定性。


测试平台:更多是把微服的整个系统:包括接口测试、单元测试、以及性能测试都在一个平台统一做好,目的是缩短微服务的发布周期,后续做持续集成时,才能提高交付效率和时间,更加敏捷。


持续集成/发布:用了微服务后,通常都会采取敏捷的方法,比如两周、四周做简单迭代,中间的版本也非常多,每个版本的发布都必不可少要做一次回归测试,工作量比较大,如果仍然由人工进行,会很艰难。


通过以上对于微服务体系进行了一些简单的理解之后,现在就可以反过来回答前文中所提到的容器(Docker)价值问题——


Docker和VM的区别,结合微服务在做持续集成/发布时,Docker更具有优势,但这也并不是说有了Docker就没必要再去采用VM,到底是将Docker部署在主机上还是部署在VM里,其实没有一定的答案,它们各有千秋,需要根据自身的实际情况去把控。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

Kubernetes对微服务的支撑


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现


〓  编排


单体应用微服务化以后,服务之间必然会有依赖关系,在发布时,若每个服务都单独启动会非常痛苦,简单地说包括一些登录服务、支付服务,若想一次全部启动,此时必不可少要用到编排的动作,这里有一个子项目:Kompose将Docker Compose编排文件无痛发布到Kubernetes上,这是个简单的Docker Compose文件,发布到一个Dedis集群,一个前端。执行kompose convert –f docker-compose.yaml即可。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现


〓  资源调度


调度是编排工具的核心,上图可以看到Kuberenetes在调度方面的框架:


  1. 用户通过Kuberctl提交运行Docker Container(Pod)的请求

  2. Api Server把请求存储在Etcd

  3. Scheduler扫描,分配资源

  4. Kubelet得到调度要执行的任务,并在本机执行生成容器(Pod)



后面会对比一下Mesos的调度实现。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现


〓  Statefulset


之前和客户提到微服时,都会说到应用微服务化以后,如何迁移上云的问题,这是很重要的动作,一般会给出的相应的建议:首先要将所有应用无状态化,规范这样的要求是因为服务状态有坑在其中。


Kubernetes的Statefulset可以发布有状态服务,需要满足以下要求:


  • Pod的存储必须通过Persistentvolume Provisioner基于Storeage提供

  • 由Headless Service生成Pods的唯一网络标识

  • Statefulset的升级是一个手动的过程


总体来说,它为了实现有状态的服务在这些前提下,还会有一些复杂性在其中。


之前有人提问数据库跑在容器里还是用主机服务,包括数据库里的分库,都不是容器所关注的问题,建议数据库服务先不做容器化,因为数据库层面,更多是对IO的分流,在它的查询,索引都是IP请求比较多。分库分表,分布式事务是在应用层面解决的,同样也不是容器所关注的,Docker接触的更为底层,因为是一个OS。



数人云架构师:微服务体系中的K8S&Mesos调度与服务发现


〓  服务发现


关于服务发现,上面提到微服务后,服务数量剧增,端到端的模式已不再适用,此时就需要做服务发现,有了服务发现和负载均衡,它可以把服务之间做一个解耦,可以提升升级方面的相关问题。


Kubernetes的服务发现有两种模式:


第一种:通过环境变量的方式,Pod创建是在环境变量中写入Serviceip和Port。


第二种:DNS,Kubernetes集群内置DNS服务器,Service创建成功后会在DNS服务器里导入一些记录,想访问某个服务,通过DNS服务器解析出对应的IP和Port,从而实现服务访问。


Sprin Cloud框架下可以考虑用Kubernetes的服务发现替换Eureka。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

Mesos对微服务的支撑


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现


〓  资源调度


数人云之前所做的平台都是用Mesos,Kubernetes和Mesos各有优势,数人云将产品体系升级为企业应用架构管理《EAMS》体系后,也已经全面支持Kuberntetes。


从Mesos调度的角度去看分为两层:资源调度和应用调度。资源调度主要负责系统资源调度管理,应用调度有Framework管理,Framework可以自定义,Mesos除了调度容器外通过不同Framework的实现,还可以调度Hadoop等。


资源调度的过程,Master节点通过ZooKeeper实现高可用,Slave同Master Leader交互更新资源变化,调度请求由Framework发起(如Marathon,Swan),Mesos Master把可以适配的资源Buffer返回给Framework,Framework下发Task到返回的Slave上,Slave执行Task,并跟Master Leader更新资源Buffer。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现


〓  服务发现


服务发现Mesos本身走不了,同时Marathon也并不提供。



说到这些域名,它和Kubernetes一样,直接解析的话,可以具体定义到某一个集群、应用、用户都是可以找到的。


数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

总结


Mesos和Kubernetes在资源调度方面都很优秀,主要矛盾在于容器调度,结合上文提到的微服务,Kuberntes略有优势,因为会做很多负载均衡,集群管理、有状态数据的管理,帮助消化很多东西。Mesos的优势在于比较灵活,扩展性强。






活动推荐:


9月23日,紫禁之巅,江湖号召,数人云Meetup联合又拍云OpenTalk,邀请到技术界四位大牛齐聚京城,为大家深刻解读微。点击文末阅读原文,即可报名活动。



☟  阅读原文,报名微服务活动

以上是关于数人云架构师:微服务体系中的K8S&Mesos调度与服务发现的主要内容,如果未能解决你的问题,请参考以下文章

阿里云架构师梁旭:MES on 云盒,助力客户快速构建数字工厂

PPT | 从架构到组件,深挖istio如何连接管理和保护微服务2.0?

PPT | 从架构到组件,深挖istio如何连接管理和保护微服务2.0?

架构师图谱·微服务&消息队列篇

云原生&k8s的架构及基本组件原理

架构师零基础到精通——微服务体系