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

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

本次主要分享主要有以下五个方面:
– 容器的价值
– 微服务体系建设
– Kubernetes对微服务的支撑
– Mesos对微服务的支撑
– 总结

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

容器的价值

Markdown

首先来思考一些问题:

  • Docker现在已经是容器界的事实标准,原因是什么?
  • Docker和VM各自都有什么优势?

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

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

微服务体系建设

Markdown

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

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

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

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

〓 微服务体系建设

Markdown

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes对微服务的支撑

Markdown

〓 编排

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

Markdown

〓 资源调度

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

  1. 用户通过Kuberctl提交运行Docker Container(Pod)的请求
  2. Api Server把请求存储在Etcd
  3. Scheduler扫描,分配资源
  4. Kubelet得到调度要执行的任务,并在本机执行生成容器(Pod)

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

Markdown

〓 Statefulset

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

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

  • Pod的存储必须通过Persistentvolume Provisioner基于Storeage提供
  • 由Headless Service生成Pods的唯一网络标识
  • Statefulset的升级是一个手动的过程

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

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

Markdown

〓 服务发现

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

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

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

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

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

Mesos对微服务的支撑

Markdown

〓 资源调度

数人云之前所做的平台都是用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。

Markdown

〓 服务发现

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

数人云自己做了一个开源项目:Swan(GitHub地址:https://github.com/Dataman-Cloud/swan),可以通过Swan Proxy做服务发现和负载均衡,Proxy是跑在Slave上,它启动容器后,注册的内容是nginx-demo.default.xcm.dataman-mesos.bbklab.net. 0 IN SRV 0 100 31000 0.nginx-demo.default.xcm.dataman-mesos.bbklab.net 里面会把定义的一个域名,包括权重,端口,的DNS注册方式,即使不用Swan DNS,用外接的DNS都可以通用,因为注册内容是SRV标准。

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

总结

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

 

来源:  https://www.kubernetes.org.cn/2735.html