Spring Cloud Alibaba

1. Nacos Discovery 服务注册发现

Nacos

        一个更易于构建云原生应用的动态服务发现(Nacos Discovery )、服务配置(Nacos Config)和服务管理平台。

Nacos 的关键特性包括:

• 服务发现和服务健康监测
• 动态配置服务
• 动态 DNS 服务
• 服务及其元数据管理

Nacos Discovery

管理服务之间错综复杂的调用关系。

Nginx 缺点：服务量（远程服务地址）很多，需要运维手动维护到Nginx， 这非常容易出错。

  

核心功能

1. 服务注册：Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。

2. 服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存

3. 服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。

4. 服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)

5.服务stop：当服务停止时，会向Nacos发送服务停止的请求。

6. 服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。（ leader raft）

补充说明：

// 查某个端口所属的进程

>netstat -aon | findstr "58883"

-- 结果会展示进程号，就可以进一步根据进程号查询进程详情。

2. Nacos Config服务配置中心

        使用 Spring Cloud Alibaba Nacos Config，可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。

没有统一的配置中心时，修改配置时的特点：

• 维护性：比如很多服务使用redis, 如果有一台redis发生服务变更，ip地址有修改，则所有的微服务的配置文件都需要修改。
• 时效性：修改后还需要重启
• 安全性：如果服务使用redis或其他服务，需要在自己的配置文件中维护链接信息，比如用户名、密码登，不安全。

springcloud config 对比， 三大优势：

1. springcloud config大部分场景结合git 使用, 动态变更还需要依赖Spring Cloud Bus 消息总线来通过所有的客户端变化。
2. springcloud config不提供可视化界面。
3. nacos config使用长轮询更新配置,一旦配置有变动后，通知Provider的过程非常的迅速, 从速度上秒杀springcloud。

3. 负载均衡器Ribbon

主流的负载均衡实现方案：

1. 集中式负载均衡，在消费者和服务提供方中间使用独立的代理方式进行负载，有硬件的（比如 F5），也有软件的（比如Nginx) 【服务端负载均衡】

2. 客户端根据自己的请求情况做负载均衡，Ribbon 就属于客户端自己做负载均衡。

客户端负载均衡：

        例如spring cloud中的ribbon，客户端会有一个服务器地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行访问。即在客户端就进行负载均衡算法分配。

服务端负载均衡

负载均衡算法：

1. 随机，通过随机选择服务进行执行，一般这种方式使用较少;
2. 轮训，负载均衡默认实现方式，请求来之后排队处理;
3. 加权轮训，通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;
4. 地址Hash，通过客户端请求的地址的HASH值取模映射进行服务器调度。 ip --->hash
5. 最小链接数，即使请求均衡了，压力不一定会均衡，最小连接数法就是根据服务器的情况，比如请求积压数等参数，将请求分
6. 配到当前压力最小的服务器上。 最小活跃数

Nacos使用Ribbon， nacos-discovery依赖了ribbon，可以不用再引入ribbon依赖。

4. 服务调用OpenFeign

Java项目中如何实现三方服务调用？

1. URLConnection：传统 JDK 自带的 URLConnection

2. HttpClient：

        HttpClient 是 Apache Jakarta Common 下的子项目，用来提供高效的、最新的、功能丰富的支持 Http 协议的客户端编程工具包，并且它支持 HTTP 协议最新版本和建议。HttpClient相比传统 JDK 自带的 URLConnection，提升了易用性和灵活性，使客户端发送 HTTP 请求变

得容易，提高了开发的效率。

3. Okhttp：一个处理网络请求的开源项目

4. HttpURLConnection：

        HttpURLConnection 是 Java 的标准类，它继承自 URLConnection，可用于向指定网站发送GET 请求、POST 请求。HttpURLConnection 使用比较复杂，不像 HttpClient 那样容易使用。

5. RestTemplate ：

        RestTemplate 是 Spring 提供的用于访问 Rest 服务的客户端，RestTemplate 提供了多种便捷访问远程 HTTP 服务的方法，能够大大提高客户端的编写效率。

6. Feign : Feign是Netflix开发的声明式、模板化的HTTP客户端

OpenFeign

Spring Cloud openfeign对Feign进行了增强，使其支持Spring MVC注解，另外还整合了Ribbon和Nacos，从而使得Feign的使用更加方便。

Feign可以做到使用 HTTP 请求远程服务时就像调用本地方法一样的体验。它像 Dubbo 一样，consumer 直接调用接口方法调用 provider，而不需要通过常规的 Http Client 构造请求再解析返回数据。

Feign的底层用的是Ribbon，但超时时间以Feign配置为准。

 5. 服务高可用Sentinel

为了保证服务的高可用，常见的容错机制：

1. 超时机制
2. 服务限流
3. 服务隔离+服务降级：
   1. 线程隔离：访问服务不直接访问，而是通过线程池访问，为不同的服务分配不同的线程数， 如果分配不到线程，进行降级处理；
   2. 信号隔离：为不同的服务配置不同的限流值
4. 服务熔断 + 服务降级
5. 服务降级

Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护 等多个维度来帮助开发者保障微服务的稳定性。

6. 分布式事务Seata

分布式事务就是为了保证不同资源服务器的数据一致性。

• 跨库事务
• 分库分表

常见分布式事务解决方案

1. seata 阿里分布式事务框架
2. 消息队列
3. saga
4. XA

他们有一个共同点，都是“两阶段(2PC)”。目前绝大多数分布式解决方案都是以两阶段提交协议2PC为基础的。实际上，这四种常见的分布式事务解决方案，分别对应着分布式事务的四种模式：AT、TCC、Saga、XA。

AT (Auto Transacion)

AT 模式是一种无侵入的分布式事务解决方案。Seta实现了AT模式。

在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

一阶段

二阶段提交

删除快照，删除行锁。

二阶段回滚

检查脏写，如果出现脏写就需要转人工处理。

行锁时干嘛的？

TCC模式

1. 侵入性比较强， 并且得自己实现相关事务控制逻辑

2.在整个过程基本没有锁，性能更强

用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。

TCC需要考虑的问题：

1. 允许空回滚：try未执行，cancel执行了
2. 防悬挂控制：cancel比try先执行
3. 幂等控制

Saga模式

Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都有一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

        分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

        Saga 正向服务与补偿服务也需要业务开发者实现。因此是业务入侵的。

        Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

与TCC实践经验相同的是，Saga 模式中，每个事务参与者的冲正、逆向操作，需要支持：

1. 空补偿：逆向操作早于正向操作时；
2. 防悬挂控制：空补偿后要拒绝正向操作
3. 幂等

XA模式

XA是X/Open DTP组织（X/Open DTP group）定义的两阶段提交协议。

XA规范的基础是两阶段提交协议2PC。

XA模式中的角色：

• 事务协调者
• 事务参与者

        分布式事务本身就是一个技术难题，业务中具体使用哪种方案还是需要不同的业务特点自行选择，但是我们也会发现，分布式事务会大大的提高流程的复杂度，会带来很多额外的开销工作，「代码量上去了，业务复杂了，性能下跌了」。

所以，当我们真实开发的过程中，能不用分布式事务就不用！（看了这么多，还不让用~）。

7. GateWay网关

8.Skywalking