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