什么是微服务？

Hi胡瀚

发布于 2018-07-04 15:45:37

8020

发布于 2018-07-04 15:45:37

自2011年以来，微服务一直是软件社区的重要组成部分，但与许多其他架构和设计理念一样，自从成立以来，围绕这种架构风格的争论不断。与许多这些炒作一样，有一种倾向于转换所有现有的软件或要求使用这种风格实施所有新软件。作为回应，许多人将这种风格视为纯粹的表面炒作，并且以与面向服务的体系结构（SOA）和跨平台面向对象的通信协议（即公共对象请求代理体系结构（Common Object Request Broker Architecture））相同的方式讽刺地期待它的突出地位被废， CORBA）。

在炒作和嘲讽中，微服务带来的重要优势不仅在于它的可重用性和模块性，还在于它在实践中促进的软件工具和技术。事实上，这种架构风格已被许多最大的企业应用程序开发商所采用，其中包括亚马逊，优步，Groupon，Capital One，沃尔玛和Netflix（2016年仅占北美所有下载互联网流量的35.2％）。通过这种巨大的采用，它便于让认真严谨的软件工程师和技术人员们关注到这种架构方法。

在本文中，我们将探索微服务的基础知识，包括捕获微服务的许多特征的一般定义，微服务如何形成的简要历史以及微服务所呈现的一些折衷。虽然微服务是一个广阔的话题，无论深度还是广度而言，我们都将关注架构的总体原则，而不是具体的实现技术。我们还将探索一些最受欢迎和最丰富的资源，感兴趣的读者可以利用这些资源从这个概述中获取信息并将其付诸实践。

简化的定义

我们通常为不同的哲学和体系结构寻找清晰明确的定义，但在微服务的情况下，并不存在一个普遍认同的定义。Microservices.io（由Chris Richardson创建）提供了一个比较可靠的定义，定义如下：

微服务 - 也被称为微服务体系结构 - 是一种架构风格，它将应用程序构建为一系列松散耦合的服务，实现业务功能。微服务架构支持大型复杂应用的持续交付/部署。它还使组织能够发展其技术堆栈。

詹姆斯刘易斯和马丁福勒提出了他们自己的定义：

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

虽然这些定义对于有些人来说似乎都是比较模糊的，但它们很好地描述了微服务架构的本质。通常，微服务体系结构涉及创建单独的服务，这些服务执行设定的业务目标，并与简约互连相链接，如含状态传输（REST）应用程序编程接口（API）。虽然个别服务的真正定义可能因应用程序而异，但总体思路是每个服务应解决一个业务目标并依赖其他服务来实现其范围之外的目的。

例如，假设我们想创建一个在线书店，允许注册用户提交订单，验证和更新库存，并使用最便宜的方法（如果书籍可用）发运图书。此应用程序应该可以使用移动应用程序，客户端单页应用程序（SPA）（在浏览器中运行）以及直接通过REST接口访问，而移动和SPA接口依赖于REST API。使用这个描述，我们可以将我们的系统分成三个主要服务，以及他们各自的职责：

用户服务：管理注册用户
库存服务：管理当前可用的图书库存
送货服务：处理寻找最便宜的送货服务并运送订单

同样，我们可以将三个主要接口分类到我们的系统中：

移动应用程序：通过API网关/代理使用REST接口
基于浏览器的SPA：通过API网关/代理服务器来使用REST接口
REST接口：消耗并生成JavaScript对象表示法（JSON）资源的超文本标记语言（HTTP）REST接口; 对于我们的微服务实现，每个服务都将拥有自己的REST接口，并且将使用API网关将这些单独的API组合成明显独特的REST API

将所有这些分区和接口组合到一个应用程序中，我们可以设计出以下系统图：

整体的方式

如果这是一个简单的系统，我们可以将每个服务组合成一个应用程序，并创建软件接口以促进服务之间的交互。接下来，我们将创建一个REST接口，可以让每个服务都可以处理请求。同样，我们将使用共享数据存储。从本质上讲，我们将创建一个名义上的三层应用程序，顶部有REST接口，中间有域和业务逻辑（用于用户，库存和运输组合），数据层（与我们的共享数据交互商店和每个外部运输服务）位于底部。

微服务方式

在更现实的缩放应用程序中，我们可以通过将每个服务分为自己的应用程序和自己的进程空间，从中受益匪浅。例如，我们可以创建一个单独的用户服务，它具有自己的数据存储，自己的业务和域逻辑以及自己的REST接口。同样，我们可以为库存和运输服务重复相同的流程。这导致了独立且高度一致的服务，如上面的系统图所示。

这个部门允许我们创建封装良好的微型（或微型）服务，可以很好地完成一件事。由于每个都有自己的进程空间，我们也可以独立部署它们。这使我们可以对单个微服务进行更改而不会影响其他服务。这也使我们能够缩放系统过载的部分。例如，如果我们要创建单个应用程序，我们将被迫在负载均衡器后部署全部应用程序的新实例以共享工作负载。如果只有运输服务超载，我们也不得不创建用户和库存服务的新实例，但这些新实例可能未被使用（或者共享单个实例就可以处理的负载从而造成不必要的负载均衡）。

