理解微服务架构

微服务架构（简称micro services）是一种独特的软件系统开发方法，它试图专注于构建具有定义良好的接口和操作的单一功能模块。近年来，随着企业希望变得更加敏捷，并朝着DevOps和持续测试的方向发展，这一趋势变得越来越流行。

微服务对敏捷和DevOps团队有很多好处——正如Martin Fowler指出的那样，Netflix、eBay、亚马逊、Twitter、PayPal和其他技术明星都已经从单一架构演变为微服务架构。与微服务不同，整体式应用程序构建为一个独立的单元。这会使应用程序的更改变慢，因为它会影响整个系统。对一小部分代码的修改可能需要构建和部署一个全新版本的软件。扩展应用程序的特定功能，还意味着您必须扩展整个应用程序。

微服务通过尽可能的模块化解决了单片系统的这些挑战。以最简单的形式，它们帮助将应用程序构建为一套小型服务，每个服务都在自己的流程中运行，并且可以独立部署。这些服务可以用不同的编程语言编写，并且可以使用不同的数据存储技术。虽然这导致了系统的可伸缩性和灵活性的发展，但它需要一个动态的改头换面。微服务通常通过API连接，并且可以利用在RESTful和web服务生态系统中发展起来的许多相同的工具和解决方案。测试这些API有助于验证整个microservice部署中的数据和信息流。

理解微服务架构

正如对术语“微服务”并没有正式的定义一样，在基于这种体系结构风格的每个系统中也并没有标准模型。但您可以预期大多数微服务系统都有一些显著的特点。

微服务的六大特征

1） 多组件

根据定义，构建为微服务的软件可以分解为多个组件服务。为什么？这样就可以独立地部署、调整和重新部署这些服务，而不会影响应用程序的完整性。因此，您可能只需要更改一个或多个不同的服务，而不必重新部署整个应用程序。但这种方法确实有其缺点，包括昂贵的远程调用（而不是进程内调用）、粗粒度的远程API，以及在组件之间重新分配职责时增加的复杂性。

2） 专为商业而建

微服务风格通常围绕业务能力和优先级进行组织。与传统的单片开发方法不同，在这种方法中，不同的团队都特别关注UI、数据库、技术层或服务器端逻辑，而微服务体系结构利用了跨功能团队。每个团队的职责是基于通过消息总线进行通信的一个或多个单独服务来制作特定产品。在微服务领域，一个团队在其生命周期内拥有该产品，正如亚马逊经常引用的格言“你构建它，你运行它”。

3） 简单路由

微服务的行为有点像经典的UNIX系统：它们接收请求，处理请求，并相应地生成响应。这与许多其他产品，如ESB（企业服务总线）相反你可以说，微服务拥有处理信息和应用逻辑的智能端点，以及信息流动的哑管道。

4） 分散的

由于微服务涉及多种技术和平台，传统的集中式治理方法并不理想。分散式治理受到微服务社区的青睐，因为其开发人员努力开发出有用的工具，供其他人使用以解决同样的问题。就像分散式治理一样，微服务体系结构也支持分散的数据管理。单片系统跨不同的应用程序使用单个逻辑数据库。在微服务应用程序中，每个服务通常管理其唯一的数据库。

5） 抗故障

就像一个全面发展的孩子一样，微服务被设计来应对失败。由于几个独特和多样的服务在一起通信，一个服务很可能会因为这样或那样的原因失败（例如，当供应商不可用时）。在这些情况下，客户端应允许其相邻的服务运行，同时以尽可能优雅的方式退出。但是，监视微服务有助于防止出现故障的风险。显然，与单片系统体系结构相比，此要求增加了微服务的复杂性。

6） 进化的

微服务体系结构是一种进化设计，同样适用于进化系统，在进化系统中，您无法完全预测有一天可能会访问您的应用程序的设备类型。许多应用程序开始基于单片体系结构，但随着一些不可预见的需求浮出水面，可以慢慢改造为微服务通过API在较旧的单片体系结构上交互的。

微服务示例

Netflix拥有一个广泛的体系结构，该体系结构已从单一架构演变为SOA。它每天从800多种不同类型的设备到其流媒体视频API接收超过10亿个呼叫。然后，每个API调用都会提示对后端服务进行大约五个额外的调用。

亚马逊也迁移到了微服务。他们从各种应用程序（包括管理web服务API的应用程序以及网站本身的应用程序）中收到无数的调用，这对于他们的旧的两层体系结构来说根本不可能处理。

