微服务是一种软件开发技术，是面向服务架构（SOA）结构风格的变体，它将应用程序安排为松散耦合服务的集合。[1]在微服务架构中，服务是细粒度的，协议是轻量级的。

介绍

微服务没有单一的定义。随着时间的推移，业界形成了一种共识。一些经常被引用的定义特征包括：

• 微服务体系结构（MSA）中的服务通常是通过网络通信的进程，使用与技术无关的协议（如HTTP）来实现目标。[2][3][4]
• 微服务架构中的服务可以独立部署。[5][6]
• 服务是围绕业务能力组织的。[7]
• 服务可以使用不同的编程语言、数据库、硬件和软件环境来实现，这取决于什么最适合
• 服务规模小，支持消息传递，受上下文限制，自主开发，独立部署，分散，使用自动化流程构建和发布。[5]

微服务不是单体应用程序（例如，web控制器或前端后端）中的一个层。[8]它是一个独立的业务功能，具有清晰的接口，并且可以通过自己的内部组件实现分层架构。从战略的角度来看，微服务体系结构基本上遵循了Unix的“做一件事，做好一件事”的理念[9]Martin Fowler将基于微服务的体系结构描述为具有以下属性：[2]

• 有助于持续交付软件开发过程。对应用程序的一小部分进行更改只需要重新构建和重新部署一个或少量服务。[10]
• 遵循诸如细粒度接口（独立部署服务）、业务驱动开发（如领域驱动设计）等原则

微服务架构通常用于云原生应用程序、无服务器计算和使用轻量级容器部署的应用程序。福勒认为，由于服务的数量庞大（与单一应用程序实现相比），为了有效地开发、维护和操作这些应用程序，分散的连续交付和具有整体服务监控的devop是必要的。[12]遵循这种方法的后果（和理据）是各个微服务可以单独缩放。在单片方法中，支持三个功能的应用程序必须全部扩展，即使其中只有一个功能具有资源约束。[13]对于微服务，只需要扩展支持具有资源约束的功能的微服务，从而提供资源和成本优化效益。[14]

历史

早在2005年，Peter Rodgers在Web服务边缘会议上的一次演讲中就引入了“微型Web服务”一词。与传统思维相反，在SOAP-SOA架构宣传曲线的最高峰，他主张“REST服务”，并在会议演示的幻灯片4中，讨论了“软件组件是微型Web服务”。[15]他接着说“微型服务是使用类Unix管道（Web满足Unix=真正的松耦合）组成的”。服务可以调用服务（+多个语言运行时间）。复杂的服务程序集抽象在简单的URI接口之后。任何服务，在任何粒度上，都可以被公开。“他描述了一个设计良好的微服务平台是如何”应用Web和REST服务的底层架构原则，以及类Unix的调度和管道，在面向服务的架构中提供根本的灵活性和改进的简单性。[16]

罗杰斯的工作起源于1999年惠普实验室的德克斯特研究项目，该项目的目标是使代码不那么脆弱，并使大规模、复杂的软件系统具有改变的鲁棒性。[17]最终，这条研究道路导致了面向资源计算（ROC）的发展，ROC是一种广义的计算抽象，其中REST是一个特殊的子集。

2007年，Juval Lówy在他的写作[18]和演讲[19][20]中呼吁建立每一个类都是服务的系统。Lówy意识到这需要使用一种技术来支持服务的这种细粒度使用，他扩展了Windows通信基金会（WCF）来做到这一点，[21][22]把每一个类都当作一个服务，同时保持类的传统编程模型。

2011年5月在威尼斯附近举行的一个软件架构师研讨会使用了“微服务”这个术语来描述参与者认为的一种常见的体系结构风格，他们中的许多人最近一直在探索这种风格。[23]2012年5月，同一组人决定将“微服务”作为最合适的名称。2012年3月，James Lewis在Kraków的33度微服务（Java，Unix方式，[24]）中以案例研究的形式提出了其中的一些想法，Fred George[25]也差不多是在同一时间提出的。Adrian Cockcroft，Netflix云系统的前主管，[26]将这种方法描述为“细粒度的SOA”，开创了web级的风格，正如本文中提到的许多其他方法一样——Joe Walnes、Dan North、Evan Bottcher和Graham Tackley

微服务是面向服务架构（service oriented architectures，SOA）的一种实现方法的专门化，用于构建灵活的、独立部署的软件系统。[7]微服务方法是继DevOps之后首次实现的SOA，并且在构建连续部署的系统方面越来越流行。[28]

2020年2月，云微服务市场研究报告预测，从2019年到2026年，全球微服务架构市场规模将以21.37%的复合年增长率增长，到2026年将达到31亿美元。[29]

服务粒度

定义微服务架构的一个关键步骤是确定单个微服务必须有多大。对于这一点，目前还没有共识或试金石，因为正确的答案取决于业务和组织环境。[30]例如，亚马逊著名地使用面向服务的架构，其中一个服务通常与一个由3到10名工程师组成的团队以1:1的比例进行映射。[31]

将服务设置得太小被认为是一种不好的做法，因为这样一来，运行时开销和操作复杂性可能会压倒这种方法的优点。当事情变得过于细粒度时，必须考虑其他方法，例如将功能打包为库，将函数移动到其他微服务中

如果在为系统构建的域建模时使用域驱动设计，那么微服务可以像聚合一样小，也可以像有界上下文一样大。[32]

好处

将应用程序分解为不同的较小服务的好处有很多：

