微服务

第一章 这个新架构术语的定义

在过去几年中出现了“微服务架构”一词，用于描述将软件应用程序设计为可独立部署的服务套件的特定方式。目前，这种架构方式还没有准确的定义，但是在围绕业务能力的组织、自动部署、智能端点、语言和数据的分散控制等方面，这种架构的应用却有着某种共同的特征。

“微服务”——又一个出现在拥挤的软件架构街道上的新术语。尽管我们的本能倾向是轻蔑地瞥一眼这些东西，但这一术语描述了一种我们发现越来越有吸引力的软件系统风格。在过去的几年里，我们看到许多项目使用这种风格，到目前为止，结果是积极的，以至于对于我们的许多同事来说，这正在成为构建企业应用程序的默认风格。然而，遗憾的是，没有太多信息概述微服务风格是什么以及如何去做。

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

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

这样的单体服务器是构建这样一个系统的自然方式。处理请求的所有逻辑都在单个进程中运行，您可以使用语言的基本功能将应用程序划分为类、函数和命名空间。小心一点，您可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署管道来确保正确测试更改并将其部署到生产中。您可以通过在负载均衡器后面运行多个实例来水平扩展单体应用。

单体应用程序可能会成功，但越来越多的人对它们感到沮丧——尤其是当越来越多的应用程序被部署到云时。变更周期是紧密联系在一起的——对应用程序的一小部分进行的变更需要重新构建和部署整个整体。随着时间的推移，通常很难保持良好的模块化结构，从而更难保持应该只影响该模块中的一个模块的更改。扩展需要扩展整个应用程序，而不是需要更多资源的部分。

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

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

第二章 微服务架构的特征

我们不能说微服务架构风格有一个正式的定义，但我们可以尝试描述我们认为适合该标签的架构的共同特征。与概述共同特征的任何定义一样，并非所有微服务架构都具有所有特征，但我们确实希望大多数微服务架构表现出最多的特征。虽然我们的作者一直是这个相当松散的社区的活跃成员，但我们的目的是尝试描述我们在自己的工作和我们认识的团队的类似努力中看到的内容。特别是我们没有制定一些定义来符合。

2.1通过服务组件化

自从我们涉足软件行业以来，就一直希望通过将组件连接在一起来构建系统，这很像我们在物理世界中看到的东西。在过去的几十年中，我们看见了大量简编的公共库取得的巨大进步，它们是大多数语言平台的一部分。

在谈论组件时，我们遇到了组件构成的困难定义。我们的定义是，组件是可独立替换和升级的软件单元。

微服务架构将使用库，但它们将自己的软件组件化的主要方式是分解为服务。我们将库定义为链接到程序中并使用内存中的函数调用进行调用的组件，而服务是与诸如 Web 服务请求或远程过程调用之类的机制进行通信的进程外组件。（这与许多面向对象程序中的服务对象的概念不同。）

使用服务作为组件（而不是库）的一个主要原因是服务是可独立部署的。如果您的应用程序由单个进程中的多个库组成，则对任何单个组件的更改都会导致必须重新部署整个应用程序。但是，如果该应用程序分解为多个服务，许多单个功能的更改只需要重新部署该服务。但是这不是绝对的，一些变化会改变服务接口导致一些协调，但是一个好的微服务架构的目标是通过服务契约中的内聚服务边界和演化机制来最小化这些耦合。

使用服务作为组件的另一个结果是更明确的组件接口。大多数语言没有定义显式发布接口的良好机制。通常，只有文档和纪律才能防止客户端破坏组件的封装，从而导致组件之间的耦合过于紧密。通过使用显式远程调用机制，服务可以更轻松地避免这种情况。

使用这样的服务确实有缺点。远程调用比进程内调用更昂贵，因此远程 API 需要更粗粒度，这通常更难使用。如果您需要更改组件之间的职责分配，当您跨越流程边界时，这种行为移动就更难做到了。

在第一次近似时，我们可以观察到服务映射到运行时进程，但这只是第一次近似。一个服务可能由多个进程组成，这些进程总是一起开发和部署，例如一个应用程序进程和一个仅由该服务使用的数据库。

2.2围绕业务能力组织

在寻求将大型应用程序拆分为多个部分时，管理通常侧重于技术层，从而将整个团队划分为 UI 团队、服务器端逻辑团队和数据库团队。当团队按照这些方式分开时，即使是简单的更改也会导致跨团队项目需要时间和预算批准。一个聪明的团队将围绕这一点进行优化，并针对两害相权取其轻——只需将逻辑强加到他们有权访问的任何应用程序中即可。换句话说，逻辑无处不在。这是康威定律的一个例子。

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

2.3产品不是项目

我们看到的大多数应用程序开发工作都使用项目模型：目的是交付一些软件，然后将其视为已完成。完成后，软件将移交给维护组织，而构建它的项目团队将被解散。

微服务支持者倾向于避免这种模式，而是更喜欢团队应该在其整个生命周期内拥有产品的概念。对此的一个共同灵感是亚马逊的“谁构建，谁运行”的概念，其中开发团队对生产中的软件负全部责任。这使开发人员能够每天接触他们的软件在生产中的行为方式，并增加与用户的联系，因为他们必须至少承担一些支持负担。

产品心态与业务能力联系在一起。不是将软件视为一组要完成的功能，而是存在一种持续的关系，其中的问题是软件如何帮助其用户增强业务能力。

没有理由不能对单体应用程序采用相同的方法，但服务的较小粒度可以更容易地在服务开发人员与其用户之间建立个人关系。

2.4智能端点和哑管道

在不同流程之间构建通信结构时，我们已经看到许多产品和方法强调将重要的智能融入通信机制本身。一个很好的例子是企业服务总线 (ESB)，其中 ESB 产品通常包括用于消息路由、编排、转换和应用业务规则的复杂设施。

微服务社区倾向于另一种方法： 智能端点和哑管道。从微服务构建的应用程序旨在尽可能地解耦和内聚——它们拥有自己的域逻辑，并且更像是经典 Unix 意义上的过滤器——接收请求，适当地应用逻辑并产生响应。这些是使用简单的 RESTish 协议而不是其他更复杂的协议（例如 WS-Choreography 或 BPEL 或由中央工具进行编排）编排的。

外文原文资料信息

[1] 外文原文作者：James Lewis , Martin Fowler

[2] 外文原文所在书名或论文题目：Microservices

[3] 外文原文来源：

网页地址：https://martinfowler.com/articles/microservices.html

二、外文原文资料：

Microservices

a definition of this new architectural term

The term 'Microservice Architecture' has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

25 March 2014

James Lewis

James Lewis is a Principal Consultant at Thoughtworks and member of the Technology Advisory Board. James interest in building applications out of small collaborating services stems from a background in integrating enterprise systems at scale. Hes built a number of systems using microservices and has been an active participant in the growing community for a couple of years.

Martin Fowler

Martin Fowler is an author, speaker, and general loud-mouth on software development. Hes long been puzzled by the problem of how to componentize software systems, having

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[596121]，资料为PDF文档或Word文档，PDF文档可免费转换为Word