通过微服务来正确实施SOA

导读	对于组织来说，能够构建、发展和扩展大型应用程序是至关重要的, 但所涉及的挑战使其成为一项艰巨的任务。正因为如此, 微服务凭借能够将单个组件拆分成围绕特定业务功能的独立服务，已成为构建现代云应用程序的主要模式。

微服务架构是一种分布式系统的方法，它可以促进使用具有自身生命周期的细粒度服务。由于微服务主要是围绕单个业务流程/功能而建模的，所以它们避免了传统分层 (多层/n 层)体系结构(如单体应用) 的问题。微服务同时还集成了过去十年出现的技术和新兴技术，因此避免了许多面向服务体系结构实现的缺点。

虽然使用微服务在使大型应用程序更易于管理方面有诸多好处，但是在任何情况下，构建一个可靠的分布式系统都是非常具有挑战性的，因为在处理故障、一致性和性能等方面有很多需要考虑的因素。

本文详细介绍了微服务架构的实现路径，并分析了该模式的优缺点。同时讨论了帮助开发人员和应用架构师，实现其应用程序目标的最优方法。

面向服务的体系架构SOA是一种可根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用的方法。每个服务都将实现预定义的业务目标，并执行分离的工作单元。这些服务是独立的，不依赖于其它服务的上下文或状态。它们在分布式系统体系结构中工作。

在某些方面，SOA架构是分布式技术（COM和CORBA）的进化。与这些类似，SOA强调服务与消费者（WSDL）以及特定服务发现（UDDI）、传输（SOAP）、中介（WS-mediation）、路由（WS-寻址）、安全（WS-security、WS-trust、WS- secure conversation等）和分布式计算的其他方面之间的严格契约。此外，SOA通过企业存储库、服务生命周期管理和服务级别监控工具，强调对服务的设计、开发和运营治理

微服务是一种体系结构风格。它是一种将单个应用程序开发为一组小型服务的方法，每个服务都运行自己的流程，并与轻量级机制通信，通常是 HTTP API。这些服务是围绕业务功能构建的，可以独立部署。

微服务模式有着显著的好处，特别是在支持复杂企业应用程序的敏捷开发和交付方面。

微服务体系结构模式将应用程序分解为可管理的块，从而实现执行模块级别，而在实践中，通过单一代码库实现模块级别是极其困难的。因此，单个服务的开发速度更快，也更容易理解和维护。

另外，这种方法更倾向于轻量级消息总线。简单来说，基于微服务构建的应用程序，其目的是尽可能地做到解耦和聚合。它们拥有自己的单个域逻辑，并更多地充当过滤器——接收请求，根据需要适当地应用逻辑，并产生响应。

微服务体系结构的本质并不新鲜，分布式系统的概念由来已久。微服务体系结构也类似于SOA。微服务背后的理念是构建大型的、复杂的、长期存在的应用程序，即随着时间的推移，而演进成一套统一的（有组织的或相互连接的）服务。“微服务”这一术语强烈表明了服务应该是小型的。

然而，尽管拥有小型服务是可取的，但这不应该是主要目标。相反，你的目标应该在于将系统分解为服务，以解决开发和部署的问题。有些服务可能确实很小，而另一些可能相当大。

应用程序的发展演变

在早期发展进程中，应用程序作为一个单一实体开发部署。这些单层应用程序易于部署，因为它们只有一个代码基和部署配置。

可伸缩性对于这种应用程序来说，是一个巨大的挑战，因为它只能通过复制整个应用程序来实现。这将直接增加企业的成本，并随着流量和负载的增加而造成资源浪费。

单层/整体应用的缺点导致了多层体系结构的产生。这种新体系结构将应用程序分解为逻辑分布式层，从而实现了高效的可伸缩性。这种方法通常将表示层、数据层和业务逻辑层分离。所以，扩展方法单独应用于这些层，而不是应用于整个应用。

但是，当使用该模式构建的应用程序增长时，它会在业务逻辑层上产生应变，并引出单体架构的许多缺点。同样，作为一个单一实体，可伸缩性是具有挑战性的，成本也是高昂的。

SOA发展演变过程中，其理念是实现将应用程序视为业务功能的愿景。

随着越来越多的企业走向自动化/数字化，IT因服务于快速变化的业务需求，已然发展为业务的支柱。这些快速变化的业务需求，使得开发人员开始将他们的应用设想为业务功能的集合，因此与组件在堆栈中的位置相比，隔离组件更符合他们的用途。例如，开发人员可以创建一个用来处理用户身份验证、计费订单服务或处电子邮件发送通知的用户服务，因为每个服务都更小、更集中，这样可以提供更有效的可伸缩性。

虽然这种模式为构建有效的应用程序体系结构提供了框架，但由于不必要的复杂抽象和遗留协议，它的实践通常是无效的。开发人员将尝试使用 SOA 来连接范围广泛的应用程序，它们都采用不同的语言，需要为企业服务总线提供额外的层。这导致了过时、昂贵的配置，无法跟上技术和商业环境的发展。

