《Spring Cloud微服务架构进阶》——1.1.3　微服务架构

1.1.3　微服务架构

微服务最早是由Martin Fowler与James Lewis于2014年共同提出，需要了解细节的读者可以阅览https://martinfowler.com/articles/microservices.html。其实Martin先生并没有给出明确的微服务定义，根据其描述，微服务的定义可以概括如下：微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信（通常是HTTP API）；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。

如今，微服务架构已经不是一个新概念了，很多业界前沿互联网公司的实践表明，微服务是一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段。

1.组成

微服务架构是一种比较复杂、内涵丰富的架构模式，它包含很多支撑“微”服务的具体组件和概念，其中一些常用的组件及其概念如下：

服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。

负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。

服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。

配置中心：将本地化的配置信息（Properties、XML、YAML等形式）注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移。

集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。

调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。

支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能健康等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效。

2.优点

微服务架构模式有很多优势可以有效解决单体应用扩大之后出现的大部分问题。首先，通过将巨大单体式应用分解为多个服务的方法解决了复杂性问题。在功能不变的情况下，应用分解为多个可管理的模块或服务。每个服务都有一个用RPC或者消息驱动API定义清楚的边界。微服务架构模式为采用单体式编码方式很难实现的功能提供了模块化的解决方案。由此，单个服务变得很容易开发、理解和维护。

其次，微服务架构模式使得团队并行开发得以推进，每个服务都可以由专门开发团队来开发。不同团队的开发者可以自由选择开发技术，提供API服务。这种自由意味着开发者不需要被迫使用之前采用的过时技术，他们可以选择最新的技术。甚至于，因为服务都是相对简单的，即使用新技术重写以前的代码也不是很困难的事情。

再次，微服务架构模式中每个微服务独立都是部署的。理想情况下，开发者不需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速地部署变化。微服务架构模式使得持续化部署成为可能。

最后，微服务架构模式使得每个服务易于独立扩展。

3.挑战

微服务的一些想法是好的，但在实践中也会呈现出其复杂性，具体如下：

运维要求较高。更多的服务意味着需要更多的运维投入。在单体架构中只需要保证一个应用的正常运行即可；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，这带来了巨大的挑战。

分布式固有的复杂性。使用微服务构建的是分布式系统。对于一个分布式系统来说，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

接口调整成本高。微服务之间通过接口进行通信。如果修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整。

重复劳动。很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，导致代码重复。

可测试性的挑战。在动态环境下，服务间的交互会产生非常微妙的行为，难以进行可视化及全面测试。