第84篇

极客时间《从0开始学架构》课程笔记。

每项微服务基础设施都是一个平台、一个系统、一个解决方案，若需自己实现都需要经过需求分析、架构设计、开发、测试、部署上线等步骤。

微服务架构3个核心之中，真正能决定微服务成败的，就是『automated』，因为基础设施是微服务可以落地的基础，没有这个基础，所有的服务拆分都是纸上谈兵。

基础设施根据建设优先级，11种基础设施共分为4类：

一、基本基础设施

服务发现

• 为了实现节点的变化能够及时同步到所有其他依赖的微服务，需要一套服务发现系统来支撑微服务的自动注册和发现
• 服务发现主要有两种实现方式：自理式和代理式。自理式结构就是指每个微服务自己完成服务发现；代理式结构就是指微服务之间有一个负载均衡系统，由负载均衡系统来完成微服务之间的服务发现
• 自理式服务实现比较简单，一般通过统一程序包提供给各个服务调用，并且访问压力分散在各个微服务节点，性能和可用性没有明显压力和风险
• 代理式服务新增了负载均衡系统，虽然降低了微服务本身的实现难度，但相应增加了可用性风险和性能风险
• 服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或者 负载均衡系统到服务注册表查询可用服务

服务路由

• 在具体进行某次调用请求时从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求，就是服务路由的功能
• 服务路由和服务发现紧密相关，一般放在一起实现
• 服务路由的核心就是路由算法，常见的有：随机路由、轮询路由、最小压力路由、最小连续数路由等

服务容错

• 微服务节点数增加的同时，微服务出故障的概率也会增加，从而出现故障扩散现象
• 故障若不及时处理，故障扩散后很多服务节点都会出现故障，所以需要自动应对出错场景，及时处理
• 常见的服务容错包括请求重试、流量控制盒服务隔离；一般情况下服务容错会集成在服务发现和服务路由系统中

二、提升开发效率

接口框架

• 微服务提倡轻量级的通信方式，一般采用 HTTP/REST 或者 RPC 方式统一接口协议
• 除了统一接口协议，还需要统一接口传递的数据格式，比如指定数据格式采用JSON，且JSON数据需遵循规范
• 接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有微服务调用

API网关

• 为了便于外部系统调用系统的某个功能，隔离微服务之间的分工和边界，并且对外统一提供安全和权限相关的能力，需要提供一个统一的API网关，专门负责外部系统的访问
• API网关主要包括接入鉴权、权限控制、传输加密、请求路由、流量控制等

三、提升测试和运维效率

自动化测试

• 微服务之间的接口数量增多，且需要快速交付，所以必须通过自动化测试系统
• 自动化测试需要涵盖代码级的单元测试、单个系统级的集成测试、系统间的接口测试，最低要求是至少做到接口测试自动化

自动化部署

• 除了接口，微服务需要部署的节点也增加了，部署的频率也会大幅提升
• 人工手工处理方式无法满足，且非常容易出错，所以需要自动化部署系统
• 自动化部署系统包括版本管理、资源管理（机器、虚拟机）、部署操作、回退操作等

配置中心

• 微服务节点数量太多，采用人工方式修改配置效率低易出错，且部署和排障时需要快速增删改查配置
• 有时在运行期间配置需要动态修改并且所有节点即时生效，人工操作无法实现
• 配置中心包括配置版本管理、增删改查配置、节点管理、配置同步、配置推送等

四、进一步提高运维效率

服务监控

• 随着节点数量的增加，需要监控的对象数量相应大大增加，而且出现故障时，需要快速根据各类信息来定位故障，所以需要服务监控系统实现微服务节点的监控
• 服务监控的作用主要是 实时搜集信息并进行分析，避免故障后再分析，减少了处理时间；另外服务监控还可以实现预警，在问题萌芽阶段发现并告警
• 服务监控系统建议做成独立系统，而不是集成到服务发现、API网关等系统中

服务跟踪

• 服务监控与服务跟踪的区别：服务监控记录的数据偏宏观，如请求次数、响应时间平均值、最高值等；服务跟踪记录的数据偏微观，如请求的发起时间、响应时间、响应错误码、请求参数等
• 目前绝大部分请求跟踪的实现技术都是基于Dapper论文

服务安全

• 从业务角度考虑，部分敏感数据或操作，只能有部分微服务可以访问，因此需要设计服务安全机制
• 服务安全主要分3部分：接入安全、数据安全、传输安全
• 一般情况下服务安全可以集成在配置中心系统中实现