为什么是微服务——新模式？

IT的发展已经极大地改变了全球商业的前景。在早期，IT被认为是商业/组织的援助之手，用于减少业务功能/单元的手工工作。

如今，IT正被用来改造业务, 产生更多的收入。所以，现在IT不仅仅是一个支持功能，而是主要的业务功能。

Gartner 在其2015的10大战略技术趋势中表示：“为了迅速地应对数字业务和规模系统的快速变化需求，计算必须从静态模式转向动态模式。规则、模式和代码可以通过应用程序动态地组装，以及配置网络所需的所有元素。”

这种在应用体系结构中思维的转变，也带来了实践上的转变。Gartner 的进一步预测表明，“对于许多组织来说，面向 Web-Scale IT 未来迈出的第一步应该是 DevOps ——以协调的方式将开发和运维结合在一起，以推动应用服务的快速、持续的增量开发。”

使用 Web-Scale IT 企业可以更轻松地构建类似于 Amazon、Google 和 Facebook 提供的应用程序和基础架构。Web-Scale IT 能够使企业在其 IT 设置中，进一步拥抱云，向内部用户提供大型服务提供商的能力。
从SOA分化

微服务模式在定义特性方面比 SOA 更清晰，它提供了一个满足现代应用程序体系结构需求的框架。微服务通常被称为：正确实施的 SOA 。

SOA 专注于独立的技术系统, 微服务专注于独立的业务系统。

微服务模式的目标不是将各种应用程序连接在一起，而是创建一个由独立开发、独立部署的服务，组成的单一、聚合的应用程序，每个服务都遵循单一职责原则。然而，“微”这个表述，对于微服务的特性来说，可能会具有一点儿欺骗性，因为大小并不是微服务定义的特征。虽然微服务通常很小，但更重要的是每个服务自己封装的流程可以独立开发和部署。开发人员通过限制一个服务可做的事情范围，来确保这些服务不会无意中和许多解耦的单体一起结束。

与现代云一样，服务之间的通信是通过基于REST的API，通过HTTP完成的，传递JSON数据，通常通过消息队列来确保可靠性。单个微服务通常是异步处理的，由API调用、推送队列、调度或 webhook 等事件触发。一个围绕通信和处理的轻量级、高效框架，进一步将微服务与SOA区分开来。

这里还有一些其他的体系结构风格可以进行扩展。《可伸缩性的艺术》一书，描述了一个非常有用的三维可伸缩性模型：伸缩立方（Scale Cube），如下图所示。

在这个模型中，通过在负载均衡器之后，运行多份应用副本来伸缩应用的方式叫做X轴伸缩。这是提高应用程序容量和可用性的一个好方法。

使用 Z 轴收缩时，每个服务器都运行一份相同的代码副本。在这方面，它类似于 X 轴缩放。最大的区别在于每个服务器只负责数据的一个子集。与X轴伸缩一样，Z轴收缩可以提高应用程序的容量和可用性。

但是，两种方法都无法解决开发增加和应用程序复杂性的问题。

为了解决这些问题，我们需要应用 Y 轴伸缩。

Z 轴伸缩会拆分相似的服务, Y 轴伸缩会拆分不同的服务。在应用层，Y 轴缩放将一个整体应用程序拆分为一组服务。

每个服务都实现了一系列相关功能，如订单管理、客户管理等。

作为一种模式，微服务通过将功能元素分解为单个服务，来提升 Y 轴的可伸缩性, 而不是通过传统的复制。

理想情况下，每个服务应该只有一小部分职责。SRP（单一责任原则）将类的责任定义为需要更改的原因，并且类应该只有一个原因需要更改。将SRP应用于服务设计也是有意义的。

在微服务架构中，客户端与应用之间，以及应用组件之间的通信模式与单体应用不同。让我们先来看一下应用客户端如何与微服务交互的问题。在此之后，我们将研究应用程序中的通信机制。

应用程序客户端 （如本机移动应用程序）可以对各个服务发出基于 REST 的 HTTP 请求，如下图所示。

和客户端所需的数据之间的粒度可能存在明显的粒度不匹配。

例如，显示一个Web页面可能需要调用大量服务。例如，Amazon.com描述了一些页面如何需要调用100多个服务。即使是在高速互联网连接上发出如此多的请求，更不用说低带宽、高延迟的移动网络了，这将非常低效，并导致用户体验差。

这是一种更好的方法，因为客户端将在网络上对被称为API网关的前端服务器发出每个页面的少量请求，可能只有一个请求。

API 网关位于应用程序客户端和微服务之间，它提供了针对客户端量身定做的 API。API 网关为移动客户端提供粗粒度的API，为使用高性能网络的桌面客户端提供细粒度的 API。在此示例中, 桌面客户端发出多个请求以检索有关产品的信息, 而移动客户端则发出单个请求。

