1.1 微服务概述

“微服务”在拥挤的软件体系结构大街上的又一个新名词。这种术语描述了一种越来越受欢迎的软件系统样式。在过去的几年中，已经看到许多项目都使用这种样式，到目前为止，结果是非常积极的，这已成为构建企业应用程序的默认样式。但是，令人遗憾的是，没有太多信息可以概述微服务风格是什么以及如何实现。简而言之，微服务架构样式是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。这些服务的集中管理几乎没有，可以用不同的编程语言编写并使用不同的数据存储技术。

微服务样式，将其与整体式样式比较很有用：以单个单元构建的整体式应用程序。企业应用程序通常由三个主要部分构建：客户端用户界面（由在用户计算机上的浏览器中运行的HTML页面和javascript组成）和数据库（由许多插入到常用（通常是关系型）数据库管理中的表组成）系统和服务器端应用程序。服务器端应用程序将处理HTTP请求，执行域逻辑，从数据库检索和更新数据，以及选择并填充要发送到浏览器的HTML视图。该服务器端应用程序是一个整体一个逻辑可执行文件。对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。

这种整体服务器是构建此类系统的自然方法。处理请求的所有逻辑都在单个过程中运行，从而可以使用语言的基本功能将应用程序划分为类，函数和名称空间。可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署管道来确保对更改了正确的测试并将其部署到生产中。可以通过在负载均衡器后面运行许多实例来水平缩放整体。

整体应用程序可以成功，但是越来越多的人对它们感到沮丧，尤其是随着越来越多的应用程序部署到云中。变更周期捆绑在一起，对应用程序的一小部分更改，需要重建和部署整个整体。随着时间的流逝，通常很难保持良好的模块化结构，这使得很难保留只影响该模块中一个模块的更改。扩展要求扩展整个应用程序，而不是需要更多资源的部分应用程序，如图 1.1 所示。

这些导致了微服务架构的风格：将应用程序构建为服务套件。除了服务可独立部署和可扩展之外，每个服务还提供了牢固的模块边界，甚至允许以不同的编程语言编写不同的服务。也可以由不同的团队来管理。

当希望将大型应用程序拆分为多个部分时，管理层通常将重点放在技术层，从而导致UI团队，服务器端逻辑团队和数据库团队。当团队按这些方向分开时，即使简单地更改也可能导致跨团队项目需要时间和预算批准。精明的团队会围绕此问题优化，并减少两种弊端中的较小者，只需将逻辑强加到他们可以访问的任何应用程序中即可。换句话说，逻辑无处不在，如图 1.2 所示。

细分的微服务方法不同，分为围绕业务能力组织的服务。此类服务针对该业务领域采用了软件的广泛实施，包括用户界面，持久性存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理，如图 1.3 所示。