运维工具链概览

在看过微服务整体架构后，我们来讨论下架构的各个层次中，本书所选用的技术栈。

与前面类似，我们依然自底向上讨论。

运维工具链选型

• 基础设施层：对于绝大多数的中小公司，且无强烈的数据保密需求，我强烈建议使用云主机。
  • 运维成本更低。想对机器加64GB的内存，如果自运维的话跑去机房、断电、拆机器、插内存，半天过去了。如果采用云主机，就是点点鼠标，重启一下的事情。
  • 弹性更大。老板一拍脑袋，明天要上线大促，预估要扩容10倍。只有一天时间，是不可能完成100台机器的采购、上架、配置的。大促结束后，流量回归到平常情况，这100台机器还要继续空转烧钱么？如果采用云主机，这些就是点点鼠标，甚至是几个API调用就可以搞定的事情。
  • 平均稳定性更高。内存ECC故障、硬盘坏道、RAID卡故障，这些都是自运维服务器时代的家常便饭。若采用云主机，就可以很好的避免这些烦恼。常见的大厂云主机，都提供了至少3个9的在线时间保障，与运维服务器相比，平均稳定性更高。
• 运维平台层之容器管理：前面已经提到，微服务需要借助容器技术才能“顺利启航”。目前主流的方案有：docker加脚本、swarm集群、Kubernetes集群、Marathon集群。本书选用Kubernetes集群，它内置的功能完全可以满足”容器的监控、调度、管理“。在这里我们采用排除法，说说为什么不选用其他几个方案。
  • docker加脚本：2014年Docker刚刚兴起时，还没有集群管理的解决方案，多数公司采用了这类架构，在不同物理机器上，通过自动化脚本来启动不同的容器。这种方式简单直接，但是当集群规模扩大后，运维非常困难。此外，这种方式很难解决自动网络配置、自动调度、容器数据迁移等很现实的问题。
  • swarm集群：swarm集群方案是Docker公司于2014年末推出的容器集群技术方案。尽管swarm是Docker公司的“亲儿子”又是市场的先发产品，但swarm很快被后起之秀Kubernetes超越。时至今日，从的新功能跟进、社区活跃、文档完善程度等方面，都弱于Kubernetes。更重要的是，借助CNCF基金会的影响力，Kubernetes已经成为了事实上的容器集群解决方案，GCE、AWS等云平台，都原生支持Kubernetes集群。在2017年，Docker公司在自己的商业化产品中直接集成了Kubernetes，标志着swarm项目的全面落败。所以在本书中，我们也不会选用swarm集群。
  • Marathon集群：Marathon是构建在Mesos集群上的一套容器集群管理软件。想使用Marathon,先要部署一套底层的Mesos。对于大型公司，特别是已经部署了Mesos的Hadoop集群的公司来说，这种搞法可以提升机器复用程度。但对于中小规模的企业而言，Mesos + Marathon多少有一些“”高射炮打蚊子“的感觉。此外，虽然Marathon在大规模机器管理上有比较多的经验，但并未在容器编排上投入太多新功能，更像是借助容器的概念为自己”造势”。综上所述，我们也不会选用Marathon集群。
• 运维平台之持续部署系统：部署前需要先构建，本书的微服务开发选用Spring Boot框架，在构建方面，我们使用Gradle(之后会阐述原因)。在持续部署方面，我们选用老牌工具Jenkins，通过一些插件和配置完成全套的持续部署。
• 运维平台之部署版本管理系统：前面已经提到，我们将采用容器技术。本书采用自建私有Docker仓库的方式，完成容器的镜像工作，并使用它作为部署版本的管理系统。

本书的主线是微服务的架构及开发。为了保证这一主题的的稳定和连惯性，我们将上述运维工具链的使用单独抽提出来，在《运维工具链》一章中介绍上述内容。