微服务架构概念的复盘

一概述

微服务的定义可以概况为：微服务架构是一种使用一系列粒度较小的服务来开发当个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信，一般是指通Http协议的API；这些服务是基于业务逻辑和范围，通过自动化的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的变成语言编写，使用不同的数据存储技术。

微服务架构是一种比较复杂，内涵丰富的架构模式，它包含很多支撑"微"服务的具体组件和概念。

二 微服务用的组件及其概念

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

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

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

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

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

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

 三 微服务架构的优点

微服务架构模式有很多优势可以有效解决当体应用扩大后出现的大部分问题。首先，通过将巨大单体应用分解为多个服务的方法解决了复杂性问题。在功能不变的情况下，应用分解为多个可管理的模块或服务。每个服务都有一个用RPC或者消息驱动API定义的边界。

微服务架构模式为采用单体式编码方式很难实现的功能提供了模块化的解决方案。由此，当个服务变得很容易开发，理解和维护。

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

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

微服务架构模式的出现使得每个服务易于独立扩展。

四 微服务架构的不足

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

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

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

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

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