vlambda博客
学习文章列表

客户端请求 VIP，然后请求打到了 OpenResty，由 OpenResty 转发给具体的某个 Nacos 节点。

OpenResty 只有一个节点提供服务，另一个暂停状态。如果 master 节点宕机，那 backup 接替继续工作。从而解决了单点故障问题。

Keepalived 作为一种高性能的服务器高可用或热备解决方案，用来防止服务器单点故障的发生。市面资料很多，下文链接是《Keepalived+Nginx部署方案》具体操作步骤

https://help.fanruan.com/finereport/doc-view-2905.html

3. RestTemplate + Ribbon （远程调用）

Spring Cloud Ribbon 基于 Netflix Ribbon 封装的负载均衡框架。内部集成了多种负载算法，如：随机、轮询等。

Ribbon 也提供了扩展接口，支持自定义负载均衡算法。

public class CustomRule extends AbstractLoadBalancerRule { private AtomicInteger count = new AtomicInteger(0); @Override public Server choose(Object key) { return choose(getLoadBalancer(), key); } private Server choose(ILoadBalancer loadBalancer, Object key) { List < Server > allServers = loadBalancer.getAllServers(); int requestNumber = count.incrementAndGet(); if (requestNumber >= Integer.MAX_VALUE) { count = new AtomicInteger(0); } if (null != allServers) { int size = allServers.size(); if (size > 0) { int index = requestNumber % size; Server server = allServers.get(index); if (null == server || !server.isAlive()) { return null; } return server; } } return null; }}

缺点

// 注册到Nacos的应用名称private final String SERVER_URL = "http://nacos-provider-demo";@Resourceprivate RestTemplate restTemplate;@RequestMapping("/hello")public String hello() { // 远程服务调用 return restTemplate.getForObject(SERVER_URL + "/hello", String.class);}

4. OpenFeign（远程调用）

Feign 是一个轻量级的 Restful HTTP 客户端，内嵌了 Ribbon 作为客户端的负载均衡。面向接口编程，使用时只需要定义一个接口并加上 @FeignClient 注解，非常方便。

OpenFeign 是 Feign 的增强版。对 Feign 进一步封装，支持 Spring MVC 的标准注解和 HttpMessageConverts。

依赖包

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId></dependency>