拍卖网站eBay是另一个经历了同样转变的例子。他们的核心应用程序由几个独立的应用程序组成，每个应用程序执行不同功能区域的业务逻辑。

微服务的利弊

微服务不是银弹，通过实现它们，您将暴露沟通、团队合作和其他问题，这些问题以前可能是隐含的，但现在被迫公开。但是微服务中的API网关可以大大减少构建和QA的时间和工作量。

一个常见问题涉及跨服务共享模式/验证逻辑。如果B有不同的需求，为了考虑某些数据的有效性并不总是适用于B。最好的建议是在共享库中应用版本控制和分发模式。然后，对库的更改成为团队之间的讨论。此外，强大的版本控制带来了依赖性，这可能会导致更多的开销。克服这一问题的最佳实践是围绕向后兼容性进行规划，并接受来自外部服务/团队的回归测试。这些提示您在中断其他人的业务流程之前进行对话，而不是之后。

与其他任何事情一样，微服务架构是否适合您取决于您的需求，因为它们都有各自的优缺点。下面是一些好的和坏的简要介绍：

赞成

• 微服务体系结构使开发人员可以自由地独立开发和部署服务
• 微服务可以由一个相当小的团队开发
• 不同服务的代码可以用不同的语言编写（尽管许多从业者不鼓励这样做）
• 易于集成和自动部署（使用开源持续集成工具，如Jenkins、Hudson等）
• 开发人员易于理解和修改，因此可以帮助新的团队成员快速提高工作效率
• 开发人员可以利用最新的技术
• 代码是围绕业务功能组织的
• 更快地启动web容器，因此部署也更快
• 当应用程序的某个部分需要更改时，只有相关的服务可以修改和重新部署，而无需修改和重新部署整个应用程序
• 更好的故障隔离：如果一个微服务出现故障，另一个将继续工作（尽管monolith应用程序的一个问题区域可能危及整个系统）
• 易于扩展并与第三方服务集成
• 没有对技术堆栈的长期承诺

反对

• 由于分布式部署，测试可能变得复杂而乏味
• 服务数量的增加可能导致信息障碍
• 该体系结构带来了额外的复杂性，因为开发人员必须降低容错性、网络延迟、处理各种消息格式以及负载平衡
• 作为一个分布式系统，它可能会导致重复工作
• 当服务数量增加时，集成和管理整个产品可能会变得复杂
• 除了单片体系结构的一些复杂性之外，开发人员还必须处理分布式系统的额外复杂性
• 开发人员必须投入更多的精力来实现服务之间的通信机制
• 在不使用分布式事务的情况下处理跨多个服务的用例不仅困难，而且需要不同团队之间的沟通与合作

微服务架构的工作原理

1） 巨石与康威定律

首先，让我们探讨康威定律，该定律指出：“设计系统的组织……被限制生产这些组织通信结构副本的设计。”

设想X公司有两个团队：支持团队和会计团队。本能地，我们将高风险活动分开；决定客户退款之类的责任很难。考虑一下我们如何回答这样的问题：“会计团队是否有足够的人来处理客户退款和信贷？”或者“我们的支持人员能够申请信用并处理受挫客户不是更好的结果吗？”X公司的新政策解决了这个问题：支持部门可以申请信用，但会计部门必须处理退款以将钱返还给客户。在这个相互关联的系统中，角色和责任已成功地分离，同时获得客户满意度并将风险降至最低。

同样，在设计任何软件应用程序的开始，公司通常会组建一个团队并创建一个项目。随着时间的推移，团队不断壮大，同一代码库上的多个项目也完成了。通常情况下，这会导致相互竞争的项目：两个人会发现，在同一个代码领域中，如果不引入权衡，就很难在不同的目的下工作。而在等式中加入更多的人只会使问题变得更糟。正如弗雷德·布鲁克斯所说，九个女人不能在一个月内生一个孩子。

此外，在X公司或任何开发团队中，优先级经常发生变化，导致管理和沟通问题。上个月的最高优先级项目可能导致我们的团队努力发布代码，但现在一个用户报告了一个问题，由于这个月的优先级，我们没有时间解决它。这是采用SOA（包括各种微服务）的最令人信服的理由。面向服务的方法认识到变更管理、领域知识和业务优先级之间的摩擦，允许开发团队明确地分离和解决它们。当然，这本身就是一种折衷——它需要协调，但它允许你集中摩擦并引入效率，而不是遭受大量小的低效。

