feat(post): 完善文章

blog-site/content/posts/java/javaessay/微服务治理详解.md

@@ -36,20 +36,20 @@ slug: "distributed-small-service"
 > 链接：[https://blog.csdn.net/qq_31960623/article/details/119840131](https://blog.csdn.net/qq_31960623/article/details/119840131)
 
 ## 从单体架构迁移到微服务架构
-重写代码，但是不要大规模重写代码，重写代码听起来很好但风险较大，如果大规模重写代码可能会导致程序出现各种各样的bug;(当你承担重建一套全新基于微服务的应用程序不需要使用时候，可以采用重写这种方法)
+重写代码，但是不要大规模重写代码，重写代码听起来很好但风险较大，如果大规模重写代码可能会导致程序出现各种各样的bug；(当你承担重建一套全新基于微服务的应用程序不需要使用时候，可以采用重写这种方法)
 
-逐步迁移单体应用的功能，独立出来形成新的微服务，同时需要与旧的单体应用集成，这可以保证系统的正常运行，单体式应用在整个架构中比例逐渐下降直到消失或者成为微服务架构一部分;
+逐步迁移单体应用的功能，独立出来形成新的微服务，同时需要与旧的单体应用集成，这可以保证系统的正常运行，单体式应用在整个架构中比例逐渐下降直到消失或者成为微服务架构一部分；
 
-虽然在逐步的迁移功能，但是也会有源源不断的需求需要开发，此时该停止让单体式应用继续变大，也就是说当开发新功能时不应该为旧单体应用添加新代码，应该是将新功能开发成独立微服务;
+虽然在逐步的迁移功能，但是也会有源源不断的需求需要开发，此时该停止让单体式应用继续变大，也就是说当开发新功能时不应该为旧单体应用添加新代码，应该是将新功能开发成独立微服务；
 
 一个巨大的复杂单体应用由成十上百个模块构成，每个都是被抽取对象。决定第一个被抽取模块一般都是挑战，一般最好是从最容易抽取的模块开始，这会让开发者积累足够经验，这些经验可以为后续模块化工作带来巨大好处。
 
 转换模块成为微服务一般很耗费时间，一般可以根据获益程度来排序，一般从经常变化模块开始会获益最大。一旦转换一个模块为微服务，就可以将其开发部署成独立模块，从而加速开发进程。比如，抽取一些消耗内存资源较大的代码，将其弄成一个服务，然后可以将其部署在大内存主机上。同样的，将对计算资源很敏感的算法应用抽取出来也是非常有益的，这种服务可以被部署在有很多 CPU 的主机上。
 有三种策略可以考虑：将新功能以微服务方式实现；将表现层与业务数据访问层分离；将现存模块抽取变成微服务。
 
-首先要将抽离的相关功能,封装成相关几个方法,几个类,几个包中;定义好模块和单体应用之间的几个大概的接口,从程序内部开始调用; 一旦完成相关的接口,也就将此模块转换成独立微服务。为了实现，必须写代码使得单体应用和微服务之间通过使用进程间通信机制的API来交换信息;服务和单体应用整合的API代码就成为了容灾层;
+首先要将抽离的相关功能封装成相关几个方法、几个类、几个包中；定义好模块和单体应用之间的几个大概的接口，从程序内部开始调用；一旦完成相关的接口，也就将此模块转换成独立微服务。为了实现，必须写代码使得单体应用和微服务之间通过使用进程间通信机制的API来交换信息；服务和单体应用整合的API代码就成为了容灾层；
 
-然后,将抽离的功能,转化为独立的服务进行部署,将其整合成一个微服务基础框架; 每抽取一个服务，就朝着微服务方向前进一步，随着时间推移，单体应用将会越来越简单，用户就可以增加更多独立的微服务。
+然后，将抽离的功能转化为独立的服务进行部署，将其整合成一个微服务基础框架； 每抽取一个服务，就朝着微服务方向前进一步，随着时间推移，单体应用将会越来越简单，用户就可以增加更多独立的微服务。
 
 ## 服务治理
 服务治理是指在分布式系统、微服务架构中，通过技术和策略管理、监控、优化各个服务之间的交互，来确保整个系统的高效、稳定和可靠运行。
@@ -274,7 +274,7 @@ OpenFeign工作原理：
 
 ![分布式架构-008](/iblog/posts/annex/images/essays/分布式架构-008.png)
 
-1. 使用注解`@FeignClient`注册`FactoryBean`到IOC容器， 最终产生了一个虚假的实现类代理;
+1. 使用注解`@FeignClient`注册`FactoryBean`到IOC容器， 最终产生了一个虚假的实现类代理；
 2. 使用Feign调用接口的地方，最终拿到的都是一个假的代理实现类；
 3. 所有发生在代理实现类上的调用，都被转交给Feign框架，翻译成HTTP的形式发送出去，并得到返回结果，再翻译回接口定义的返回值形式；
 
@@ -400,9 +400,68 @@ Nacos 是一个由阿里巴巴开源的动态服务发现、配置管理和服
 Nacos 还支持动态配置管理，应用的配置可以实时更新，无需重启应用，提升了系统的灵活性。Nacos 提供健康检查机制，监控服务的可用性，并支持多数据源存储选项，以满足不同的业务需求。
 它与 Spring Cloud Alibaba 深度集成，形成了一整套高效的微服务治理解决方案，广泛应用于云原生和分布式系统中。
 
+Nacos 服务注册流程：
+1. 当服务提供者（服务实例）启动时，它会初始化 Nacos 客户端；
+2. 服务提供者通过 Nacos 客户端发送注册请求，包括以下信息：服务名称、服务实例的 IP 地址、端口号、权重（可选）、元数据（可选）；
+3. Nacos 接收到注册请求后，执行以下操作：
+   - 将服务实例信息存储在内存中。
+   - 根据配置将服务实例信息持久化存储到数据库（如 MySQL、PostgreSQL 等）。
+4. Nacos 定期对注册的服务实例进行健康检查，确保服务的可用性。健康检查可以使用：HTTP 健康检查、TCP 健康检查、GRPC 健康检查。
+如果某个实例被标记为不可用，Nacos 会在一定时间内将其状态更新为“下线”，并在一段时间后将其从注册表中剔除。
+
+Nacos 服务发现流程：
+1. 服务消费者（需要调用服务的应用）在启动时也会初始化 Nacos 客户端；
+2. 服务消费者通过 Nacos 客户端向 Nacos 发送请求，查询指定服务名称的可用实例信息；
+3. Nacos 查询到可用的服务实例后，将其信息以 JSON 格式返回给服务消费者，信息包括：服务实例的 IP 地址、端口号、权重、元数据（如果有）；
+4. 服务消费者收到服务实例信息后，使用负载均衡算法（如轮询、随机等）选择一个实例进行调用；
+5. 服务消费者通过 HTTP、gRPC 等协议调用选定的服务实例，实现业务逻辑；
+
+使用Nacos作为配置中心步骤：
+1. 下载安装Nacos，启动Nacos，并创建配置；
+   ![SpringBoot整合nacos](/iblog/posts/annex/images/spring/SpringBoot整合nacos-004.png)
+    ```yaml
+    server:
+      port: 8001
+
+    config:
+      info: "config info for dev from nacos config center"
+    ```
+2. 集成Nacos客户端，在SpringBoot项目中添加相关依赖，在`application.yml`配置中配置Nacos地址；
+    ```xml
+    <dependency>
+        <groupId>com.alibaba.cloud</groupId>
+        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
+    </dependency>
+    ```
+    ```yml
+    spring:
+      cloud:
+        nacos:
+          config:
+            server-addr: localhost:8848
+            file-extension: yaml  # 或 json，根据配置格式选择
+    ```
+3. 在应用中使用`@Value`或`@ConfigurationProperties`注解来获取`Nacos`中的配置，使用`@RefreshScope`注解标记需要动态刷新的Bean；
+    ```java
+    @RestController
+    @RefreshScope
+    public class ValueAnnotationExample {
+    
+        @Value("${config.info}")
+        private String configInfo;
+    
+        @GetMapping("/config/info")
+        public String getConfigInfo() {
+            return configInfo;
+        }
+    
+    }
+    ```
+4. 修改 Nacos 控制台中的配置，观察 SpringBoot 应用是否能够动态刷新配置；
 
 
 #### Sentinel
+[//]: # (写到了这里。。。。。。)
 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。 Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
 
 Sentinel 具有以下特征:
@@ -426,13 +485,13 @@ Dubbo工作原理:
 
 ![分布式架构-014](/iblog/posts/annex/images/essays/分布式架构-014.png)
 
-- config 配置层：Dubbo 相关的配置。支持代码配置，同时也支持基于 Spring 来做配置，以 ServiceConfig, ReferenceConfig 为中心
+- config 配置层：Dubbo 相关的配置。支持代码配置，同时也支持基于 Spring 来做配置，以 ServiceConfig， ReferenceConfig 为中心
 - proxy 服务代理层：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 ServiceProxy 为中心。
 - registry 注册中心层：封装服务地址的注册与发现。
 - cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心。
 - monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心。
-- protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心。
-- exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心。
+- protocol 远程调用层：封装 RPC 调用，以 Invocation，Result 为中心。
+- exchange 信息交换层：封装请求响应模式，同步转异步，以 Request，Response 为中心。
 - transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心。
 - serialize 数据序列化层：对需要在网络传输的数据进行序列化。