@FeignClient(value = "${provider.name}")public interface OrderService { // 调用服务提供者的 /create_order 接口 @RequestMapping(value = "/create_order", method = RequestMethod.GET) public String createOrder();

其中，@FeignClient(value = "${provider.name}") 定义了服务提供方的工程名，底层自动打通了注册中心，会拿到 artifactId 对应的 IP 列表。根据一定的负载均衡算法，可以将请求打到目标服务器上。

OpenFeign 默认等待接口返回数据的时间是 1 秒，超过这个时间就会报错。如果想调整这个时间，可以修改配置项 feign.client.config.default.readTimeout。

5. Dubbo Spring Cloud（远程调用）

RestTemplate + Ribbon 和 OpenFeign 都是基于HTTP协议调用远程接口。而 Dubbo Spring Cloud 是基于 TCP 协议来调用远程接口。相比 HTTP 的大量的请求头，TCP 更轻量级。

Dubbo Spring Cloud = Spring Cloud  + Dubbo

特性

• 支持多种注册中心，用于服务的注册、发现；
• 内置多种负载均衡策略；
• 服务粒度是面向接口，支持 TCP 轻量级协议；
• 容易扩展，采用 微内核 + 插件 的设计原则，扩展点更强。

依赖包

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-dubbo</artifactId></dependency>

注意：虽然是将 Dubbo 集成到了 Spring Cloud，增加了一些 注解 和 yaml 配置项，开发更方便，但大部分调用玩法还是遵守 Dubbo 框架那一套。

几个重要的配置项：

dubbo.scan.base-packages # dubbo 服务扫描基准包，上报注册服务dubbo.protocol.name: dubbo # 支持的协议dubbo.protocol.port: -1 # dubbo 协议端口（ -1 表示自增端口，从 20880 开始）dubbo.registry.address # 注册中心地址

6. Spring Cloud Gateway（网关）

分布式时代，一个复杂的系统被拆分为若干个微服务系统，每个系统都配置独立的域名肯定不合适。为了解决这个问题，网关便诞生了。

网关充当反向代理的角色，作为流量的第一入口，承载了很多基础的、公共的模块功能，如流控、鉴权、监控、路由转发等。

Spring Cloud 生态早期的网关是 Netflix 公司的 Zuul，后来 Zuul 社区停止了维护。官方后来推出了 Spring Cloud Gateway，其底层是基于 WebFlux 框架。而 WebFlux 框架的底层采用高性能通讯框架 Netty，性能是 Zuul 的 1.6 倍。

核心组件：

路由

内部主要是负责转发规则。

断言（Predicate）

如果返回为 true，当前路由才有效，才会路由到具体的服务。官方提供了很多内置路由断言，如果满足不了你的诉求，也可以自定义路由断言工厂。

所有的路由断言工厂都是继承自 AbstractRoutePredicateFactory，自定义类的命名也有固定规则，“配置名”+RoutePredicateFactory。这样，在 yaml 配置时，只需要写前面定义的配置名即可。

过滤器（Filter）

主要是请求、响应之间增加一些自定义的逻辑。按作用范围分为全局和局部。全局是作用于所有的路由，而局部只是作用于某一个路由。

跟上面的断言类似，除了官方提供的过滤器，也支持自定义。

• 局部过滤器：继承自 AbstractGatewayFilterFactory，自定义类的命名也有固定规则，“配置名”+GatewayFilterFactory。这样，在 yaml 配置时，只需要写前面定义的配置名即可；

• 全局过滤器：实现 GlobalFilter、Ordered 两个接口，实现逻辑跟上面的局部过滤器类似。这里就不展开了。其中的 Ordered 接口主要是负责优先级，数值越小，优先级越高。

依赖包

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId></dependency>

yaml 配置示例：

spring: cloud: gateway: routes: #路由，可配置多个 - id: user_route # 路由id 唯一即可，默认是UUID uri: lb://user-server-sample # 匹配成功后提供的服务的地址 order: 1 # 路由优先级，数值越小优先级越高，默认0 predicates: - Path=/user/** # 断言，路径匹配进行路由 # - User=0, 1000 # 自定义路由断言工厂 只允许查询id为0 - 1000之间的用户 # - Method=POST # 表示需要POST方式请求 # - Query=id, \d+ # 参数名id，正则表达式为\d+（一个或多个数字） filters: - AddRequestHeader=X-Request-token, 12345678 #为原始请求加上请求头及值

当然，服务提供方的地址可能经常变化。为了动态感知，我们引入 Nacos 注册中心用于服务的注册、发现、统一管理服务的 IP 地址。网关路由转发时，只需从 Nacos 动态获取即可。

7. Sentinel（熔断、限流、降级）

Sentinel 是阿里开源的流控框架，提供了简单易用的控制台，比 Hystrix 支持的范围更广。集成简单，只需要少量配置，即可快速接入。支持如 gRPC、Dubbo、Spring Cloud 等。

同类竞品框架

• Hystrix 框架已经停止维护；
• Resilience4j 一种轻量级容错库，专为 Java 8 和函数式编程而设计。通过装饰器的方式，以使用断路器、速率限制器、重试或隔板来增强任何功能接口、Lambda 表达式或方法引用。

流控规则

页面元素介绍：

• 资源名 ：唯一即可；
• 针对来源 ：对调用者限流，填写应用名称（Spring.application.name的值）。只针对某个服务限流；
• 阈值类型
• QPS ：每秒接收的请求数；
• 线程数 ：能使用的业务线程数；
• 流控模式
• 直接 ：达到条件后，直接执行某个流控效果；
• 关联 ：如果访问关联接口 B 达到了阈值，则让接口 A 返回失败；
• 链路 ：记录从入口资源的流量，达到条件也只限流入口资源；
• 流控效果
• 快速失败 ：直接返回失败结果；
• 预热（Warm Up） ：开始有一个缓冲期， 初始值 = 阈值/ codeFactor （ 默认 3），然后慢慢达到设置的阈值；
• 排队等待 ：让请求以均匀的速度通过，如果请求超过阈值就等待，如果等待超时则返回失败。

降级规则

• RT
• 异常数
• 异常比例

系统规则

流控规则和降级规则是针对某个资源来说的，而系统规则是针对整个应用的，粒度更大。当前所有的接口服务都会应用这个系统规则。

授权规则

根据调用方判断调用的接口资源是否被允许，如黑名单、白名单机制。

热点规则

将粒度进一步细化。可以针对方法的参数做规则控制，为每个参数设置单独的阈值，也可以多个参数组合。从而实现单个方法的热点流量，按业务需求进一步控制。

@SentinelResource注解

@SentinelResource 注解可以根据实际情况定制化功能，跟 Hystrix 的 @HystrixCommand 注解功能类似。达到阈值后，系统的默认提示是一段英文，很不友好，所以我们要自定义兜底方法。

// 资源名称为handle1 @RequestMapping("/handle1")@SentinelResource(value = "handle1", blockHandler = "blockHandlerTestHandler")public String handle1(String params) { // 业务逻辑处理 return "success";}
// 接口方法 handle1 的 兜底方法public String blockHandlerTestHandler(String params, BlockException blockException) { return "兜底返回";}

注意：@SentinelResource注解中，除了blockHandler字段外，还有fallback字段。

• blockHandler ：主观层面。如果被限流，则调用该方法，进行兜底处理；
• fallback ：对业务的异常兜底。比如执行过程中抛了各种 Exception 则调用该方法，进行兜底处理。

通过上面两层兜底，可以让 Sentinel 框架更加人性化体验更好。

集群流控

单机限流很容易做，但是互联网很多应用都是集群部署，毕竟其下游还挂载着 mysql、或者其他微服务，为了防止对下游的大流量冲击，采用集群流控。防止单机的流量不均匀， 理想下 QPS = 单机阈值 * 节点数

8. Seata（分布式事务）

事务的原子性和持久性可以确保在一个事务内，更新多条数据，要么都成功，要么都失败。在一个系统内部，我们可以使用数据库事务来保证数据一致性。那如果一笔交易，涉及到跨多个系统、多个数据库的时候，用单一的数据库事务就没办法解决了，此时需要引入分布式事务。

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，默认 AT 模式。为用户打造一站式的分布式解决方案。

优点

• 对业务无侵入：即减少技术架构上的微服务化所带来的分布式事务问题对业务的侵入；
• 高性能 ：减少分布式事务解决方案所带来的性能消耗。

Seata 有三个基本组成部分：

• 事务管理器（TM）：定义全局事务的范围：开始全局事务，提交或回滚全局事务。

• 事务协调器（TC）：维护全局事务和分支事务的状态，驱动全局提交或回滚。

• 资源管理器（RM）：管理正在处理的分支事务的资源，与TC对话以注册分支事务并报告分支事务的状态，并驱动分支事务的提交或回滚。

运行流程：

• TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID；
• XID 在微服务调用链路的上下文中传播；
• RM 向 TC 注册分支事务，TC 返回分支事务ID ，并将其纳入 XID 对应全局事务的管辖；
• RM 执行本地业务表操作，并记录 undo_log 日志，提交本地事务；
• 当所有的 RM 都执行完后，TM 向 TC 发起针对 XID 的全局提交或回滚决议；
• TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。如果提交，删除 undo_log 日志就可以了。如果是回滚，根据 undo_log 表记录逆向回滚本地事务，把数据还原，最后再删除 undo_log 日志。

9. Spring Cloud Stream （异步消息）

Spring Cloud Stream 是统一消息中间件编程模型的框架，屏蔽了底层消息中间件的差异。支持的消息队列框架有 RabbitMQ、Kafka、RocketMQ 等。

常用注解：

• @Input：标记为输入信道，消费消息
• @Output：标记为输出信道，生产消息
• @StreamListener：监听某个队列，接收消息，处理自身的业务逻辑
• @EnableBinding：绑定通道

依赖包：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-stream-rocketmq</artifactId></dependency>

绑定通道：

@SpringBootApplication@EnableBinding({ CustomSource.class})public class StreamProduceApplication { public static void main(String[] args) { SpringApplication.run(StreamProduceApplication.class, args); }}

定义输出信道

public interface CustomSource { @Output("output1") MessageChannel output1();}

yaml 配置

spring: cloud: stream: rocketmq: binder: name-server: 127.0.0.1:9876 # rocketMq服务地址 bindings: output1: producer: transactional: true # 事务 group: myTxProducerGroup # 事务分组 bindings: output1: destination: test-transaction-topic # 主题 content-type: application/json # 数据类型

发送消息

@Servicepublic class SendMessageService { @Resource private CustomSource customSource; public String sendMessage() { //发送简单字符串消息的方法 String message = "字符串测试消息"; // 发送消息 customSource.output1().send(MessageBuilder.withPayload(message).build()); return "发送成功！"; }}

10. SkyWalking（分布式链路追踪）

SkyWalking 是 一款 APM（应用性能监控）系统，专为微服务、云原生架构、容器（Docker、k8s、Mesos）而设计。通过探针收集应用的指标，进行分布式链路追踪，感知服务间的调用链路关系。

特性

• 支持告警
• 采用探针技术，代码零侵入
• 轻量高效，不需要大数据平台
• 多个语言自动探针。包括 Java、.NET Core 和 Node.JS。
• 强大的可视化后台