微服务Microservices——应用架构的未来

能够构建、演变和扩展大型应用程序对于组织来说是至关重要的，但是所涉及的挑战使其成为一项困难的任务。正因为如此，微服务已经成为构建现代云应用的主导模式，它将单个组件分解为独立的服务，这些服务围绕着特定的业务功能。

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

虽然使用微服务可以使大型应用程序更易于管理，但是在任何场景中，构建一个可靠的分布式系统都是极具挑战性的，因为在处理失败、一致性和性能等方面有很多考虑因素。

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

关于领域（Domain）

SOA

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

在某些方面，SOA是分布式技术(如COM和CORBA)的进化。类似地，SOA强调服务和使用者(WSDL)和特定服务发现(UDDI)、传输(SOAP)、中介(WS-mediation)、路由(WS- addressing)、安全性(WS-security、WS-trust、WS- secure conversation等)以及分布式计算的其他方面之间的严格契约。此外，它非常强调通过企业存储库、服务生命周期管理和服务级别监视工具来设计、开发和操作服务治理。

1. 介绍

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

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

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

另一种方法是使用轻量级消息总线。用外行的话说，从微服务构建的应用程序的目标是尽可能地实现解耦和内聚。它们拥有各自的域逻辑，更像是过滤器——接收请求、适当地应用逻辑并生成响应。

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

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

Application Development Evolution

单层应用程序（Single Tier Applications）

在早期的进化过程中，这些应用被开发并部署为单个实体。这些应用程序的单个层很容易部署，因为它们只有一个代码库和部署配置。

这种应用程序的可扩展性是一个巨大的挑战，因为它只能通过复制整个应用程序来完成。这直接增加了业务的成本，并随着流量和负载的增加而浪费资源。

多层架构（Multi-Tier (or n-Tier)）

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

现在，当使用模式构建的应用程序增长时，它会对业务逻辑层造成压力，并导致monolith的许多缺点。同样，作为一个单个实体，可扩展性是具有挑战性和昂贵的。

Service Oriented Architecture (SOA)

SOA (SOA的发展)背后的想法是将应用程序视为业务功能。

随着越来越多的组织转向自动化/数字化，它已经成为业务的骨干，服务于快速变化的业务需求。这些快速变化的业务需求，使得开发人员开始将他们的应用程序看作是业务能力的集合，从而使组件比它们在栈中的位置更能隔离组件。例如，开发人员将创建一个处理用户身份验证的用户服务、一个处理账单的订单服务或一个处理发送电子邮件的通知服务。这样做可以提供更有效的可伸缩性，因为每个服务都更小、更专注。

虽然这个模式为构建有效的应用程序体系结构提供了框架，但是由于不必要的复杂抽象和遗留协议，它的实践通常是无效的。开发人员将尝试使用SOA来连接各种应用程序，这些应用程序都使用不同的语言，需要为企业服务总线提供额外的层。

这导致了陈旧的、昂贵的配置，而这些配置无法跟上技术和业务领域的发展。

2. Microservices – Artefacts

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

IT技术的演变极大地改变了全球商业的视角。在早期，它被认为是对企业/组织的帮助。最初，它用于减少业务功能/单元的手工工作。

如今，它被用来改造企业，创造更多的收入。所以现在它不仅仅是一个支持函数/责任，而是业务的主要功能线。

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

考虑应用程序架构的这种转变也引入了实践上的转变。Gartner进一步预测，“对于许多组织来说，迈向web规模IT未来的第一步应该是DevOps(开发操作)——以一种协调的方式将开发和操作结合在一起，以推动应用程序服务的快速、持续增量开发。”

通过使用web scale，组织可以更容易地构建类似于Amazon、谷歌和Facebook提供的应用程序和基础设施。它使他们能够在企业It环境中进一步拥抱云，将大型服务提供者的功能交付给内部用户。

与 SOA的区别

在定义特性方面，微服务模式比SOA更清晰，提供了满足现代应用程序体系结构需求的真实框架。微服务通常被称为“SOA做得好:”

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

微服务模式的目的不是将各种应用程序连接在一起，而是创建一个单一的、内聚的应用程序，该应用程序由独立开发和部署的服务组成，每个服务遵循单一的职责原则。但是，“微服务”一词可能会欺骗微服务的特性，因为规模不是微服务的定义特征。虽然通常很小，但重要的是每个服务都是它自己的封装过程，可以独立开发和部署。通过限制服务功能的范围，开发人员可以确保他们不会无意间得到许多解耦的整体。

与现代云一样，服务之间通过HTTP通过RESTful api进行通信，传递JSON数据，通常通过消息队列来确保可靠性。单个微服务通常是异步处理的，由事件(如API调用、push queue、schedule或webhook)触发。围绕通信和处理的轻量级、高效的框架进一步将微服务与SOA区分开来。

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

