Docker在沪江落地的实践

 黄凯 分布式实验室 

容器化技术在过去的几年甚至到现在都是一个十分红火的技术，每一个对技术有些追求的公司对容器或多或少都有些蠢蠢欲动与研究，我厂也不例外。今天我们就来谈谈Docker是如何在沪江落地的。

Docker与微服务

微服务与Docker都是着简单轻量的代言，以至于人们说起Docker便会联想起微服务。但其实两者没有本质的关系，Docker可以不依赖于任何语言、框架或系统，而微服务负责拆分业务，解耦复杂应用。由于Docker相比VM更加轻量，更加灵活，正好符合了微服务的一些原则，所以大家经常使用Docker来部署微服务。

沪江在使用Docker前，首先对业务进行了拆分，把传统服务拆分成微服务后再实践Docker部署。今天我以沪江的课件云为例，先讲解一下服务的拆分遇到的问题。

微服务的颗粒度一直是众多架构师探讨的问题之一，在众多的讨论中，我比较欣赏微服务教父Sam的一个定义：微服务是一个能够在两个星期内重构完成的小程序。所以在拆分课件云业务之初，就以两星期原则为拆分依据，分为下图这样的结构：

在图中，最底层由分布式存储与容器云组成，容器云使用Docker+Mesos+Marathon的组合，相信大家对这套组合不会陌生，之后会继续介绍为什么使用这套组合以及使用中遇到的问题。中间层便是拆分出的业务微服务，目前这个项目线上已有8个微服务。最上层是两个客户端软件。

编排工具的选择

如果只把Docker作为一个部署工具实在是太浪费了，Docker的优势完全没有发挥出来，通过Docker来编排微服务才是使用Docker的正确姿势，这里不得不说一说Mesos和Kubernetes的一些故事。

如今的docker编排呈现了三大阵营，Mesos+Marathon，Kubernetes和Docker Swarm。Swarm还处于发展阶段但势头很猛，Kubernetes和Mesos都源于google的brob项目但侧重点不同：Kubernetes侧重于企业级集成，你能想到的方案，他都能通过自身组件集成，而Mesos专注于资源调度和管理。

在这里我们主要介绍Kubernetes和Mesos之争，由于两大阵营的激烈争夺，大的互联网企业自然选择了Kubernetes这样潜力十足又非常周到的企业级产品，虽然K8s目前网络，存储的解决方案还不完善，但互联网巨头不怕，他们有的是技术团队去修改源码，去贡献社区。这使我们这些中小型互联网企业面对了选择的难题。

我们最好的方式就是对两者都进行尝试。通过寻找各个框架配合的方案，找到最符合我们需求的方案。经历了99 81难后，我们给出了下图的比较：

Mesos由于历史悠久，性能不差，组合方便成为了我们最终的选择。

Docker网络是我们遇到的最头疼也是最迫切的问题之一。站在巨人的肩膀上，业内成熟的解决方案有Calico，flannel，docker vxlan，weave，Macvlan等。Calico对物理网络侵入交多，weave性能过差暂时不考虑，所以矛盾集中在flannel和docker network的选择上。网上也有张著名的性能比较图。

我们针对Flannel和Docker Network也进行了性能的比较后发现，在大并发的情况下，Flannel网络cpu占用过高，这是因为Flannel基于大三层对tcp请求进行了封包与拆包导致，Docker network虽然也需要封包拆包，但其过程发生在内核中，性能要优于Flannel。具体网络拓扑见下图：

Docker Network方案是由Docker公司开发的，对Docker本身有足够的支持。在网络隔离性上也有一定的控制，比如可以控制两个Overlay网络之间互访。在效率上由于使用了内核级分包拆包，速度和资源消耗要远小于Flannel。

Docker Network的使用过程中，我们也遇到了许多的坑，例如内核的版本或Docker版本过低导致网络不稳定等，建议使用这种网络方案的同学把linux内核升到4.4，Docker版本升到1.11以上。对于将来，我们计划研究一下Calico网络，毕竟有人称Calico是产线上最好的网络解决方案。

业务对于存储的需求，大致有两点：日志和共享存储。这两点恰恰反应了Docker本地存储和网络存储的解决方案。在存储上Docker和Kubernetes有一定的分歧，Docker公司比较推行Volume-driver的理念，即所有的存储都是驱动，本地存储和网络存储只是对应的驱动不同而已。

而Google的Kubernetes则认为存储本身应该和Docker甚至容器是隔离的，即任何存储都是卷（volume）。不管是本地存储还是网络存储，应该都是事先建立好的，在容器看来都只是一个卷，通过统一的驱动挂在即可。

我们属于墙头草派。结合两者的特点，首先创建两种存储卷，再通过Docker的卷驱动进行挂载。其结构如下图所示：

如果一个线上应用没有监控手段来保证运行的正常，结果是十分可怕的。曾经一位对容器化感兴趣但非常犹豫的伙伴对我说，我非常希望采用Docker的方案来改变我们的臃肿并且部署麻烦的应用，这看着十分方便和高效。但真上线我不敢啊，当遇到紧急情况，如何看到应用的状态？当遇到系统崩溃，docker容器已经消失，如何能回溯问题？这两个问题也引起了我们的思考，归纳起来是两点问题：监控与还原现场。

目前Docker的监控方案有很多，例如Google的cAdvisor，Datado，SoundCloud的Prometheus等，我们选择了使用Mesos自带的Metric做为我们监控的元数据。其原理是：任何使用Mesos Framework启动的任务，都能通过Mesos的Matrics API获取到。通过这一特性，Docker的cpu、内存、磁盘利用率就能监控了。

至于还原现场，很多公司都各显神通。我们对此需求不是特别强烈，所以没有研究。

对微服务进行扩容是相当麻烦的事。微服务本身部署数目众多，扩容也不会只扩容几个Instance，如果是人工运维的话，需要对上层的LB逐一的修改配置。这肯定不符合工程师们“懒才是推动技术发展动力”的观念，如何对微服务进行自动扩容成为了我们新目标。

在沪江，我们的解决方案是使用Mesos Consul、Consul、Consul Template等一些列配套工具。当扩容的容器通过Mesos启动后，Mesos Consul（Cisco开源）会自动读取分配的IP和port注册到Consul（一个专业服务注册软件）中。我们再用Consul Template（一个官方定时读取Consul内注册服务的组件）对Nginx进行改造，每次得到更新的微服务信息后更新Nginx配置。通过这样一套辅助软件，我们便可以实现自动化的扩容了。

当应用服务的压力达到一定的阈值后，自动扩容程序便会通过Mesos Metrics检测到，同时通知Marathon根据既定的策略进行扩容。

当应用服务的压力减小后，扩容程序也能进行自动缩容，只是会根据策略选择缩容方式，比如设定当应用服务压力减少到20%后，凌晨2点开始减小容器个数。

通过上述方案，Docker终于在沪江落地了，那它的结果如何呢？下图是我们对使用前后做的对比图：

可以看出，使用Docker相比传统应用，可以部署更多的应用，QPS增加，资源降低，效果十分明显。

Docker与微服务虽然时常博得大众的眼球，但实际操作落地却并不容易。沪江并没有走大厂Kubernetes的技术路线，而是采用更稳定、更灵活的Mesos+Marathon编排也是结合了企业自身的技术能力和业务场景。

我们虽然根据自身需求，暂时解决了Docker容器编排、网络、存储、监控、扩容等相关问题，但这并不是终点，我们将持续对Docker容器应用进行研究。这就是我今天所有的分享，感谢大家倾听。