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

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

• 容器的价值




• 微服务体系建设




• Kubernetes对微服务的支撑




• Mesos对微服务的支撑




• 总结

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

容器的价值

首先来思考一些问题：

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




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

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

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

微服务体系建设

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

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

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

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

〓  微服务体系建设

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes对微服务的支撑

〓  编排

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

〓  资源调度

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

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




2. Api Server把请求存储在Etcd




3. Scheduler扫描，分配资源




4. Kubelet得到调度要执行的任务，并在本机执行生成容器（Pod）

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

〓  Statefulset

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

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

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




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




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

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

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

〓  服务发现

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

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

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

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

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

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。

〓  服务发现

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

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

总结

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

活动推荐：

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

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