微服务是什么

过去几年来，“微服务架构”这个术语出现了，它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义，但围绕业务能力，自动化部署，端点智能以及语言和数据的分散控制等方面存在着某些共同特征。

“微服务” - 在软件架构拥挤的街道上又一个新名词。尽管我们的自然倾向是以轻蔑的眼光来传递这样的东西，但这些术语描述了一种我们发现越来越吸引人的软件系统风格。我们已经看到许多项目在过去几年中都采用了这种风格，迄今为止的结果是积极的，因此对于我们的许多同事来说，这正成为构建企业应用程序的默认风格。可悲的是，没有太多的信息概述了微服务的风格以及如何去做。

简而言之，微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

在开始介绍微服务风格（microservice style）前，比较一下整体风格（monolithic style）是很有帮助的：一个完整应用程序（monolithic application）构建成一个单独的单元。企业应用程序通常建立在三个主要部分中：一个客户端用户界面（由用户计算机上的浏览器中运行的HTML页面和JavaScript组成）数据库（包括插入常见的通常是关系数据库管理的多个表系统）和一个服务器端应用程序。服务器端应用程序将处理HTTP请求，执行特定领域逻辑，通过数据库进行检索和更新数据，选择并填充要发送到浏览器的HTML视图。这个服务器端应用程序是一个庞然大物 - 一个逻辑可执行文件。系统的任何更改都涉及构建和部署新版本的服务器端应用程序。

这样的整体服务（monolithic server）是一种构建系统很自然的方式。处理请求的所有逻辑都在一个进程中运行，允许您使用语言的基本功能将应用程序划分为类，函数和名称空间。谨慎操作时，您可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署通道来确保更改经过适当测试并部署到生产环境中。您可以通过在负载平衡器后面运行多个实例来横向缩放整体。

单体式应用程序可以取得成功，但越来越多的人会感到失望 - 尤其是随着更多应用程序被部署到云中。变更周期是连在一起的 - 对应用程序的一小部分进行更改，需要重建和部署整个程序。随着时间的推移，它通常很难保持良好的模块化结构，使得难以保持应该：模块内的一个改动仅影响该模块本身中。自适应需要自适应整个应用程序，而不是它的一部分，这样做需要更多资源。

这些挫折引出了微服务架构风格：将应用程序构建为服务套件。除了服务是可独立部署和可伸缩的事实之外，每个服务还提供了一个严格的模块边界，甚至允许用不同的编程语言编写不同的服务。它们也可以由不同的团队来管理。

我们并不是说微服务风格是新颖的或创新的，它的根源至少可以追溯到Unix的设计原则。但我们确实认为，没有足够多的人考虑使用微服务架构，如果他们使用了，那么许多软件开发将会更好。

微服务体系结构的特征

我们不能说对微服务架构风格有一个正式的定义，但是我们可以尝试描述我们所看到的与“微服务”标签相符的架构的共同特征。与任何概述共同特征的定义一样，并不是所有的微服务架构都具有所有的特征，但是我们确实期望大多数微服务架构具有大多数特征。虽然我们的作者一直是这个相当松散的社区的活跃成员，但我们的目的是尝试描述我们在自己的工作中看到的东西，以及我们所知道的团队的类似努力。特别地，我们并没有给出一些符合要求的定义。

通过服务（Sevice）实现组件化

只要我们参与过软件行业，这就存在一种期盼：通过将组件整合在一起来构建系统，这与我们在现实世界中看待事物的方式非常相似。在过去的几十年中，我们已经见证了大部分语言平台中常见库的大量摘要所取得的巨大进步。在谈及组件时，我们遇到了对组件构成定义的难题。我们的定义是，组件是可独立更换和升级的软件单元。

微服务架构一样会用到各种库，但这种架构会把软件给拆分成各种不同的服务来实现组件化。这里我们定义两个重要的概念：库(library) 指的是链接到程序的组件，通过本地函数调用来使用库提供的功能；而服务 (service) 是进程外的组件，通过网络服务请求 (web service request) 或者远程函数调用之类的机制来使用里面的功能。注意这和很多面向对象程序里服务对象的机制是不同的 。

之所以在组件化的软件里用服务，而不是库，一个主要原因就是各个服务是可以独立部署的。比如说，如果在同一个软件里用了多个库，那么就算只是修改了其中一个，都会导致整个软件要被重新部署；相反，如果用的是服务，那只需要重新部署修改过的就可以。然而，有个问题是，当修改服务时，可能会把服务接口也给修改了，这样一来，服务的调用者和开发者就得自己私下协调了。好的微服务架构，就应该尽量避免这种问题；非要修改服务契约的话，也得循序渐进，让调用者有迹可循，不用私下协调。

使用服务作为组件的另一个后果是更显式的组件接口。大多数语言都没有很好的机制来定义显式发布的接口。通常，只有文档和规程可以防止客户机破坏组件的封装，从而导致组件之间的紧密耦合。通过使用显式的远程调用机制，服务可以更容易地避免这种情况。使用这样的服务确实有缺点。远程调用比进程内调用更昂贵，因此远程api需要粗粒度，这通常更难以使用。如果您需要更改组件之间的职责分配，那么当您跨越流程边界时，这种行为的移动就更加困难了。

我们可以观察到服务映射到运行时进程，但这只是第一次近似。服务可能包括多个进程，这些进程将始终会一起开发和部署，例如应用进程和服务所用到的数据库。

根据服务能力进行管理

当将大型应用程序拆分为不同组件时，通常的管理侧重于技术层，由技术层引领UI团队、服务器端逻辑团队和数据库团队的工作。当团队的这种生产线被隔离时，即使是简单的改变也会引起跨团队的项目耗时耗力。聪明的团队将围绕这一点进行优化——仅把逻辑强加到他们所能触及的任何方式中。换句话说，逻辑无处不在。这是Conway定律的一个例子。

任何如设计系统（广义定义）的组织，必将创造出一个设计，其设计结构是组织的通信结构的副本。

在划分层面，微服务方法是不同的，分解成围绕业务能力所组织的服务。这些服务需要对该业务领域的软件进行广泛的实施，包括用户界面、持久性存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验、数据库和项目管理。