部署微服务

部署一般涉及到两个互相关联的概念：流程和架构。

• 部署流程包括一些由开发人员和运维人员执行的步骤，以便将软件投入到生产环境。
• 部署架构定义了该软件运行的环境结构。

下图说明了重量级、长生命周期的物理机已被越来越多轻量级、短声明周期的技术所抽象：

下面结合自己的工作经历，回顾下部署流程和架构的演进路线：

• 早先开发人员将代码和配置脚本扔给测试人员，测试通过后，在提交代码和生产环境的配置给到运维人员，由运维人员进行手动或者借助脚本的半自动化部署。此时运维人员一般要登录应用服务器的控制台（例如Weblogic、WebSphere)来部署应用程序，他们会非常关心这些机器，就像对待宠物一样。
• 后来很多项目甚至电信核心的系统都用开源的轻量级的Web容器Tomcat替换掉昂贵的应用程序服务器，同时虚拟机开始取代物理机。
• 在后来就是采用CC或者Jenkins之类的持续集成工具应用于开发、测试和生产环境，小项目团队一般自行负责生产环境的部署，从工具流层面逐渐实践DevOps理念。
• 最近一般大型的系统慢慢采用容器化部署方式，部署到kubernetes环境下。此时容器是一种虚拟机之上的更轻量级的抽象层，它们被视为一次性的资源而不再是宠物，更像是奶牛，出现故障或者使用过后，它们就被丢弃和重建，而不是重新配置。

最近一些公有云厂商提供了基于kubernetes的更轻量级的Serverless部署平台，使得租户不再关注购买了多少台云主机，不再需要自己构建kubernetes环境，只需要按厂商提供的规范、开发接入并部署，后续的运维、监控都无需介入。

部署流程和架构的更新换代，与微服务架构的日益普及几乎同时发生，这绝非是一种巧合。应用程序可能会有数十种语言和框架编写的服务。因为每个服务都是一个小应用程序，这就意味着在生产环境中有数十个应用程序。因此，让系统管理员手动配置服务器和服务已不再可行。如果要大规模部署微服务，则需要高度自动化的部署流程和基础设施。

下图显示了一个生产环境的抽象视图:生产环境使开发人员能够配置和管理他们的服务。使用部署流水线部署新版本的服务，以及用户访问这些服务实现的功能。

生产环境比较实现四个关键的功能：

1. 服务管理接口：使开发人员能够创建、更新和配置服务。提供可供命令行和图形部署工具调用的Rest API。
2. 运行时服务管理：确保始终运行着所需数量的服务实例。
3. 监控：让开发人员能够了解服务正在做入门，包括日志文件和各种监控指标。如果出现问题，必须提醒开发人员。也就是所谓的可观测性。
4. 请求路由：将用户的请求路由到服务。

1 部署模式

下面讲解5种基本的部署模式，每个模式在特定的时期都是阶段性正确的。其中所说的不足也仅表示站在今天的技术角度去看而已，不存在优劣之分。

1.1 编程语言特定的发布包模式

对于特定语言的应用程序，都需要安装必要的运行环境。例如JDK或JRE。

下图说明了理想情况下，部署流水线自动构建可执行的JAR文件并将其部署到生产环境中。在生产环境中，每个服务受理都是运行在安装了JDK或JRE的计算机上的JVM中：

服务实例通常是单个进程，可以采用一台主机一个服务实例的方式，它的好处在于：

1. 服务实例之间的隔离；
2. 不会又资源的需求或者版本依赖之类的冲突；
3. 单个服务只会最大化地消耗本地机器的资源；
4. 可以直接监控、管理和部署每个服务实例；

当然这种方式会导致资源利用率不足，此时可以采用同一台计算机上部署多个服务实例：

也可以在单个进程中运行多个服务实例。例如下图中单个Tomcat上运行了多个Java服务：

当然这种多实例部署的方式，其优缺点刚好和一台主机一个实例的相反。

优点

• 快速部署:将服务复制到主机并快速启动它。对于Java语言编写的服务，只要复制Jar或者War文件。对于Go语言的，只要复制可执行文件。在任何一种情况下，需要通过网络复制的字节数相对较小。

  此外，启动服务耗时也较短。如果服务运行在自己独占的进程，则启动它。如果在同一个Web容器中部署了多个实例，则可以将其动态部署到Web容器中，或重启Web容器。通常情况下，启动速度都较快。

• 高效的资源利用率:多个服务实例共享机器及其操作系统。若干多个服务实例在同一进程中运行，则资源利用率更高。

不足

• 缺乏对技术栈的封装:运维团队必须了解部署每个服务的具体细节，例如不同的语言和框架，特定的版本等；开发人员与运维人员需要分享这些细节。这种沟通的复杂性增加了部署期间出错的风险。
• 无约束服务实例消耗的资源：一个进程可能会消耗机器的所有CPU或内存，争用其他进程和操作系统的资源。
• 在同一台计算机上运行多个服务实例时缺少隔离:行为不当的服务实例可能会影响其他服务实例。
• 很难自动判断放置服务实例的位置：每台机器都有一组固定的CPU、内存等资源，而每个服务实例都需要一定的资源。如何以一种有效使用机器而不会使它过载的方式将服务实例分配给机器非常重要。每个机器应该部署多少个服务实例，需要人为判断，缺乏自动处理能力。

1.2 虚拟机部署

将服务实例打包成虚拟机镜像，然后按一台虚拟机一个服务实例的方式部署：

虚拟机镜像一般由构建流水线构建而来，比如采用Packer工具，它是一个现代的虚拟机镜像构建器，支持多种虚拟化技术，包括Amazon EC2, CloudStack, DigitalOcean, Docker, Google Compute Engine, Microsoft Azure, QEMU, VirtualBox, VMware等。

优点

• 虚拟机镜像封装了技术栈:虚拟机镜像包含服务及其所有的依赖项。消除了错误来源，确保正确安装和设置服务运行所