老肖实录分享 | 基于 Mesos 打造高可用微服务系统实践

本文是数人云CTO肖德时在2016全球运维大会·上海站上的演讲实录。干货连连！走过容器大会探讨完热门的一容器一IP，接着来运维大会随小数一块儿来看一下如何基于Mesos打造高可用微服务架构吧：）

很高兴在这里和你们分享一下如何用开源软件打造一个高可用以及微服务的架构。Mesos是Apache的一个开源项目，其宗旨是像一台电脑同样管理整个集群，它源于Google的Borg系统，有一套cluster管理平台对无数台机器进行管理。Twitter、Airbnb的服务器及苹果电脑的Siri大数据应用都是跑在Apache Mesos上面，基于Apache Mesos系统咱们也作了一个轻量级PaaS平台。

高可用

什么是高可用？将概念缩小到维基百科的简单定义，能够看到它有以下几个特征。第一，消灭单点问题，系统要把单点支持住；第二能冗余，HA的架构；第三，快速检测，失败可以自动切换。

一开始作这套系统时，咱们想到Load Balance，把系统作一个负载，这样有了HA的架构，可是里面Load Balance自己又是一个单点。你们可能会想把Load Balance作成cluster，用DNS的方式去作，可是DNS自己要来回切，切两个IP之间的轮换，这个自己依然有单点的问题。以一个单数据中心的角度来讲，最好有一个能挑的IP， IP最好是固定的。而后在里面去作Load Balance的Proxy，底下是App Server，再去切换，这样就是一个高可用的架构不断的演进过程。

这个过程里面会涉及到几个问题，咱们来看一下Mesos系统是怎么解决这些问题的。首先，在任何高可用的架构里面，锁是必须的，可是高可用在当前的发展过程当中，scaling的过程必定要作分布式系统，因此对于锁的要求就比较多。第二，要有本身的控制节点，即Mesos的节点，它主要是控制这些资源的提供，这是它的一种基本的架构，实际计算节点在下面，这些Slave节点的特色是即便进程死掉了，也保证任务必定能运行起来。

这也是应用跟集群之间松耦合的过程，Mesos是很是成熟的架构，能够帮助企业实现高可用的架构。

微服务

微服务咱们也从头提及。微服务最初是一个Web，一个DB，按照第一个方式走，顶不住的时候开始加Cache。这样的架构颇有可能变成一个单体，可是内部仍是不能去松耦合，虽然加了Cache仍是有依赖，发展到最后，咱们知道构建一个高可用或者智能的架构实际上是一个想象中的过程。实际上须要的模块应该是一个总体，模块里面的东西应该可以水平扩展，作一些精细化的运营，这才是微服务的一些比较核心的理念。

第三个案例里，首先要分层，每一层都是能够支撑的，其运营的难度不会很高，底层DB关了，可是由于有容灾的DB，上一层不会受到影响。Mesos高可用的架构是一种具体的实现方法。第二，微服务咱们能够混合部署，不须要关心部署在什么地方，只要把有状态的应用变成无状态，撒在集群里面，让充分的计算资源来支撑业务，有状态的业务仍然须要专心管理，可是有状态和无状态之间能够精心地设计。基于Mesos作这种微服务的架构，用混合部署的方式支撑业务，消灭单点，支持容灾，还能在出现task出错以后自动切换。这是分布式架构应有的一些特性，也是咱们对微服务的一些理解。

系统实践

数人云是一家创业公司，咱们利用了一些当前比较时髦的一些技术，好比说容器。 Mesos自己是一个集群系统，但其部署仍较复杂。你们都但愿运维可以标准化，通常想到的是Ansible和SaltStack。

Docker标准化镜像很是方便，因而咱们用Docker的方式把这些组件都标准化，打成image，经过一个DSL的文件撒下去，也一样实现了这样的集群。复制之后，下次再也不须要配置，按照这个方式快速地执行。Ansible和Salt也是同样的过程，那么选择这套方案的缘由是，咱们认为image的管理比对脚本的管理更方便一点，有仓库和版本的概念。咱们也利用了Docker的一个先进的理念——应用中心导向的build、ship、run，能把全部的配置信息都用一个DSL写成一个Json文件下发下去，经过控制器在所有的机器上自动部署。基于Linux自己的四层的路由IPVS进行分化。咱们不用Docker全部的特性，只须要其deliver的特性。

