微服务（一）

作者：James Lewis/Martin Folwer
翻译：Zhang Yang

“微服务” – 软件体系结构这样一个拥挤的街道上的又一个新术语。虽然我们很自然地倾向于用轻蔑的眼神来看它，但是它描述了一种软件风格，现在我们却越来越多的发现它吸引人的地方。在过去数年中，我们已经看到了很多的项目在使用这种风格，到目前为止结果都是积极的，以至于我们很多同事来说，它正成为构建企业应用程序的默认样式。但不幸的是，还没有多少信息概括微服务的特点是什么，以及如何做到。

总的来说，微服务架构风格[1]是一种方法，开发一个应用程序提供一组服务套件：小服务都运行在各自的进程中，通过轻量级机制进行通讯，常常包含HTTP资源API。这些服务是通过全自动部署机制，建立起业务功能和独立部署。这些服务最小化中央管理，可以用不同的编程语言，并使用不同的数据存储技术。

要解释微服务，首先将它和整体件作比较：一个整体应用程序就像建成单一部件。企业应用通常内置三个主要部分：一个客户端用户界面（包括HTML页和在用户的计算机上的浏览器运行的JavaScript），数据库（包括插入到一个共同的，并且通常为关系数据库管理许多表的系统），和一个服务器端应用程序。服务器端应用程序将处理HTTP请求，执行业务逻辑，从数据库中检索和更新数据，和挑选并填充HTML视图发送到浏览器。这种服务器端应用程序是一个整体件 -一个单一的逻辑执行部[2]。任何对系统的更改都必须构建和部署服务器端应用程序的新版本。

这样的整体件服务器是建立系统的一种自然方式。所有请求的处理逻辑都运行在一个进程里，允许使用编程语言的基本功能特性将应用程序划分为不同的类，函数和命名空间。小心一些的话，你可以在开发者的笔记本上运行、测试这些应用程序，并使用部署管道，确保变动被恰当地测试过，并被部署到产品中。你可以通过运行多个实例和负载平衡器，横向扩展整体件。

整体件应用程序可以是成功的，但越来越多的人都感到挫败的心情 – 尤其是随着越来越多的应用被部署到云中。变化周期被紧密绑定 –对程序一个小部分的小改动，需要整个整体件重新构建和部署。随着时间的推移它往往很难保持一个良好的模块化

结构，使其难以保持的更改部分只影响它所在模块。扩展时就需要扩展整个应用程序，而不是需要更多的资源那一部分。

图1：整体式和微服务

这些挫折导致了微服务架构风格的产生：建立包含一组服务的应用程序。我们知道这样一个事实，即服务是独立部署的和可扩展的，每个服务还提供了一个清晰的模块边界，甚至允许不同的服务由不同的编程语言实现。它们也可以由不同的团队管理。

我们并不认为微服务款式新颖或创新，它的历史可以追溯到至少于Unix的设计原则。但我们认为，没有足够多的人考虑微服务架构，如果他们使用了它，许多软件开发会更好。

微服务架构的特点

我们不能说这是微服务架构的正式定义，但我们??可以尝试描述我们所看到的共同特性。标题中的共同特点，并不是所有的微服务架构都拥有的特点，但我们期待，大部分微服务架构呈现出大部分的特点。我们的作者一直是这个松散社区的积极成员，我们的目的是试图说明在我们自己的工作中，和我们所知道的同样努力的团队的工作中，所看在的。

依据服务组件化

从事软件业这么多年以来，我们一直希望和在我们看到的真实世界的事情一样, 系统是通过组件搭建起来的。在过去的几十年中，我们已经看到了是大多数语言平台都建立起了大量的公共库。

谈到组件，我们碰到的困难是：定义什么构成组件。我们的定义是，一个 组件是软件的单位，它可独立被更换和升级。

微服务架构也使用的库，但通过分解成服务，来组件化自己的软件。我们定义库 为被链接到程序，并提供内存函数调用的组件，而服务是跨多个进程的组件，它们之间以某种机制通信，如Web服务请求，或远程过程调用通信。（这是与许多OO程序中 服务对象 不同的概念[3]）。

使用服务作为组件（而不是库）的一个主要原因是，服务是可独立部署的。如果你有一个应用程序[4]，它由一个单一的进程和多个库组成，对任何单个部件的改动，结果必然要重新部署整个应用程序。但是，如果该应用程序被分解成多个服务，你可以期待许多单一服务改变而只需要重新部署该服务。这不是绝对的，有些变化会导致一些协调服务接口的改变，但良好的微服务架构可以通过凝聚服务的边界，以及服务契约演化，最大限度地减少这些情况的放生。

使用服务作为组件的另一个后果是更明确组件接口。大多数语言没有一个很好的机制来定义一个明确的发布的接口。通常，只有文档和规则来防止客户端打破组件的封装，导致组件之间过于紧密的耦合。服务更容易使用显式的远程调用机制，避免这种情况。

这样的使用服务确实也有不足之处。远程调用比进程调用更加昂贵，从而远程APIs必须是粗粒度的，这往往是更难以使用。当你跨越进程边界去更改组件之间的责任分配时，更难了。

作为一个第一近似，我们可以发现服务可以映射到运行时的进程，但是这仅是一个近似。服务可能包括多个进程，它们将永远被一起开发和部署，如应用程序进程，和只有进程使用的数据库。

备注：
1: The term “microservice” was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices – Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as “fine grained SOA” was pioneering the style at web scale as were many of the others mentioned in this article – Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
2: The term monolith has been in use by the Unix community for some time. It appears in The Art of Unix Programming to describe systems that get too big.
3: Many object-oriented designers, including ourselves, use the term service object in the Domain-Driven Design sense for an object that carries out a significant process that isn’t tied to an entity. This is a different concept to how we’re using “service” in this article. Sadly the term service has both meanings and we have to live with the polyseme.
4: We consider an application to be a social construction that binds together a code base, group of functionality, and body of funding.

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树服务网格(istio)ServiceMesh介绍8770 人正在系统学习中

来源：windmissing