微服务提倡者Martin Fowler关于微服务的原文翻译＜转载＞

Martin Fowler 微服务

一个新的架构术语: Matin Fowler提倡的微服务架构文章

在过去的几年中,出现了"微服务结构"一词,用于描述架将软件应用程序设计为独立部署的服务套件的特定方式,尽管没有对架构风格的精确定义,但围绕业务能力,自动部署,端点中的智能以及对语言和数据分散控制,组织周围存在某些共同特征.

简而言之,微服务架构风格是一种单一应用程序开发为一组小型服务的方法,每个小型服务都在自己的进程中运行并与轻量级机制(通常是HTTP资源API)进行通信,这些服务围绕业务功能构建,并且可以通过全自动部署机制独立部署,有一个集中管理的最低限度的这些服务,可以不同的语言不同的数据存储技术.

在2013年底,听到我圈子中有关微服务的所有讨论后,我开始担心微服务不明确,(这种命运SOA带来了许多问题).因此,我和同事詹姆斯·刘易斯（James Lewis）在一起，他是这种风格的经验丰富的从业者之一。我们在一起写也就是后来有了微服务的文章我们这篇文章是为了提供对微服务样式的坚定定义,我们通过列出我们在该领域中看到的微服务架构的共同特征来做到这一点．

- 通过服务进行组件化

- 围绕业务能力进行组织

- 产品不是项目

- 智能端点和哑管理

- 分散治理

- 分散数据管理

- 基础设施自动化

- 失败设计

- 进化设计

我们还研究了一些常见问题,例如:微服务的规模有多大"以及"微服务和面向服务的体系结构之间的区别是什么,这篇文章激发了人们对微服务的系兴趣.

== 我们什么时候应该使用微服务???==

任何建筑风格都需要权衡,我们必须根据使用的上下文评估其优点.微服务肯定是这种情况,尽管他它是一种有用的体系结构,实际上,大多情况下,使用整体组件会更好.

微服务可带来好处… …但要付费(来自微服务的权衡)

强大的模板边界: 微服务加强了模块化结构,这对于大型团队而言尤其重要
独立部署: 简单服务更易于部署,并且由于它是自治的,因此出错是不太可能导致系统故障.
技术多样性:借助微服务,您可以混合使用多种语言,开发框架和数据存储技术.
分发:分布式系统更难编程,因为远程调用速度很慢并且总是,有失败的风险.
最终一致性:对于分布式而言,保持情强一致性非常困难,这意味着每个人都必须管理组最终一致性.
运营复杂性:您需要一个成熟的运营团队来管理大量定期重新部署的服务.

微服务新架构术语的定义:原文如下:https://martinfowler.com/articles/microservices.html

1:在过去的几年中,出现了"微服务体系结构"一词,用于描述将软件应用程序设计为独立部署的服务套件的特定方式,尽管没有对此风格的精确定义,但围绕业务能力,自动部署,端点中的智能以及对语言和数据的分散控制,组织周围此存在在某些共同特征.

2:"微服务"在拥挤的软件体系结构大街上的又一个新名词,尽管我们的天性是轻蔑地掠过些东西,但是这种术语描述了一种越来越受欢迎的软件系统样式,在过去的几年中,我们已经看到许多项目都使用这种样式,并且到目前为止,结果是积极的,已至于对于我们的许多同事来说,这已成为构建企业应用程序的默认样式,但是,令人遗憾的是,没有太多信息可以概述微服务风格是什么以及如何实现.

2:简而言之,微服务架构样式是一种将单一应用程序开发一组小服务的方法,每个小服务都在自己的进程中运行并与轻量机制(通常是 HTTP 资源 API)进行通信.这些服务围绕业务功能构建,并且可以通过全自动部署机制部署,这些服务的集中管理几乎没有,可以用不同的编程语言编写并使用不同的数据存储技术.

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

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

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

微服务的架构特征

我们不能说对微服务架构样式有一个正式的定义,但是我们可以尝试描述我们认为符合标签的架构共同特征,与任何概述通用特征的定义一样,并非所有微服务架构都具有所有特征,但是我们确实希望大多数微服务架构都具有大多数特征,尽管我们的作者一直是这个相当松散的社区的活跃成员,但我们的意图是尝试我们在自己的工作以及我们所认识的团队的类似努力中看到的,特别是,我们没有规定要符合的定义.

通过服务进行组件化

自从我们从事软件行业以来,就一直希望通过组件连接在一起构建系统,这与我们在物理世界中看到事物的方式非常相似,再过去的几十年中,我们看到了在大多数语言平台中都包含的大量通用库概要中取得了长足的进步.

在谈论组件中,我们会遇到很难定义组件的定义的问题,我们是定义是,组件是可以独立替换和升级的软件单元

*微服务架构将使用库,但是它们将自己的软件组成组件的方式是分解为服务.我们将库定义,为链接到程序并使用内存中函数调用的组件,而服务则是进程外组件,而服务是进程外组件,它们通过某种机制(例如 Web 服务请求远程过程调用)进行通信(这与许多OO程序中的服务对象的概率不同.)
使用服务作为组件,(而不是库)的主要原因之一是服务可独立部署的,如果您的应用程序在单个过程中包含多个库,则对任何单个组件的更改都将导致必须重新部署整个应用程序,但是,如果该应用程序分解为多个服务,则可以预期许多个服务的更改仅亚要求重新部署该服务.这不是绝对的,某种更改贵改变服务接口,从而导致某种程度的协调,但是好的微服务架构的目的是通过服务的内聚性服务边界和演化机制来最小化它们.