最重要的是，巧妙地实现SOA或微服务体系结构迫使您应用接口分离原则。由于成熟系统的连通性，在隔离关注的问题时，典型的方法是找到接缝或通信点，然后在系统的两半之间画一条虚线。然而，如果不仔细考虑，这可能会导致意外地创建两个较小但不断增长的巨石，现在与某种桥梁相连。这样做的结果可能是将重要的代码放在错误的一边：团队a不费心去看管它，而团队B需要它，所以他们重新发明了它。

2） 微服务：避开巨石

我们列举了一些常见的问题；现在让我们开始看一些解决方案。

如何部署相对独立但集成的服务而不产生意外的整体？好吧，假设您有一个大型应用程序，如下面我们公司X的示例所示，并且正在拆分代码库和团队以扩大规模。您可以在应用程序图的边缘查找某些内容，而不是查找要拆分的整个应用程序部分。您可以知道这些部分是什么，因为没有什么依赖于它们。在我们的示例中，指向打印机和存储的箭头表明，它们是可以很容易地从主应用程序中删除并抽象掉的两件事情。打印作业或发票与此无关；打印机只需要可打印的数据。将这些打印机和存储设备转换为外部服务可以避免前面提到的单一问题。这也是有意义的，因为它们被多次使用，而且几乎没有什么可以重新发明的。用例从过去的经验中是众所周知的，所以您可以避免意外删除关键功能。

3） 服务对象和标识数据

那么，我们如何从巨石变成服务？一种方法是通过服务对象。在不从应用程序中删除代码的情况下，您实际上只是开始将其构造为完全外部的。要做到这一点，您首先需要区分可以执行的操作以及作为这些操作的输入和输出显示的数据。考虑下面的代码，做一个有用的概念和任务的状态。

# A class to model a core transaction and execute it

      class Job
        def initialize
          @status = 'Queued'
        end
        
        def do_useful_work
          ....
          @status = 'Finished'
        end
        
        def finished?
          return @status == 'Finished'
        end
        
        def ready?
          return @status == 'Queued'
        end
      end

要让它看起来像一个微服务，下一步是什么？

# Service to do useful work and modify a status

    class JobService
      def do_useful_work(job_status)
        ....
        
        job_status.finish!
        
        return job_status
      end
    end

    # A model of our Job's status

    class JobStatus
      def initialize
        @status = 'Queued'
      end
      
      def finished?
        return @status == 'Finished'
      end
      
      def ready?
        return @status == 'Queued'
      end
      
      def finish!
        @status = 'Finished'
      end
    end

现在我们已经区分了两个不同的类：一个是建模数据的类，另一个是执行操作的类。重要的是，我们的JobService类几乎没有状态，您可以反复调用相同的操作，只更改数据，并期望得到一致的结果。如果JobService以某种方式开始在网络上运行，那么我们的单片应用程序就不会在意了。将这些类型的类转移到库中，并用网络客户机替换以前的实现，将允许您将现有代码转换为可伸缩的外部服务。

这是一种六边形体系结构，应用程序的核心和协调处于中心位置，外部组件围绕它进行编排以实现您的目标。

4） Coordination和Dumb Pipes

现在，让我们更仔细地看看是什么让某个东西成为一种微服务，而不是传统的SOA。

也许最重要的区别是副作用。微服务避免它们。要了解原因，让我们看一看较旧的方法：Unix管道。

ls | wc-l

上面，两个程序链接在一起：第一个列出目录中的所有文件，第二个读取输入流中的行数。想象一下，编写一个类似的程序，然后不得不将其修改为以下内容：

ls | less

组成小块功能依赖于可重复的结果、输入和输出的标准机制以及程序的退出代码，以指示成功或失败。我们从观察证据中知道这是可行的，我们还知道Unix管道是一个“哑”接口，因为它没有控制语句。管道通过将数据从A推送到B来应用SRP，由管道成员决定输入是否不可接受。

让我们回到X公司的工作和发票系统。每一个都控制一个事务，可以一起使用，也可以单独使用：可以为作业创建发票，可以在不创建发票的情况下创建作业，也可以在不创建作业的情况下创建发票。与Unix shell命令不同，拥有作业和发票的系统有自己的用户独立工作。但如果不回到政策上来，就不可能在全球范围内对这两个体系实施规则。

假设我们要提取出可以重复执行的关键操作，这些操作用于发送发票、更改作业状态和更改发票状态。这些与持久化数据的任务完全不同。

这使我们能够将离散组件连接到两条管道中：

用户创建手动invoice

• 将数据添加到invoice，状态为“已创建”
• -调用BillingPolicyService以确定何时为给定客户支付invoice
• invoice是发给客户的
• 持续显示到invoice数据服务，状态为“已发送”

