《软件架构模式》-第四章 微服务框架模式（上）

原文地址  译者：克里斯托刘

微服务架构模式正在迅速成为行业中单一应用程序及面向服务架构的可行的解决方案。因为这个架构模式仍在不断发展，关于这种模式的定义和其实现方式还有很多困惑之处。本章将为您解释其关键概念和基础知识，以理解这种模式的优点以及是否适合您的应用程序。

模式描述

无论选择的拓扑或实施方式如何，有许多普遍的核心概念是适用于所有的该架构模式。第一个概念是独立部署单元。如图4-1所示，每个微服务架构的组件都部署为一个独立的单元，这达到了以下优点：部署简单（通过高效和流水交付管道）、可扩展性增加、以及高度的应用和组件在应用程序内的解耦。

也许帮助理解这种模式的最重要的概念是服务组件(service component)。 考虑服务组件可以从不同粒度上入手：从一个简单的模块到一个大型的应用范围内考量，而不仅仅思考微服务架构中的服务组件。服务组件可包含一个或多个模块（例如Java类），如代表一个单一用途的功能（例如，提供天气为特定的城市或城镇）或一个大型商业应用程序的独立模块（例如股票交易安排或汽车保险率计算模块）。 给服务组件设计好粒度级别是微服务架构中最大的挑战之一。以下会详细讨论这一难点。

微服务架构模式中的另一个关键概念是它是一个分布式架构，意味着架构内所有的组件完全彼此解耦并通过某种远程访问协议互相访问（如JMS、AMQP、REST、SOAP、RMI等）。 这种分布式的特征是架构有很好的可扩展性和易部署特征的原因。

一个关于微服务架构的令人兴奋事情是，它是从解决其他常见架构的问题演变而来，而不是创建用来解决一个新问题。微服务架构风格由两种主要来源进化而来：使用分层架构模式的单体应用程序和面向服务架构开发的分布式应用程序。

从单体应用到微服务的演进路径，主要通过开发连续交付方式、连续的从开发到生产的部署管道概念，这些简化应用程序的部署的办法而来。单体应用通常由紧密耦合的组件组成，它们是单个部署单元的一部分，这使其变得繁琐且难以改变、测试和部署应用程序（因此，会发现在大多数大型IT应用商店中，单体应用程序通常“每月部署”周期会不断增加）。这些因素通常导致应用程序间断性，即因为每次部署新特性时都要中断。 微服务架构模式通过分离应用程序到多个可部署的单元（服务组件）中来解决这些问题，这些组件可以独立开发、测试和部署。

促成微服务架构的另一个演化路径来自面向服务的架构模式（SOA）实现中发现的问题。虽然SOA模式是非常强大的，它可以提供无与伦比的抽象层次，复杂连接(heterogeneous connectivity)，服务编排和可达成业务目标与IT服务能力一致性，但它很复杂、昂贵、无处不在、难以理解和实施的且对于大多数应用程序来说是不必要的。微服务架构风格通过简化服务概念、消除编排需求、简化连接和访问服务组件来解决这一复杂性。

模式的拓扑结构

虽然有很多方式去实现微服务框架，主要有三种最为常见和受欢迎：基于REST拓扑结构的API、基于REST拓扑的应用和消息队列。

基于REST API的拓扑结构对于一些通过API提供小型、自给自足的单个服务的网站很有用。如图4-2所示，这种拓扑结构由排布好的服务组件组成（因此得名微服务），这些服务组件包含一个或两个执行特定业务功能的模块，这些业务功能是和其他业务独立的。在这种拓扑中，这些排布好的服务组件通常使用基于REST的接口进行访问，具体通过单独部署的基于Web的API层实现。这种拓扑结构的例子包括一些常见的如雅虎，谷歌，谷歌等公司创建的基于云的RESTful Web单个服务。

基于REST 应用的拓扑结构与基于REST API拓扑结构不同在于，它是通过基于网络或客户端业务应用界面的传统方式接收客户请求，而不是通过一个简单的API层。如图4-3所示，应用程序的用户接口层被单独部署成一个独立的Web应用，它会远程访问单独部署的服务组件（业务功能）通过简单的基于REST的接口。这种拓扑中的服务组件与基于API-Rest拓扑的服务组件不同在于，它的服务组件通常更大、更粗糙并只代表了整个业务的一小部分功能，而不是细粒度的、一步作业服务。 这种拓扑对于中小型企业而言很常见，它普遍具有相对较低复杂度。

微服务架构中的另一种常见方法是集中式消息队列。 这种拓扑结构（如图4-4）与基于REST API的拓扑结构类似，不同点在于，它不使用REST进行远程访问，而使用轻量级集中式消息代理方式（如ActiveMQ、HornetQ等）。当看待该拓扑结构时，很重要一个点是不要将其与面向服务的体系结构混淆或将其视为“SOA-Lite”。该拓扑结构不会执行任何编排、转换或复杂的路由，相反，它只是一个轻量级的运输工具去访问远程服务组件。

集中式消息队列拓扑结构通常可运用在大型商业应用中或需要更复杂地控制用户接口和服务组件的传输层的情况下。这种拓扑的好处是拥有先进的队列机制、异步消息、监控、错处处理方式和更好的总体负载平衡性和可扩展性。 该拓扑结构中，中央消息代理（broker）相关的单点失败和架构瓶颈的问题，可以通过代理分类、代理联合（基于系统功能区域，将单个经纪人实例拆分成多个经纪人实例，去分解消息吞吐量负载）解决。