还有其他一些有规模的架构风格。《The Art of Scalability》（可扩展性的艺术）一书描述了一个非常有用的三维可扩展性模型，如下图所示。

在这个模型中，通常使用的方法是通过在负载均衡模块后面运行多个相同副本来扩展应用程序，称为x轴缩放。这是提高应用程序容量和可用性的好方法。

当使用z轴扩展时，每个服务器都运行相同的代码副本。在这方面，它类似于x轴缩放。最大的区别是，每个服务器只负责数据的一部分。z轴缩放，像x轴缩放，提高了应用程序的容量和可用性。

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

为了解决这些问题，我们需要应用y轴缩放

z轴缩放比例分割相似的东西，y轴缩放比例分割不同的东西。在应用程序层，y轴伸缩将一个单片应用程序分解为一组服务。

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

作为一种模式，微服务通过将功能元素分解为单独的服务来促进y轴可伸缩性，而不是传统的复制。

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

微服务架构 –通信机制

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

直接调用

一个应用程序客户端(如本机移动应用程序)可以向各个服务发出RESTful HTTP请求，如下图所示。

在单个服务的api和客户端所需的数据之间，可能会出现严重的粒度不匹配。

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

API 网关模式

这是一种更好的方法，因为客户端将会在每个页面上生成少量的请求，可能只有一页，通过internet到前端服务器(称为API网关)。

API网关位于应用程序的客户端和微服务之间。它提供为客户定制的api。API网关为移动客户端提供粗粒度的API，为使用高性能网络的桌面客户端提供细粒度的API。在本例中，桌面客户端发出多个请求来检索关于产品的信息，而移动客户端发出一个请求。

API网关通过在高性能LAN上请求一些微服务来处理传入的请求。在本例中，来自桌面客户端的细粒度请求被简单地代理到相应的服务，而来自移动客户端的每个粗粒度请求通过聚合调用多个服务的结果来处理。

3. 微服务的优势

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

模块化

微服务以服务为单位;每个服务都有其边界，您不能简单地绕过边界，以便能够独立地开发、部署和扩展服务。

Service-Specific Database

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

故障隔离

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

可伸缩性

在单个服务级别上的扩展变得更加有效，并且是按需的。可以并发地处理单个任务，而不影响应用程序的其余部分。

分离应用程序的组件可以减少单个bug或硬件故障导致整个系统崩溃的可能性(消除单个故障点)。失败的进程可以被隔离，并且在到达之前可以退出端点。

技术/语言的灵活性

每个单独的服务可以使用不同的语言，基于开发人员的偏好、任务适合性，或者匹配特定的库。

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

• 微服务体系结构为开发人员提供了独立开发和部署服务的自由。
• 小型团队就可以开发微服务。
• 不同服务的代码可以用不同的语言编写。
• 易于集成和自动部署(使用开源连续集成工具，如Jenkins, Hudson等)
• 对于开发人员来说，很容易理解和修改，因此可以帮助一个新团队快速高效地工作。
• 可以更有效地对API进行版本控制，因为各个服务可以遵循自己的方案。主要版本可以在应用程序级别完成，而服务可以根据需要进行更新。
• 分离应用程序的组件可以减少单个bug或硬件故障导致整个系统崩溃的可能性。失败的进程可以被隔离，下端点可以退役直到到达(消除单个失败点)。
• 开发人员可以利用最新的技术。
• 代码是围绕业务功能组织的。
• 启动web容器的速度更快，因此部署速度也更快。
• 当应用程序的某个部分需要更改时，只能修改和重新部署相关的服务——不需要修改和重新部署整个应用程序。
• 更好的故障隔离:如果一个微服务失败，另一个将继续工作(尽管单个应用程序的一个问题区域可能危及整个系统)。
• 易于扩展和与第三方服务集成。
• 不需要长期围绕一个技术栈。

4. Microservices的缺点

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

复杂的业务流程(Complex Orchestration)

虽然微服务的一个关键好处是它的简化编排功能，但更多的服务意味着保持更多的部署流。DevOps在这个模式中扮演了更重要的角色，因为每个服务必须在整个生命周期中正确配置。

服务间通信

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

测试

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

然后，独立测试一个服务需要一个完整的测试环境才能有效。

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

5. 结论

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

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

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

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

在开发微服务时，还需要处理一些复杂的分布式数据管理问题。尽管存在缺陷，微服务体系结构对于快速发展的大型、复杂应用程序是有意义的，特别是对于saas风格的应用程序。

有各种策略可以逐步地将现有的单体应用程序发展到微服务体系结构。开发应该实现作为独立服务的新功能，并编写胶水代码将服务与整体集成。

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

References

1. Fowler, Martin, and Lewis, James [25 March 2014] Microservice Architecture.
2. http://martinfowler.com/articles/Microservices.html
3. http://Microservices.io/patterns/Microservices.html
4. http://www.infoq.com/presentations/Micro-Services

请关注公众号:程序你好