摘要：近年来，许多企业已经采用了微服务，也称为微服务架构，这种开发方法创建由一组小型独立服务组成的应用程序。这些独立的微服务中的每一个都可以单独测试和部署;它们甚至可以用不同的编程语言编写或使用不同的开发框架。

    近年来，许多企业已经采用了微服务，也称为微服务架构，这种开发方法创建由一组小型独立服务组成的应用程序。这些独立的微服务中的每一个都可以单独测试和部署;它们甚至可以用不同的编程语言编写或使用不同的开发框架。
　　
　　微服务应用程序与组织过去生产的单一应用程序有很大不同。几十年前，开发团队通常将应用程序创建为统一的整体。对于代码库较小的应用程序而言，这种方法很好，但随着代码库变大，单片应用程序变得比较笨拙。
　　
　　在某些情况下，随着应用程序的扩展，这种单片架构会导致吞吐量瓶颈，从而导致性能下降。此外，如果组织需要进行相对较小的更改，则需要在重新部署应用程序之前更新整个应用程序，并再次对其进行测试。
　　
　　微服务体系结构解决了许多这样的问题——尽管它本身也面临着挑战。它特别适用于由大量开发人员维护的非常大的应用程序。微服务与许多当今最流行的技术（如DevOps、自动化和云计算）紧密结合。此外，微服务和容器尤其具有互操作性，经常一起使用。
　　
　　一些供应商提供的产品被他们贴上“微服务平台”或“微服务框架”的标签，但是组织并不需要任何特定的软件或工具来部署微服务。它更多的是一种设计方法和一种架构风格，而不是一种特定的技术。
　　
　　也就是说，一些开发工具在支持微服务方面比其他开发工具更好。通常，支持DevOps和云计算的工具也是微服务的很好选择。
　　
　　什么是微服务架构？
　　
　　下图显示了微服务架构的各个方面之间的关系：
　　
　　                微服务图
　　
　　微服务架构将单片软件应用程序分解为更易于管理的服务组件。
　　
　　在这种类型的体系结构中，每个微服务都是完全独立的。它们各自可能有各自独立的数据库，也可能连接到远程服务（通常通过API）。客户机和各种微服务之间的通信通过API网关进行处理。应用程序也可能具有管理和/或服务发现功能。
　　
　　一些个人和组织试图识别不同类型的微服务。例如，有些人将微服务分为两类：无状态和有状态。其他人说有三种类型的微服务：无状态的、以数据为中心的和聚合器。
　　
　　不同意见部分源于这样一个事实，即没有标准机构或其他组织对微服务进行了广泛接受的定义。几个小组提出了微服务的相互竞争的定义，其中一些包括不同类型微服务的图表和描述。因此，人们对微服务的确切性质仍然感到困惑。
　　
　　微服务：相关概念
　　
　　即使是经验丰富的开发人员和行业专家有时也会将微服务与相关术语和技术混淆，例如面向服务的体系结构（SOA）、API和Web服务。
　　
　　微服务与SOA
　　
　　用户可以将微服务视为面向服务的体系结构（SOA）的继承者或子集，但两者并不完全相同。
　　
　　面向服务的体系结构，也称为基于服务的体系结构，是一种软件开发方法，它将应用程序的独立组件视为服务-类似于微服务体系结构。但是，面向服务的体系结构（SOA）应用程序传统上尝试重用和共享尽可能多的架构。例如，面向服务的体系结构（SOA）服务通常共享存储，构建在公共平台上，并使用企业服务总线（ESB）进行通信。
　　
　　相比之下，微服务意味着尽可能独立和分离。顾名思义，微服务也比面向服务的体系结构（SOA）中的服务小得多，它们通常通过轻量级协议而不是通过企业服务总线（ESB）进行通信。
　　
　　微服务与API
　　
　　应用程序编程接口（API）是应用程序的组件相互通信的定义方式。例如，应用程序经常使用API来调用软件库，例如JavaAPI。
　　
　　在微服务应用程序中，各个微服务使用API与每个（并且可能与外部服务）进行通信。微服务应用程序需要API才能运行，但API和微服务是两回事。
　　
　　微服务与Web服务
　　
　　人们有时会混淆的另一组术语是微服务和Web服务。
　　
　　Web服务是一种通过Web为其他应用程序提供功能的服务。例如，谷歌公司将谷歌地图作为Web服务提供，以便其他开发人员可以将映射功能添加到其网站或应用中。因此，当用户查找餐馆的网站，并看到提供餐馆路线的嵌入式谷歌地图链接时，该网站正在访问GoogleMapsWeb服务。
　　
　　微服务应用程序可以使用Web服务。为了使事情更加混乱，Web服务可以基于微服务架构。但是，这两者并不一定以任何方式相关。
　　
　　微服务的好处
　　
　　企业和软件供应商选择使用微服务架构，因为它提供了许多好处，包括：
　　
　　•更快的开发-将应用程序分解为许多小块。意味着用户可以分配独立的团队来处理每个部分，只需要团队之间的协调很少。无论是在初始开发阶段还是在更新期间，都可以加快整个开发过程。
　　
　　•更轻松的测试-使用微服务架构，每个微服务都可以独立测试。如果需要更新特定的微服务，则只需要在重新部署之前再次测试该微服务，这再次使该过程更快。
　　
　　•简化部署-由于可以单独部署微服务，因此可以单独推出单独的组件。如果一个微服务出现问题，用户可以轻松地回溯对该微服务的更改，而不会影响整个应用程序。
　　
　　•故障隔离-如果生产中的微服务应用程序出现问题，它应该只影响一个微服务。理论上，如果只有一个小部分包含错误，应用程序的其余部分应该继续正常运行。
　　
　　•更高的可扩展性-微服务也可以独立扩展。也就是说，用户可以为那些需要它们的微服务分配更多资源，而无需为应用程序的其余部分分配更多资源，尤其是在用户的微服务应用程序是基于云计算的情况下。这有助于防止单片应用程序可能出现的一些瓶颈。
　　
　　•更多技术选择-开发每个微服务的团队可以根据自己的偏好和应用程序的需求选择编程语言和框架。他们不需要在Java中构建一个应用程序，因为应用程序的其余部分是用Java编写的。
　　
　　微服务挑战
　　
　　虽然微服务提供了许多优势，但它也带来了一些挑战，包括：
　　
　　•复杂性-单个微服务非常简单，但是由许多独立部分组成的应用程序具有许多不同的语言，框架和依赖性非常复杂。微服务应用程序的治理和管理可能非常困难。
　　
　　•网络延迟-由于应用程序中的所有微服务都是通过API相互通信，因此它们必然会给网络带来沉重的负担。除非网络设计用于处理增加的负载，否则可能会降低性能。
　　
　　•测试-虽然微服务可以独立测试，但用户还必须测试整个应用程序。对不同团队的问题进行故障排除可能很困难。
　　
　　•微服务版本控制-在传统应用程序中，团队为每个向用户推出的更新提供新编号。当组件单独开发时，这变得更加困难。一个微服务可能在版本1.2上，而另一个在3.7上。这也使测试变得复杂，因为微服务可能与单独组件的1.3版一起正常工作，但在1.4版本发布时完全中断。
　　
　　•缺乏技能-微服务架构是一种新方法，因此并非所有开发人员都具有这种架构形式的经验。有些人也可能对发展方法的变化有抵触情绪。
　　
　　微服务和DevOps
　　
　　如果用户熟悉DevOps方法，就会发现微服务的许多优点也与DevOps的优势重叠。这两种技术相互适应。
　　
　　例如，DevOps和微服务都承诺更快的开发和部署。当用户将DevOps与微服务架构一起使用时，可以将每个架构的优势复合在一起。
　　
　　此外，DevOps团队使用的许多技术和方法在创建微服务应用程序时也非常有用。例如，自动化、云计算（尤其是PaaS产品和无服务器计算）和容器通常与DevOps和微服务相关联。与单片软件结构相比，使用微服务应用程序更容易实现DevOps目标，如持续部署和连续测试。
　　
　　微服务示例
　　
　　使用微服务架构的企业列表就像是技术行业的人。一些最著名的例子包括：
　　
　　•Netflix是最早采用微服务的公司之一。流媒体服务于2009年开始改变其架构，并且在记录其过渡时异常开放，其中包括一路上的一些小问题。今天，NetflixWeb应用程序由API网关管理，每天处理数百个微服务的数十亿个请求。新架构使该服务可以扩展到现在的规模，并有助于防止中断。
　　
　　•Airbnb是微服务的另一个早期采用者。在线客房预订服务首先采用DevOps开始迁移到微服务。随着时间的推移，DevOps所要求的持续部署变得过于繁琐，无法处理整体架构。通过转向微服务，该公司能够扩大其持续交付，使其现在每年支持超过75,000个生产部署。
　　
　　•Uber从2015年开始从单片架构转变为微服务架构。在其博客中，该公司概述了其一些工具选择，并指出它遇到了一些障碍。它建议采用微服务的其他组织为流程预算大量时间，从小型服务开始，并投入大量资源进行测试。
　　
　　编辑：Harris