刚才咱们混合部署了一套微服务的架构，但真正把它部署下去，监控起来也是很是麻烦的。由于每个小的App都有本身的性能的瓶颈，也有本身的指标，如何把它们汇总起来是一个问题，好比说你的十个App，每个都有本身的指标，撒在不一样的机器上，若是按照正常的模式，原来监控的每个都要监控，而后作汇聚，这与以前Mesos用一台电脑管理资源是相违背的。

其实咱们并不关心每个节点上App运行的性能，咱们须要的是汇总的性能。一个比较好的方式是经过API网关，内部的交互彻底经过这种Restful的API网关来去控制。没有达到性能指标，就把它杀掉换在别的机房运行，对外提供统一的定义的这个指标，用网关控制这个指标，咱们用的是eBay的proxy。最简单的方式能够用HA proxy去作，可是fabio用go语言来写，更符合咱们数人云的语言技术栈，因而选择它作二次开发，控制整个API请求的指标还有响应速度。Mesos自己有本身的容灾和调度策略，咱们作了一个自动试错三次的上限，除了报警之外，不容许它再扩了。

这种方式总体上把微服务全部模块的组建、全部组件服务的质量都获得了一个可量化的指标。所以能支持多少个请求都是能够快速知道，也是可控的，不需再作实时的评测。正常运营过程当中，会在事前作一些压测，但这个压测是理论值，生产环境中业务的质量是须要有一个控制，一个总闸。这也是原来微服架构里面，你们比较容易忽视的地方。

Mesos是一种通用型的架构，由于出来的比较早，当时使用的一致性的锁是Zookeeper。对于分布式架构，还有其余比较优秀的组件，好比Consul，etcd，这些算法自己是一个精简的算法，并且有很是良好的支撑分布式的锁的概念，Apache Mesos也支持这方面功能，咱们以为彻底不须要去选择Zookeeper，并非说它很差，而是一个精简的过程。

在使用Mesos的过程当中，Mesos自己是提供一个资源池，想使用它的时候须要一个入口。咱们基本上按照Mesos推荐的Framework，这里推荐的是Marathon，用的自己是Scala语言写的一套系统， Mesos自己的组件已经由原来简单的protobuf rpc的交互转变成Restful API，开发一个调度APP或者Framework已经再也不须要mesos依赖库，如今彻底能够经过HTTP API的去操做它，所以咱们彻底能够本身去作开发。Mesos的不少特性，例如针对统一的容器管理，不只仅是针对Docker，Cgroup也支持，GPU也能够管理，将来会支持虚拟机。然而它不少特性咱们想用可是用不了，没有这种支持，所以咱们考虑在这方面作开源的项目，把Mesos的特性真正发挥出来。

众所周知，Twitter、Airbnb以及Apple在使用Mesos的时候，都是使用自研的Framework调度Mesos的资源。分布式系统里面最重要的是网络，它支持了当前最流行的CNI容器化网络接口。由于这种网络是池内部的网络，跟外界的网络是能够隔离的，所以这个网络能够动态扩缩，也是当前比较时髦的语言， SDN比较推崇的一种技术。它是一个Json定义接口，对接网络的结构，好比DHCP，咱们能够分网关给它，来作接入。

在用这套系统的时候，会看到底部是Mesos的池，上面的机器有API网关，这个网关是一个总控，把应用经过这个网关切入，利用这些资源去作资源的统一控制，结构是松耦合的过程。上面全部的状态经过一个Consul分布式的锁，进入你的状态，相似于无状态的一个平台，能够部署多套，下面经过锁的方式控制schedule，所以它也是一个分布式的平台，这就是咱们具体的一个参考实现。

总结

总结一下。第一，咱们认为Mesos作高可用的分布式的架构是靠谱的。第二，微服务的架构只是一个理念，它有各类各样的方式，这种混布的架构方式并非神话，内部并非如你们想象那样拆成碎片，往里面一放就能够了，它是一个系统工程。你能够在业务层面上去控制API网关，治理下面微服务的使用质量，能够可控扩缩微服务的架构。

第三，关于DevOps，运营这套系统不能期待它百分百可控，仍是要靠自研，把它作得更好，开源软件才能发挥其真正的做用，这样整套系统才是完整的，能够容灾，没有单点，符合当前的微服务架构的服务设施理念。咱们数人云最近也开源了一个容器管理的开源项目 Crane，以后会开源更多的基于的Mesos的项目，欢迎你们关注，谢谢你们！

最后隆重推荐一下孙宇聪老师翻译的《 SRE ： Google 运维解密》，小数已经私藏了好多本啦，这个秘密小数只悄悄告诉你，从此它会在咱们活动中做为奖品出现哦！