经过微服务来正确实施SOA

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

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

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

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

SOA：面向服务的架构

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

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

Introduction

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

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

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

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

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

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

应用程序的发展演变

单层应用程序

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

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

多层 (或 n 层)

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

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

面向服务的体系结构 (SOA)

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

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

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

Microservices——Artefacts

为何是微服务——新模式？

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 专一于独立的技术系统, 微服务专一于独立的业务系统。

微服务模式的目标不是将各类应用程序链接在一块儿，而是建立一个由独立开发、独立部署的服务，组成的单1、聚合的应用程序，每一个服务都遵循单一职责原则。然而，“微”这个表述，对于微服务的特性来讲，可能会具备一点儿欺骗性，由于大小并非微服务定义的特征。虽然微服务一般很小，但更重要的是每一个服务本身封装的流程能够独立开发和部署。开发人员经过限制一个服务可作的事情范围，来确保这些服务不会无心中和许多解耦的单体一块儿结束。

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

将应用程序分解为多个服务

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

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

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

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

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

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

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

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

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

微服务体系结构–通讯机制

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

直接调用

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

单个服务的 API

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

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

API 网关模式

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

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

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

Advantages of Microservices

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

模块化

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

    特定于服务的数据库

微服务是松散耦合的，而且拥有本身的数据库，所以服务不会经过持有数据库锁来阻止其余服务。

    故障隔离

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

    可伸缩性

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

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

    技术/语言灵活性

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

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

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

Drawbacks of Microservices

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

复杂的业务流程

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

    服务间通讯

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

    测试

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

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

结论

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

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

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

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

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

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

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