在微服务方法中，我们可以扩展需要更多资源的应用程序部分（在这种情况下为送货服务）。从本质上讲，微服务为我们提供了更高层次的部署粒度，但这种方式带来了一些缺点。其中最主要的是需要更多细微的协调。例如，如果我们将系统组合到单个应用程序中，我们将共享一个进程空间，并且在服务之间进行调用与向内存中的另一个对象进行方法调用一样无足轻重。通过微服务，我们现在负责确保服务之间的消息映射正确，允许每个服务通过各自的REST API彼此通信。

虽然编排可能是微服务的关注点，但服务之间的互连应该尽可能地简单，并且构成恰好来完成服务之间的最小通信。不同的SOA与企业服务总线（ESB）的时期，智慧合理的微服务架构应当包含在各个服务之间，而不仅仅是在服务之间的连接中。

理想的微服务环境

部署和扩展的灵活性不仅使我们能够对运行时应用程序的部署方式做出更精细的决策，而且还使我们能够将高度自动化引入到生产系统中。例如，理论上，我们可以为每个服务创建一个交付管道，在管道之间建立反映服务之间依赖关系的关系。当对服务的代码库进行更改时，将启动该服务的交付管道。随着执行更改服务的管道，随后将执行所有相关管道。

一旦服务被构建并测试（其流水线阶段全部通过），服务及其依赖项（其流水线也通过了所有阶段）被打包到容器中并部署到生产环境中。下图显示了这种理想的环境。

在上面描述的部署环境之上，可以建立一个类似的设置，以启动微服务的新实例，以自动扩展以满足生产环境的需求。例如，一旦服务的管道完成，服务将被集装箱化并存储在存储库中。如果需要更多的服务实例，例如一天中高压或大流量时间，则可以自动部署更多的集装箱化微服务实例以满足这些直接需求。当需要更多服务实例消失时，可以移除容器，并且系统的资源使用恢复到正常水平。

虽然交付管道技术的组合是一个伟大的目标，集装箱化技术和微服务理念，但实际应用的细微差别使这一理想系统难以实施。例如，假设一个应用程序由20个微服务组成，所有这些应用程序都有数十个自己的依赖项和必需的接口。随着系统规模的增长，编排大量微服务会变得非常困难。

在实用应用程序中，完全自动化（从开发人员检查代码到在生产环境中部署和扩展更新的微服务）可能是不可能的，但即使是部分实现这些概念，也可以大大降低生产系统的脆弱性。

重新定义了简化的定义

通过了解微服务背后的思想过程和它们提供的一些优点，我们可以为微服务体系结构创建一个简化的定义：

微服务体系结构是指将系统的业务目标分为独立的，封装的和解耦的服务，这些服务通过定义良好的远程接口相互交互

虽然此定义可能缺少其他定义的某些细节和特性，但它为理解微服务提供了基准。独立性和封装的限制导致防御性编程的服务能够以最小的影响来应对故障，升级或扩展。实际上，微服务的定义良好的远程接口将是某种类型的基于Web的技术，例如WebSockets，协议缓冲区或HTTP REST接口，但任何可在进程空间之间通信的技术都已足够。

为了更深入地了解微服务，我们必须探索微服务是如何实现的，特别是微服务架构在成长和成熟时所取代的技术和哲学。

企业应用的演变

模块化和组件化一直以来都是软件工程的一部分，但是微型服务已经是一个相对较新的概念，源自于漫长的架构历史。虽然许多基础概念自软件工程的婴儿时代就已经出现，但创建一系列网络化微型专用服务的想法始于最基本的所有体系结构：单片架构。

整体建筑

一块巨石是一块巨大的石块结构，自软件开发以来，大多数系统都与这些建筑有着惊人的相似之处。在大多数软件中，我们只将所有代码绑定到一个庞大的项目中，并将所有业务逻辑，接口，框架和数据存储集中到一个应用程序中。虽然这可能听起来像是构建应用程序的糟糕方式，但它对于广泛的用例非常有效。

例如，用户，库存和运输微服务可以被认为是庞然大物。从书店应用程序的全貌来看，它们是简单的微服务，但如果我们只关注其中的一种服务，它们就是一个带有用户界面（REST API），业务逻辑和数据存储的单层三层应用程序。

尽管整体技术足以满足小规模应用或小型服务的需求，但对于当今开发和部署的大规模应用来说，它是完全不够的。对于每天处理超过400亿次事件的 Netflix应用程序，这种过于简化的架构在开发和部署方面都不足。在互联网时代的早期，一种新型架构被设想来解决这个难题：SOA。

面向服务的体系结构