用户完成作业，创建invoice

• 验证作业是否可完成
• 将数据添加到invoice，状态为“已创建”
• -调用BillingPolicyService以确定何时为给定客户支付invoice
• invoice是发给客户的
• 持续显示到invoice数据服务，状态为“已发送”

与invoice计算相关的步骤是幂等的，因此，通过利用我们新的专用微服务，编写invoice草稿或预览客户应付的金额非常简单。

与传统SOA不同，这里的区别在于，与可能执行整个业务操作的高级API调用相比，我们通过简单的接口公开了低级细节。事实上，使用高级API，很难将小组件重新连接在一起，因为服务设计师已经消除了我们可以通过提供一次性接口来实现的许多接缝或选择。

至此，业务逻辑、策略和规则的重复导致许多人传统上将这种复杂性推到服务总线或单一、集中的工作流编排工具中。然而，微服务体系结构的关键优势并不是我们从不共享业务规则/流程/策略，而是我们将它们推送到离散的包中，与业务需求保持一致。这不仅意味着策略是分布式的，还意味着您可以在没有风险的情况下更改业务流程。

SOA与微服务

“等一下，”你们中的一些人可能会边喝早茶边喃喃地说，“这不是SOA的另一个名字吗？”面向服务的体系结构（SOA）在本世纪头几年兴起，微服务体系结构（microservice Architecture，简称MSA）有许多相似之处。然而，传统的SOA是一个更广泛的框架，可以包含多种内容。一些微服务倡导者完全拒绝SOA标签，而另一些微服务则认为微服务仅仅是SOA的一种理想的、精致的形式。无论如何，我们认为存在足够明显的差异来证明一个独特的“微服务”概念是正确的（至少作为SOA的一种特殊形式，我们将在后面加以说明）。

例如，典型的SOA模型通常具有更多依赖的ESB，微服务使用更快的消息传递机制。SOA还侧重于命令式编程，而微服务体系结构侧重于响应式参与者编程风格。此外，SOA模型往往有一个超大的关系数据库，而微服务经常使用NoSQL或微SQL数据库（可以连接到传统数据库）。但真正的区别与用于首先获得一组集成服务的体系结构方法有关。

由于数字世界中的一切都在变化，因此能够跟上软件发展需求的敏捷开发技术是非常宝贵的。microservices体系结构中使用的大多数实践来自于为大型企业组织创建软件应用程序的开发人员，他们知道今天的最终用户期望在各种设备上获得动态而一致的体验。可扩展、适应性强、模块化且可快速访问的基于云的应用程序需求量很大。这导致许多开发人员改变了他们的方法。

微服务体系结构的未来

无论微服务体系结构是否成为未来开发人员的首选风格，它显然是一个强有力的想法，为设计和实现企业应用程序提供了巨大的好处。许多开发人员和组织从未使用过SOA的名称，甚至没有将他们的实践标记为SOA，而是一直在使用一种方法来利用可归类为微服务的API。

我们还看到许多现有技术试图解决微服务所要解决的部分细分和通信问题。SOAP在描述给定端点上可用的操作以及通过WSDLs在何处发现这些操作方面做得很好。从理论上讲，UDDI是向宣传服务可以做什么以及在哪里可以找到服务迈出的一大步。但是这些技术已经被一个相对复杂的实现所破坏，并且往往不会被新的项目所采用。基于REST的服务也面临同样的问题，尽管您可以将WSDLs与REST结合使用，但还没有广泛使用。

假设发现是一个已解决的问题，那么在不相关的应用程序之间共享模式和意义对于除微服务和其他SOA系统之外的任何应用程序来说仍然是一个困难的命题。RDFS、OWL和RIF等技术已经存在并被标准化，但并不常用。JSON-LD和Schema.org提供了共享定义的整个开放web的大致情况，但这些还没有在大型私营企业中采用。

然而，共享、标准化定义的力量正在政府内部大行其道。Tim Berners-Lee一直在广泛提倡链接数据。结果可以在data.gov和data.gov.uk中看到，您可以在此浏览大量可用的数据集以及详细描述的链接数据。如果能够就大量标准化定义达成一致，那么接下来的步骤很可能是面向代理：小程序协调来自大量供应商的微服务以实现特定目标。当你将SaaS应用程序、可穿戴设备和物联网的日益复杂和通信需求纳入总体规划时，很明显，微服务架构的未来可能非常光明。

原文地址：https://smartbear.com/solutions/microservices/