• 模块化：这使得应用程序更容易理解、开发、测试，并且更容易抵御架构侵蚀。[6]与单体架构的复杂性相比，这种优势经常被争论。[33]
• 可伸缩性：由于微服务是独立实现和部署的，也就是说，它们在独立的进程中运行，因此可以独立地监视和伸缩它们。[34]
• 异构系统和遗留系统的集成：微服务被认为是现有单片软件应用程序现代化的可行手段。[35][36]有几家公司的经验报告，它们已成功地用微服务替换了（部分）现有软件，或正在这样做。[37]遗留应用程序的软件现代化是使用增量方法完成的。[38]
• 分布式开发：它使小型自治团队能够独立地开发、部署和扩展各自的服务，从而实现开发的并行化。[39]它还允许通过不断的重构出现单个服务的体系结构。[40]基于微服务的体系结构有助于持续集成，持续交付和部署。[41][42]

批评和关切

微服务的方法受到许多问题的批评：

• 服务形成信息壁垒。[43]
• 网络上的服务间呼叫在网络延迟和消息处理时间方面的成本高于单块服务进程中的进程内呼叫。[2]
• 测试和部署更加复杂。[44][45]
• 在服务之间转移职责更为困难。[6]这可能涉及不同团队之间的通信、用另一种语言重写功能或将其安装到不同的基础架构中。[2]然而，微服务可以独立于应用程序的其他部分进行部署，而处理单体的团队需要同步才能一起部署。[46]
• 将服务的大小视为主要的结构机制可能会导致太多的服务，而内部模块化的替代可能会导致更简单的设计。[47]这需要使用有助于理解应用程序的总体架构和组件之间的相互依赖关系的应用程序。[48]
• 在基于微服务的体系结构中，两阶段提交被视为一种反模式，因为这会导致事务中所有参与者的紧密耦合。然而，缺乏这项技术会导致一些棘手的问题，为了保持数据的一致性，所有事务参与者都必须实现这些问题
• 如果使用不同的工具和技术构建许多服务，那么开发和支持这些服务就更具挑战性—如果工程师经常在项目之间移动，这一问题尤其严重。[50]
• 通常与微服务（HTTP）一起使用的协议是为面向公众的服务而设计的，因此不适合用于通常必须非常可靠的内部微服务
• 虽然分解方法并不特定于微服务，但它通常使用功能分解，这样既不处理需求的变化，又增加了服务的复杂性。[52]
• 微服务的概念本身就是误导，因为只有服务。对于服务何时开始或停止作为微服务，没有声音定义。[53]

认知负荷

该体系结构引入了额外的复杂性和需要解决的新问题，例如网络延迟、消息格式设计、[54]备份/可用性/一致性（BAC）、[55]负载平衡和容错。[45]所有这些问题都必须大规模解决。根据《2020年微服务状况报告》的调查结果，维护和调试仍然是构建微服务的开发团队面临的最大问题之一。[56]

如果单片应用程序作为一组微服务应用程序重新实现，它的复杂性不会消失。一些复杂性转化为操作复杂性。[57]复杂性表现在网络流量增加和性能降低的其他地方。此外，由任何数量的微服务组成的应用程序都有大量的接口点来访问其各自的生态系统，这增加了体系结构的复杂性。[58]各种组织原则（如HATEOAS、通过Swagger捕获的接口和数据模型文档，已应用于减少此类额外复杂性的影响。

技术

计算机微服务可以用不同的编程语言实现，并且可以使用不同的基础设施。因此，最重要的技术选择是微服务相互通信的方式（同步、异步、UI集成）和用于通信的协议（RESTful HTTP、消息传递、GraphQL…）。在传统的系统中，大多数技术选择（如编程语言）都会影响整个系统。因此，选择技术的方法是完全不同的

Eclipse基金会发布了一个开发微服务的规范Eclipse microfile

服务网格

另请参见：服务网格

在服务网格中，每个服务实例都与反向代理服务器的实例配对，称为服务代理、sidecar代理或sidecar。服务实例和sidecar代理共享一个容器，容器由容器编排工具（如Kubernetes、Nomad、Docker Swarm或DC/OS）管理。服务代理负责与其他服务实例的通信，可以支持服务（实例）发现、负载平衡、身份验证和授权、安全通信等功能。

在服务网格中，服务实例及其sidecar代理被称为构成数据平面，它不仅包括数据管理，还包括请求处理和响应。服务网格还包括一个控制平面，用于管理由其sidecar代理介导的服务之间的交互。服务网格架构有多种选择：Istio（Google、IBM和Lyft的联合项目）、Linkerd（由floubant[61]领导的CNCF项目）、Consul（HashiCorp产品）和其他。

平台比较

实现微服务架构是困难的。任何微服务架构都需要解决许多问题（见下表）。Netflix开发了一个微服务框架来支持他们的内部应用程序，然后开放源码[62]该框架的许多部分。这些工具中的许多已经通过Spring框架得到了普及，它们已经作为Spring云项目（Spring Cloud[63]project）下的基于Spring的工具重新实现。下表显示了Kubernetes生态系统的一个实现特性与Spring Cloud world的一个等价特性的比较。[64]Spring Cloud生态系统的一个值得注意的方面是，它们都是基于Java的技术，而Kubernetes是一个多线程运行时平台。

原文：https://en.wikipedia.org/wiki/Microservices

本文：http://jiagoushi.pro/node/966

讨论：请加入知识星球或者微信圈子【首席架构师圈】