微服务架构最佳实践

• 避免非核心服务故障影响核心服务

例如，日志上报一般都属于非核心服务，但是在某些场景下可能有大量的日志上报，如果系统没有拆分，那么日志上报可能导致核心服务故障；拆分后即使日志上报有问题，也不会影响核心服务

• 核心服务高可用方案可以更加单

核心服务的功能逻辑更加简单，存储的数据可能更少，用到的组件也会更少，设计高可用方案部分情况下要比不拆分简单很多

• 能够降低高可用成本

将核心服务拆分出来后，核心服务占用的机器、带宽等资源比不拆分要少很多。因此，只针对核心服务做高可用方案，机器、带宽等成本比不拆分要节省较多

4. 基于性能拆分

• 将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务
• 常见的拆分方式和具体的性能瓶颈有关，可以拆分Web服务、数据库、缓存等
• 例如，电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务

以上拆分，可以根据实际情况自由排列组合

基础设施

• “automated”是重要一环，如果其相关的基础设施不健全，那微服务就是焦油坑，让研发，测试，运维陷入各种陷阱中
• 微服务基础设施如下图所示

实施微服务

• 有开源的微服务基础设施全家桶，例如，Spring Cloud项目，涵盖了服务发现、服务路由、网关、配置中心等功能
• 如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的

按优先级来搭建基础设施

• 1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施
• 2. 接口框架、API网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API网关是为了提升与外部服务对接的效率
• 3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率
• 4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率
• 以上3和4两类基础设施，其重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑，虽然效率不高，但也基本能够顶住

基础设施

自动化测试

• 微服务将原本大一统的系统拆分为多个独立运行的“微”服务，微服务之间的接口数量大大增加，并且微服务提倡快速交付，版本周期短，版本更新频繁
• 如果每次更新都靠人工回归整个系统，则工作量大，效率低下，达不到“快速交付”的目的，因此必须通过自动化测试系统来完成绝大部分测试回归的工作中
• 自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都是自动化
• 因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化

自动化部署

• 相比大一统的系统，微服务需要部署的节点增加了几倍甚至十几倍，微服务部署的频率也会大幅提升（例如，我们的业务系统70%的工作日都部署操作），综合计算下来，微服务部署的次数是大一统系统部署次数的几十倍
• 这么大的部署操作，如果继续采用人工手工处理，需要投入大量的人力，且容易出错，因此需要自动化部署的系统来完成部署操作
• 自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能

配置中心

• 微服务的节点数量非常多，通过人工登录每台机器手工修改，效率低，容易出错
• 特别是部署或者排障时，需要快速增删改查配置，人工操作的方式显然是不行的
• 有的运行期配置需要动态修改并且所有节点即时生效，人工操作是无法做到的
• 综上，微服务需要一个统一的配置中心来管理所有微服务节点的配置
• 配置中心包括配置版本管理（例如，同样的微服务，有10个节点是给移动用户服务的，有20个节点给联通用户服务的，配置项都一样，配置值不一样）、增删改查配置、节点配置、配置同步、配置推送等功能

接口框架

• 微服务提倡轻量级的通信方式，一般采用HTTP/REST或者RPC方式统一接口协议
• 但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式
• 例如，我们需要指定接口协议为HTTP/REST，但这还不够，还需要指定HTTP/REST的数据格式采用JSON，并且JSON的数据都遵循如下规范。

• 如果我们只是简单指定了HTTP/REST协议，而不指定JSON和JSON的数据规范，那么就会出现这样混乱的情况：有的微服务采用XML，有的采用JSON，有的采用键值对；即使同样都是JSON，JSON数据格式也不一样。这样每个微服务都要适配几套甚至几十套接口协议，相当于把曾经由ESB做的事情转交给微服务自己做了，这样做的效率显然是无法接受的，因此需要统一接口框架
• 接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有微服务调用。例如，针对上面的JSON样例，可以由某个基础技术团队提供多种不同语言的解析包（Java包、 Python 包 、C库等）

API网关

• 系统拆分为微服务后，内部的微服务之间是互联互通的，相互之间的访问都是点对点的
• 如果外部系统想调用系统的某个功能，也采取点对点的方式，则外部系统会非常“头大”
• 因为在外部系统看来，它不需要也没办法理解这么多微服务的职责分工和边界，它只会关注它需要的能力，而不会关注这个能力应该由哪个微服务提供
• 外部系统访问系统还涉及安全和权限相关的限制，如果外部系统直接访问某个微服务，则意味着每个微服务都要自己实现安全和权限的功能，这样做不但工作量大，而且都是重复工作
• 综合上面的分析，微服务需要一个统一的API网关，负责外部系统的访问操作
• API网关是外部系统访问的接口，所有的外部系统接入系统都需要通过API网关，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能

服务发现

• 微服务种类和数量很多，如果这些信息全部通过手工配置的方式写入各个微服务节点，首先配置工作量大，配置文件可能要配几百上千行，几十个节点加起来后配置项就是几万几十万行了，人工维护这么大数量的配置项是一项灾难
• 其次是微服务节点经常变化，可能是由于扩容导致节点增加，也可能是故障处理时隔离掉一部分节点，还可能是采用灰度升级，先将一部分节点升级到新版本，然后让新老版本同时运行
• 不管哪种情况，我们都希望节点的变化能够及时同步到所有其他依赖的微服务。如果采用手工配置，是不可能做到实时更改生效的
• 因此，需要一套服务发现的系统来支撑微服务的自动注册和发现

服务发现主要有两种实现方式：自理式和代理式

1. 自理式

• 自理式结构如下：

• 自理式结构就是指每个微服务自己完成服务发现。例如，图中SERVICE INSTANCE A访问SERVICE REGISTRY获取服务注册信息，然后直接访问SERVICE INSTANCE B
• 自理式服务发现实现比较简单，因为这部分的功能一般通过统一的程序库或者程序包提供给各个微服务调用，而不会每个微服务都自己来重复实现一遍；并且由于每个微服务都承担了服务发现的功能，访问压力分散到了各个微服务节点，性能和可用性上不存在明显的压力和风险

2. 代理式

• 代理式结构如下：

• 代理式结构就是指微服务之间有一个负载均衡系统，由负载均衡系统来完成微服务之间的服务发现
• 代理式的方式看起来更加清晰，微服务本身的实现也简单了很多，但实际上这个方案风险较大
• 第一个风险是可用性风险，一旦LOAD BALANCER系统故障，就会影响所有微服务之间的调用
• 第二个风险是性能风险，所有的微服务之间的调用流量都要经过LOAD BALANCER系统，性能压力会随着微服务数量和流量增加而不断增加，最后成为性能瓶颈
• 因此LOAD BALANCER系统需要设计成集群的模式，但LOAD BALANCER集群的实现本身又增加了复杂性
• 不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或者LOAD BALANCER系统到服务注册表查询可用服务

服务路由

• 有了服务发现之后，微服务之间能够方便地获取相关配置信息，但具体进行某次调用请求时，我们还需要从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求，这就是服务路由需要完成的功能
• 服务路由和服务发现紧密相关，服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的
• 对于自理式服务发现，服务路由是微服务内部实现的；对于代理式服务发现，服务路由是由LOAD BALANCER系统实现的
• 无论放在哪里实现，服务路由核心的功能就是路由算法。常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等