共计 2954 个字符，预计需要花费 8 分钟才能阅读完成。
本系列为之前系列的整顿重启版，随着我的项目的倒退以及我的项目中的应用，之前系列外面很多货色产生了变动，并且还有一些货色之前系列并没有提到，所以重启这个系列重新整理下，欢送各位留言交换，谢谢！~
上图中演示了一个非常简单的微服务架构：
- 微服务会向注册核心进行注册。
- 微服务从注册核心读取服务实例列表。
- 基于读取到的服务实例列表，微服务之间相互调用。
- 内部拜访通过对立的 API 网关。
- API 网关从注册核心读取服务实例列表，依据拜访门路调用相应的微服务进行拜访。
在这个微服务架构中的每个过程须要实现的性能都在下图中：
接下来咱们一一剖析这个架构中的每个角色波及的性能、要思考的问题以及咱们这个系列应用的库。
每个微服务的根底性能包含：
- 输入日志 ，并且在 日志中输入链路追踪信息 。并且，随着业务压力越来越大，每个过程输入的日志可能越来越多，输入日志可能会成为性能瓶颈，咱们这里应用了 log4j2 异步日志，并且应用了 spring-cloud-sleuth 作为链路追踪 的外围依赖。
Http 容器：提供 Http 接口的容器，分为针对同步的 spring-mvc 以及针对异步的 spring-webflux 的：
- 对于 spring-mvc，默认的 Http 容器为 Tomcat。在高并发环境下，申请会有很多。咱们思考通过应用间接内存解决申请来缩小利用 GC 来优化性能，所以没有应用默认的 Tomcat，而是 应用 Undertow。
- 对于 spring-webflux，咱们间接应用 webflux 自身 作为 Http 容器，其实底层就是 reactor-http，再底层其实就是基于 Http 协定的 netty 服务器。自身就是异步响应式的，并且申请内存根本应用了间接内存。
- 微服务发现与注册 ：咱们应用了 Eureka 作为注册核心。咱们的集群平时有很多公布，须要 疾速感知实例的高低线 。同时咱们有很多套集群，每个集群服务实例节点数量是 100 个左右，如果 每个集群应用一个 Eureka 集群感觉有些节约 ，并且咱们心愿能有 一个间接治理所有集群节点的治理平台 。所以咱们 所有集群应用同一套 Eureka，然而通过框架配置保障 只有同一集群内的实例相互发现并调用。
- 健康检查：因为 K8s 须要过程提供健康检查接口，咱们应用 Spring Boot 的 actuator 性能，来作为健康检查接口。同时，咱们也通过 Http 裸露了其余 actuator 相干接口，例如动静批改日志级别，热重启等等。
- 指标采集：咱们通过 prometheus 实现过程外部指标采集，并且裸露了 actuator 接口供 grafana 以及 K8s 调用采集。
Http 客户端：外部微服务调用都是 Http 调用。每个微服务都须要 Http 客户端。在咱们这里 Http 客户端有：
- 对于同步的 spring-mvc，咱们个别应用 Open-feign，并且每个微服务本人保护本人微服务提供的 Open-feign 客户端。咱们个别不应用
@LoadBalanced注解的RestTemplate - 对于同步的 spring-flux，个别应用
WebClient进行调用。
- 对于同步的 spring-mvc，咱们个别应用 Open-feign，并且每个微服务本人保护本人微服务提供的 Open-feign 客户端。咱们个别不应用
- 负载平衡 ：很显著，Spring Cloud 中的负载平衡大多是 客户端负载平衡，咱们应用 spring-cloud-gateway 作为咱们的负载均衡器。
- 优雅敞开：咱们心愿微服务过程在收到敞开信号后，在注册核心标记本人为下线；同时收到的申请全副不解决，返回相似于 503 的状态码；并且在所有线程解决完手头的活之后，再退出，这就是优雅敞开。在 Spring Boot 2.3.x 之后，引入了这个性能，在咱们这个系列中也会用到。
另外还会有 重试机制，限流机制以及断路机制，这里咱们先来关怀最外围的针对调用其余微服务的 Http 客户端中的这些机制以及须要思考的问题。
来看几个场景：
1. 在线公布服务的时候，或者某个服务呈现问题下线的时候，旧服务实例曾经在注册核心下线并且实例曾经敞开，然而其余微服务本地有服务实例缓存或者正在应用这个服务实例进行调用，这时候个别会因为无奈建设 TCP 连贯而抛出一个 java.io.IOException，不同框架应用的是这个异样的不同子异样，然而提示信息个别有 connect time out 或者 no route to host。这时候如果重试，并且重试的实例不是这个实例而是失常的实例，就能调用胜利。如下图所示：
2. 当调用一个微服务返回了非 2XX 的响应码：
a) 4XX：在公布接口更新的时候，可能 调用方和被调用方都须要公布 。假如新的接口参数发生变化，没有兼容老的调用的时候，就会有异样， 个别是参数谬误，即返回 4XX 的响应码 。例如新的调用方调用老的被调用方。针对这种状况，重试能够解决。然而 为了保险，咱们对于这种申请曾经收回的，只重试 GET 办法（即查询方法，或者明确标注能够重试的非 GET 办法），对于非 GET 申请咱们不重试。如下图所示：
b) 5XX：当某个实例产生异样的时候，例如连不上数据库，JVM Stop-the-world 等等，就会有 5XX 的异样。针对这种状况，重试也能够解决。同样为了保险，咱们对于 这种申请曾经收回的，只重试 GET 办法（即查询方法，或者明确标注能够重试的非 GET 办法），对于非 GET 申请咱们不重 试。如下图所示：
3. 断路器关上的异样：前面咱们会晓得，咱们的断路器是针对微服务某个实例某个办法级别的，如果抛出了断路器关上的异样，申请其实并没有收回去，咱们能够间接重试。
这些场景在线上在线公布更新的时候，以及流量忽然到来导致某些实例呈现问题的时候，还是很常见的。如果没有重试，用户会常常看到异样页面，影响用户体验。所以这些场景下的重试还是很必要的。对于重试，咱们 应用 resilience4j 作为咱们整个框架实现重试机制的外围。
再看上面一个场景：
微服务 A 通过同一个线程池调用微服务 B 的所有实例。如果有一个实例有问题，阻塞了申请，或者是响应十分慢。那么长此以往，这个线程池会被发送到这个异样实例的申请而占满，然而实际上微服务 B 是有失常工作的实例的。
为了避免这种状况，也为了限度调用每个微服务实例的并发（也就是限流），咱们 应用不同线程池调用不同的微服务的不同实例 。这个也是 通过 resilience4j 实现 的。
如果一个实例在一段时间内压力过大导致申请慢，或者实例正在敞开，以及实例有问题导致申请响应大多是 500，那么即便咱们有重试机制，如果很多申请都是依照申请到有问题的实例 -> 失败 -> 重试其余实例，这样效率也是很低的。这就须要应用 断路器。
在理论利用中咱们发现，大部分异常情况下，是某个微服务的某些实例的某些接口有异样，而这些问题实例上的其余接口往往是可用的。所以咱们的断路器 不能间接将这个实例整个断路，更不能将整个微服务断路 。所以，咱们应用 resilience4j 实现的是 微服务实例办法级别 的断路器（即不同微服务，不同实例的不同办法是不同的断路器）。
本大节咱们提出了一个简略的微服务架构，并仔细分析了其微服务实例的波及的公共组件应用的库以及须要思考的问题，并且针对微服务调用的外围 Http 客户端的重试机制，线程隔离机制和断路器机制须要思考的问题以及如何设计做了较为具体的阐明。接下来咱们持续剖析对于 Eureka 注册核心以及 API 网关设计须要思考的机制。
微信搜寻“我的编程喵”关注公众号，每日一刷，轻松晋升技术，斩获各种 offer：
