微服务架构最佳实践 - 基础设施篇
作者：互联网
极客时间：《从 0 开始学架构》:微服务架构最佳实践 - 基础设施篇
每项微服务基础设施都是一个平台、一个系统、一个解决方案，如果自己实现，其过程都需要经过需求分析、开发测试、部署上线等步骤。
自动化测试
微服务将原本大一统的系统拆分为多个独立运行的“微”服务，微服务之间的接口数量增加，并且微服务提倡快速交付，版本周期短，版本更新频繁。因此必须通过自动化测试系统来完成绝大部分的测试回归工作。
自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。
自动化部署
微服务部署频率会大大增加，部署次数会使大一统系统部署次数的几十倍，如果要人工手动部署，需要投入大量的人力，并且容易出错，因此需要自动化部署的系统来完成部署操作。
自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能。
配置中心
微服务的节点数量非常多，通过人工登录每台机器手工修改，效率低，容易出错。微服务需要一个统一的配置中心来管理所有微服务节点的配置。
配置中心包括配置版本管理、增删改查配置、节点管理、配置同步、配置推送等功能。
接口框架
微服务提倡轻量级的通信方式，一般采用 HTTP/REST 或者 RPC 方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。
但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。
API网关
系统拆分为微服务后，内部的微服务之间是互联互通的，相互之间的访问都是点对点的。
微服务需要一个统一的 API 网关，负责外部系统的访问操作。
API 网关是外部系统访问的接口，所有的外部系统接⼊系统都需要通过 API 网关，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能。
服务发现
需要一套服务发现的系统来支撑微服务的自动注册和发现。
服务发现主要有两种实现方式：自理式和代理式。
- 1、自理式
自理式结构如下：
自理式结构就是指每个微服务自己完成服务发现
该部分的功能一般都通过统一的程序库或者程序包提供给各个微服务调用，而不会每个微服务都自己来重复实现一遍；并且每个微服务都成端了服务发现的功能，访问压力分散到了各个微服务节点，性能和可用性上不存在明显的压力和风险。 - 2、代理式
代理式结构如下：
代理式结构就是指微服务之间有一个负载均衡系统（图中的 LOAD BALANCER 节点），由负载均衡系统来完成微服务之间的服务发现。
实际中该方案存在风险较大：
- 可用性风险：一旦LOAD BALANCER系统故障，就会影响到所有微服务之间的调用
- 性能风险：所有的服务之间的流量调用都需要经过LOAD BALANCER系统，性能压力会随着微服务数量和流量增加而不断增加，最后成为性能瓶颈
因此，LOAD BALANCER系统需要设计成集群的模式，但集群实现又增加了复杂性
不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或者 LOAD BALANCER 系统到服务注册表查询可用服务。
服务路由
服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。对于自理式服务发现，服务路由是微服务内部实现的；对于代理式服务发现，服务路由是由 LOAD BALANCER 系统实现的。无论放在哪里实现，服务路由核心的功能就是路由算法。常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等。
服务容错
常见的服务容错包括请求重试、流控和服务隔离。通常情况下，服务容错会集成在服务发现和服务路由系统中。
服务监控
服务监控的主要作用有：
- 实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间。
- 服务监控可以在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低了问题影响的范围和时间。
通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现、API 网关等系统中。
服务安全
服务安全主要分为三部分：接入安全、数据安全、传输安全。通常情况下，服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理。由于这些策略是通用的，一般会把策略封装成通用的库提供给各个微服务调用。基本架构如下：
标签：LOAD,服务,基础设施,配置,系统,BALANCER,最佳,架构,路由 来源： https://www.cnblogs.com/whiteBear/p/15836672.html