1、概述

微服务架构模式作为替代单体应用和面向服务架构的一个可行的选择，在业内迅速取得进展。由于这个架构模式仍然在不断的发展中，在业界存在很多困惑——这种模式关乎什么？它是如何实现的？本报告将为你提供关键概念和必要的基础知识来理解这一重要架构模式的好处与取舍，以此来判断这种架构是否适合你的应用。

2、模式描述

不管你选择哪种架构实现，有几种常见的核心概念适用于该架构模式。

2.1、独立部署单元

微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通讯，同时它还具有很强的扩展性，应用和组件之间高度解耦，这使得部署更为简单。

独立部署单元

要理解这个模式的最重要的概念是服务组件。不要考虑微服务架构内的服务，而是转而考虑微服务向外暴露的服务。从粒度上讲它可以小到单一的模块，或者大到一个应用程序。

在微服务架构中，正确设计服务组件的粒度是一个很大的挑战，在接下去的服务组件部分将对这一挑战进行了详细的讨论。

2.2、分布式架构

微服务架构模式的另一个关键概念是它是一个分布式架构，这意味着架构内部的所有组件之间是完全解耦的，并可以通过某种远程访问协议进行（如：JMS, AMQP, REST, SOAP, RMI等）访问。这种架构的分布式特性，正是去实现可扩展性和易于部署特性的关键。

2.3、架构演变来源

微服务架构一个显著特性是：它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。

2.3.1、单体应用的演变过程

单体应用：一个应用就是一个整体。

由单体应用到微服务的发展过程主要是由持续交付开发促成的，这是提出了从开发到持续部署的概念，微服务架构简化了应用程序的部署过程。

单体应用通常是由紧耦合的组件组成的，这些组件同时又是另一个单一可部署的单元的一部分，这使得它繁琐、难以改变、测试和部署应用。这些因素会导致应用变得脆弱以至于每次有一点新功能部署后，应用就不能正常运行。

微服务架构通过将应用分割成多个可独立部署的单元（服务组件）来解决该问题，这些服务组件可以独立于其他服务组件进行开发、测试、部署。

2.3.2、SOA 应用的演变过程

SOA 模式非常强大，它提供了无与伦比的抽象级别、异构连接、服务编排，可同时也是异常复杂、昂贵、很难被理解和实现，因而对于大多数应用程序来说过犹不及。

微服务架构通过简化服务概念、消除服务编排、简化服务组件连接和访问来解决复杂度问题。

3、模式实现

虽然有很多方法来实现微服务架构，这里提出三个脱颖而出的案例。

• 基于 REST API 的结构
• 基于 REST 应用的结构
• 集中式消息结构

3.1、基于 REST API 的结构

基于 REST API 非常适用于通过对外提供小型、自包含的服务，通常这些服务由粒度非常细的服务组件组成（因此得名为微服务架构），这些服务组件通过组合一个或多个独立服务组件对外暴露特定业务。

基于 REST API 的结构

此种拓扑的例子包含一些常用的专用的基于云的 RESTFUL WEB SERVICE，像 Yahoo、Google、Amazon 都在使用该种架构模式。

3.2、基于 REST 应用的拓扑结构

基于 REST 的应用与基于 REST API 的略有不同，它是通过传统的基于客户端（Web、Android、iOS 等）业务应用来接收客户端的请求，而不是简单的 API 层。

基于 REST 应用的结构

在基于 REST 的应用中，服务组件是一个具备交互界面的独立的服务组件。此时服务组件向外提供业务接口，而调用方依旧可通过各种远程访问协议与服务组件进行通讯。它与基于 REST API 的服务相比，最显著的不同是：它的服务组件更大、粒度更粗、且代表了应用程序的一小部分。

它往往可见于企业内部的技术（产品）组件库中，通过暴露服务向企业内部提供服务。

3.3、集中式消息拓扑结构

集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的逻辑控制的应用程序中。

集中式消息结构

该结构对比之前基于 REST 的结构，其好处是有排队机制、异步消息传递、监控、错误处理和更好的负载均衡与扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟解决。

代理联盟：将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理。

4、避免依赖与编排

微服务架构模式的主要挑战之一是：决定服务组件的粒度级别。如果服务组件粒度过粗，你可能很难意识到该架构带来的部署、可扩展性、可测试性和松耦合。然而服务组件粒度过细，则很快会将微服务架构模式演变成一个复杂、容易混淆、代价昂贵并易于出错的重量级面向服务架构。

粒度太细的几种情况：

• 当你发现需要从应用程序内部编排服务组件时；
• 当你发现需要在服务组件之间通讯，才能处理单个业务请求时；

如果你发现就算不考虑服务组件粒度的级别，你仍然不能避免服务编排，这可能微服务架构可能并不适用于你的应用。由于这种模式的分布性特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务，这对于相对简单而优雅的微服务架构来说显著增加了复杂性。

5、注意事项

微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的、单独部署单元，使用微服务架构模式构建的应用程序通常更健壮，并提供更好的可扩展性，支持持续交付也更容易。

该模式的另一个优点是，它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署，一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。

最后一个要重视的考虑是，由于微服务架构模式是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题。包括：约定的创建、维护、管理、远程系统的可用性、远程访问身份验证和授权。

6、模式总结

关注点	�可用性	描述
易于部署	高	整体来讲，由于该模式的解耦特性和事件处理组件使得部署变得相对简单。broker拓扑往往比mediator拓扑更易于部署，主要是因为event-mediator组件与事件处理器是紧耦合的，事件处理器组件有一个变化可能导致event mediator跟着变化，有任何变化两者都需要部署。
整体灵活性	高	整体的灵活性是能够快速响应不断变化的环境。由于单独部署单元的概念,变化通常被隔离成单独的服务组件,使得部署变得快而简单。同时，使用这种模式构建的应用往往是松耦合的，也有助于促进改变。
可测试性	高	由于业务功能被分离成独立的应用模块,可以在局部范围内进行测试，这样测试工作就更有针对性。对一个特定的服务组件进行回归测试比对整个单体应用程序进行回归测试更简单、更可行。而且,由于这种模式的服务组件是松散耦合的，从开发角度来看，由一个变化导致应用其他部分也跟着变化的几率很小，并能减小由于一个微小的变化而不得不对整个应用程序进行测试的负担。
性能	低	虽然你可以从实现该模式来创建应用程序并可以很好的运行，整体来说，由于微服务架构模式的分布式特性，并不适用于高性能的应用程序。
伸缩性	高	由于应用程序被分为单独的部署单元,每个服务组件可以单独扩展，并允许对应用程序进行扩展调整。例如，股票交易的管理员功能区域可能不需要扩展，因为使用该功能的用户很少，但是交易布局服务组件可能需要扩展，因为大多数交易应用程序需要具备处理高吞吐量的功能。
易于开发	高	由于功能被分隔成不同的服务组件，由于开发范围更小且被隔离，开发变得更简单。程序员在一个服务组件做出一个变化影响其他服务组件的几率是很小的，从而减少开发人员或开发团队之间的协调。

---

参考资料 软件架构模式