与单机架构不同，SOA是更标准化的架构。SOA没有一个应用程序处理系统中的所有类型的服务，而是用一个非常精确的接口将系统的每个主要部分描述为服务。SOA不仅仅是一系列服务，还包括一个大型核心：ESB。

很多SOA实现的目标是创建一组标准化的服务（消费和生产数据）并将它们附加到单独的ESB。然后ESB负责匹配生产者和消费者，并允许服务之间彼此发现。应该指出的是，每种服务或服务类别的接口都是高度标准化的，而且很可能是合约性的。

例如，我们可以通过创建一个允许连接不同设备（服务）的集中式ESB来为汽车创建SOA。然后，我们可以添加所需设备的合约，例如发动机控制单元（ECU）。为了将ECU连接到ESB，我们实施了完全符合ECU合同接口并注册ESB的服务。当公共汽车上的其他服务希望对发动机进行更改（例如更换空气燃料混合物）时，他们会向ESB发送信息。然后ESB认识到我们的ECU服务能够执行此操作并将消息发送给我们的ECU服务。该方案如下图所示。

需要注意的是，发送空气燃料混合物更新信息的服务不知道我们的ECU服务的任何内容，甚至可能不知道我们的ECU服务已在公交车上注册。相反，它只是产生一条消息，并指示ESB为消息找到消费者。ESB知道我们的ECU服务并且认识到它是空气燃料混合物更新消息的使用者（当它被注册为ECU接口合同的实现时发现），将消息转发给ECU。需要注意的是，大多数消息路由和决策都是在ESB中进行的：通常，应用程序的智能都包含在ESB中。

理论上，这种方法将允许完全正交的服务实现连接到相同的总线并进行互操作。例如，我们可以在福特汽车内创建ESB实施方案，允许福特算法将空燃混合气更新消息发送到总线，并让博世ECU对引擎进行必要的更改。这种架构的美妙之处在于，福特算法中没有博世ECU的概念，只是有一个它生成的空气 - 燃油混合信息的订阅。

虽然这个想法在理论上是合理的，但它需要一组严格的接口和一个非常复杂的ESB来创建。实际上，这意味着在线应用程序需要大量复杂的Web服务描述语言（WSDL）规则，以及用于本地化应用程序的无数专有接口合同。虽然一些SOA实现是富有成效的，但总体而言，花费了数百万美元来创建SOA ESB并没有多大用处。需要的是巨石和ESB之间的妥协：具有简单通信接口的小型服务。

微服务是不同的

微服务架构与SAO类似，但有一些重大差异。与SOA一样，微服务体系结构由封装服务组成，但接口规则更为宽松。微服务不是使用专有的或复杂的规则描述符，而是使用简洁的接口，利用预定义的JSON（或其他信息传输格式，如可扩展标记语言，XML）请求和响应主体使用基于HTTP的REST。这不仅消除了对严格规则的需求，也消除了对ESB的需求。

使用微服务体系结构，体系结构的智能在于叶子而不是分支：服务包含业务逻辑并直接向其他服务（或通过代理或网关）发出请求，而不是使用集中式路由或发现。实质上，微服务是整体架构和SOA摆摆动之间的平衡。

优点缺点

就像软件工程中的任何其他哲学或方法一样，微服务旨在解决特定环境中的问题。因此，微服务有其优势和劣势。

优点

使用微服务架构的一些主要优势包括：

服务相对较小且独立（相对于等效单一应用程序的规模而言较小）。
改变一个服务并不一定会引起其他服务的改变。
服务可以独立于其他服务进行部署和扩展，甚至可以使用容器技术（如Docker）部署在单独的容器中; 可以使用构建和交付管道来自动化部署，更改服务会导致服务的自动构建，测试和部署，以及依赖于其的其他服务。
服务可以独立开发，可能有不同的语言和技术堆栈，不同的开发人员，甚至不同的组织。
系统的部分可以热插拔，而不必关闭整个应用程序
系统中一项服务的失败并不一定会停止整个应用程序（系统各部分之间的界限更加明确，而且每个部分在微服务体系结构中与单一应用程序相比更加孤立）。
独立测试服务更容易。

缺点

虽然微服务对某些应用程序有效，但它们也存在一些缺点，包括：

服务可能包含重复的逻辑，或者开发工作可能在多个服务之间重复。
需要服务之间有更好的协调性。
由于需要网络路由和服务之间的其他通信路径，测试整个系统将更加困难。
干净地划分服务可能很困难（正如SoapUI Pro所说：“将应用程序划分为微服务非常重要）”。
恰当地封装服务之间的交易可能很困难; 例如，我们是否在库存服务中创建了一个订单ID，并将每个商品作为单独的消息（使用订单ID）添加到订单中，还是等待包含订单中的完整商品列表的消息发送到库存服务？
当部署微服务时（与等效的单片应用程序相比），可能需要更多资源（如内存）。
服务之间的连接往往比单个服务器复杂得多（不是单个连接的复杂性，比如SOA，而是各种微服务之间的连接数量）。