API 网关通过在高性能 LAN 上向一些微服务发出请求来处理传入的请求。在此示例中，来自桌面客户端的细粒度请求只是代理到相应的服务，而来自移动客户端的每个粗粒度请求都通过聚合调用多个服务的结果来进行处理的。

组件的分离为构建和维护高度可伸缩的需求，提供了更有效的环境。独立开发、独立部署的较小的服务更容易维护、修复和更新，从而为响应当今不断变化的环境提供更敏捷的功能。

    模块化

微服务以服务为单位;每个服务都有自己的边界，你不能简单地绕过边界，这样你就可以独立地开发、部署和扩展服务。

    特定于服务的数据库

微服务是松散耦合的，并且拥有自己的数据库，因此服务不会通过持有数据库锁来阻止其他服务。

    故障隔离

微服务体系结构具有更好的故障隔离;一个服务的问题不会影响其他服务，其他服务将继续正常工作。

    可伸缩性

在个人服务水平上的扩展变得更具有成本效益，并随需应变。可以并发地处理单个任务，而不会影响应用程序的其余部分。

分离应用程序的组件使单个错误或硬件故障导致整个系统瘫痪(消除单个故障点)的可能性降低。失败的进程可以被隔离，并且可以退出端点直到到达。

    技术/语言灵活性

每个单独的服务都可以基于开发人员的首选项、任务适用性或与某个库匹配的不同语言。

除此之外, 以下几点也是微服务的主要优势：

    微服务体系结构允许开发人员自由地独立开发和部署服务。
    小团队可以开发微服务。
    不同服务的代码可以用不同的语言编写。
    易于集成和自动部署（使用开源持续集成工具，如 Jenkins、Hudson 等）。
    易于理解和修改的开发人员，从而可以帮助一个新的团队变得高效快速。
    api可以更有效地进行版本控制，因为单个服务可以遵循自己的方案。主要版本可以在应用程序级别执行，而服务可以根据需要更新。
    将应用程序的组件分离开来，就不太可能出现单个错误或硬件故障导致整个系统瘫痪的情况。失败的进程可以被隔离，并且向下的端点可以被退休直到到达（消除单个故障点）。
    开发者可以使用最新的技术。
    围绕业务功能的代码。
    启动web容器更快，所以部署也更快。
    当应用程序的某个部分需要更改时，只能修改和重新部署相关的服务——不需要修改和重新部署整个应用程序。
    更好的故障隔离：如果一个微服务失败，另一个将继续工作（尽管一个整体应用程序的一个问题区域可能会危及整个系统）。
    易于扩展和与第三方服务集成。
    没有长期致力于技术栈。

将应用程序分离到独立的服务意味着现在有更多的活动组件需要维护。这也带来了一些挑战。

    复杂的业务流程

虽然微服务的一个主要优点是精简的编排功能，但更多的服务意味着要维护更多的部署流。DevOps 在这个模式中扮演着更为重要的角色，因为每个服务都必须在它的整个生命周期中正确地配置。

    服务间通信

分离的服务需要一种可靠、有效的方式来进行通信，同时又不会减慢整个应用程序的速度。通过网络交付数据会带来延迟和潜在的故障，这会影响用户体验。一种常见的方法是引入消息队列作为可靠的传输层。

    测试

虽然保持代码和依赖关系紧密意味着为特定服务提供更简单的开发环境，但它确实带来了与整个应用程序相关的测试挑战。服务通常需要相互通信，或者依赖于数据源或API。独立地测试一个服务将需要一个完整的测试环境才能有效。

    微服务体系结构带来了大量的操作开销。
    要求有 DevOps 技能。
    分布式系统管理起来很复杂。
    由于分布式部署，默认跟踪问题。随着服务数量的增加，整个产品的管理变得越来越复杂。

单体应用是用于构建企业应用程序的常用模式。它在小型应用程序中工作得相当好：开发、测试和部署小型单片应用程序相对简单。

然而，对于大型、复杂的应用程序，单块体系结构成为开发和部署的障碍。持续的交付是很难做到的，并且您常常被永久地锁定在你最初的技术选择上。对于大型应用程序，使用将应用程序分解为s组服务的微服务体系结构更有意义。

微服务体系结构有许多优点。例如，单个服务更容易理解，可以独立于其他服务进行开发和部署。使用新语言和框架也容易得多，因为你可以一次尝试一个服务的新技术。

微服务体系结构也有一些明显的缺陷。特别是，应用程序要复杂得多，并且有更多的活动部件。你需要高度自动化，例如PaaS，才能有效地使用微服务。

在开发微服务时，还需要处理一些复杂的分布式数据管理问题。尽管存在这些缺点，但对于快速发展的大型复杂应用程序（尤其是SaaS风格的应用程序）来说，微服务体系结构是有意义的。

有许多策略可以渐进地将现有的单体应用程序演化为微服务体系结构。开发人员应该将新功能作为独立的服务实现，并编写粘合代码将服务与单体集成。

迭代地识别组件以从整体中提取并转换为服务也是有意义的。虽然这种改进并不容易，但它比开发和维护一个笨重的单体应用程序要好。