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

[dataman]

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

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

高可用

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

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

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

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

微服务

{<4>} 微服务我们也从头说起。微服务最初是一个 Web ，一个 DB ，按照第一个方式走，顶不住的时候开始加 Cache 。这样的架构很有可能变成一个单体，但是内部还是不能去松耦合，虽然加了 Cache 还是有依赖，发展到最后，我们知道构建一个高可用或者智能的架构其实是一个想象中的过程。实际上需要的模块应该是一个整体，模块里面的东西应该能够水平扩展，做一些精细化的运营，这才是微服务的一些比较核心的理念。

{<5>} 第三个案例里，首先要分层，每一层都是可以支撑的，其运营的难度不会很高，底层 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 本身有自己的容灾和调度策略，我们做了一个自动试错三次的上限，除了报警以外，不允许它再扩了。

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

{<6>} 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 ，我们可以分网关给它，来做接入。

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

总结

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

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

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