将服务用作组件的另一个结果是更明确的组件接口,大多数语言都没有定义都没有明确的发布接口的良好的机制,通常唯一的文档和纪律可以防止客户端破坏组件的封装,从而导致组件之间的耦合过于紧密,服务通过使用显式的远程调用机制避免这种情况变得更加容易.

初看起来,我们可以观察带服务映射到运行时进程,但这仅仅是初看起来,服务可能包含将初始终一起开发部署的多个流程,例如:仅由该服务使用的应用程序流程和数据库.

围绕业务能力组件

当希望将大型应用程序拆分为多个部分时,管理层通常重点放在技术层,从而导致UI团队,服务器端逻辑团队和数据库团队.当团队按照这些路线分开时,即使是简单的更改也可能导致跨团队项目需要时间和预算批准,精明的团队将围绕此问题进行优化,并减少两种弊端中的较小者-只需要将逻辑加到它它们访问的任何应用程序中即可.换句话说:逻辑无处不在,这是康康威定律发挥作用的一个例子。

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

以这种方式组织的一家公司.跨职能团队负责构建和操作每个作用,每个产品分为多个分为多个通过消息总线进通信的单独服务.

大型单片应用程序也始终可以围绕业务进行模块化,尽管这种情况并不常见,当然.我们会敦促组成一个整体应用程序的大型团队按照业务划分自己.我们字这里看到的主要问题是,它们往往是围绕太多上下文进行组织的,如果整体跨越了这些模块化边界中的许多边界了,那么团队中的各个成员可能很难将其放入它们的短期记忆中.另外.我们看到模块化的生产线需要大量的纪律来实施,服务组件所需的必要的,更明确的分割使得更容易保持院队界限.

产品不是项目

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

微服务的支持倾向于避免这种模式,而是倾向团队应该在产品的整个生命周期内拥有产品的想法.这样做的一个共同灵感是亚马逊的构建,运行概念,其中开发团队对生成中的软件负责任.这使开发人员可以日常接触其软件在生成中的行为方式,并增加与用户的联系,因为他们必须承担至少一些支持负担.
产品的心态与业务能力的联系紧密相关,与其将软件视为要完成的功能集,不如说存在着一种持续的关系,即问题是软件如何帮助其用户增强业务能力.
没有理由不能在整体应用程序中采用的方法,但是较小的服务粒度可以使在服务开发人员与其用户之间建立个人关系变得更加容易

分散数据管理

数据管理的分散化以多种不同的方式呈现。从最抽象的角度讲，这意味着系统的世界概念模型将有所不同。在大型企业中进行集成时，这是一个常见问题，客户的销售视图将与支持视图不同。在销售视图中称为客户的某些内容可能根本不会出现在支持视图中。那些具有相同属性的属性可能具有不同的语义，并且（更差的）公共属性具有不同的语义。

微服务是未来?

其实当我在熟读由 Martin Fowler提倡的微服务文章时候,当时本文的主要目的是解释微服务的主要思想,通过花时间来做到这一点,我们清楚地认为微服务架构是一个重要的想法,值得企业应用认真考虑,我们最近使用这样式架构了多个系统,并认识了其他使用并喜欢此方法的人.

尽管有这些积极的经验，但是，我们并没有争论我们可以确定微服务是软件体系结构的未来方向。尽管到目前为止，与单片应用程序相比，我们的经验是积极的，但我们意识到，没有足够的时间来进行全面的判断。

通常，您做出体系结构决策的真正后果只有在您做出决策的几年后才能显现出来。我们看到的项目中，一个对模块化有强烈需求的优秀团队构建了一个整体式的架构，并且这种架构多年来一直在衰落。许多人认为，由于服务边界是明确的并且很难修补，因此微服务的这种衰减不太可能发生。但是，直到我们看到足够的系统和足够的使用期限，我们才能真正评估微服务架构的成熟程度。

人们肯定会期望微服务成熟度很低的原因是有原因的。在进行组件化的任何努力中，成功都取决于软件适合组件的程度。很难准确地确定组件边界应位于何处。进化设计认识到正确设置边界的困难，因此易于重构它们的重要性。但是，当您的组件是具有远程通信的服务时，则重构要比进程内库困难得多。跨服务边界移动代码很困难，参与者之间的任何接口更改都需要协调，需要向后兼容，并且测试变得更加复杂。

我们的同事山姆·纽曼（Sam Newman）在2014年的大部分时间里都在写一本书，该书记录了我们构建微服务的经验。如果您想更深入地研究该主题，那么这应该是您的下一步。

另一个问题是，如果组件组成不清晰，那么您要做的就是将复杂性从组件内部转移到组件之间的连接。这不仅可以解决复杂性问题，还可以将其转移到不太明确和难以控制的地方。当您查看一个小的简单组件的内部而又缺少服务之间的混乱连接时，很容易想到事情会更好。

最后，还有团队合作能力的因素。技能更强的团队倾向于采用新技术。但是，对于技能娴熟的团队来说更有效的技术不一定适用于技能不太熟练的团队。我们已经看到了许多技能水平较低的团队构建凌乱的整体架构的案例，但是花些时间来看看当微服务发生这种混乱时会发生什么。一个糟糕的团队总是会创建一个糟糕的系统-在这种情况下，很难说微服务是减少混乱还是使其变得更糟。

我们听到的一个合理的论据是，您不应该从微服务架构开始。取而代之的是从整体开始，使其保持模块化，一旦整体出现问题，将其拆分为微服务。（尽管此建议并不理想，因为良好的进程内接口通常不是良好的服务接口。）

因此，我们对此持谨慎乐观的态度。到目前为止，我们已经对微服务风格有足够的了解，认为这可能是一条值得走的路。我们无法确定最终的结果，但是软件开发的挑战之一是只能根据当前必须掌握的不完善信息来做出决策。