rpc调用，限流，降级，熔断

三高

高可用，高并发，高扩展

架构图

分布式事物
链路追踪

高可用-nacos+openfeign实现服务调用

之前大促的实现

增减机器，修改各种nginx配置

rest-template（默认集成了rebbion----实现客户端的负载均衡）

调用之前，ribbion进行拦截，然后请求注册中心，根据服务名获取到服务列表，然后根据负载规则选择一个发起请求，定时轮询（隔几秒就拉去服务）

注册中心定时接受客户端心跳

重试，熔断

openfeign底层依赖rebbion，他实现了调用远程方法如同调用本地方法一样，

高可用- sentinel限流

降级限流熔断

订单系统每秒能抗10万，现在大促活动，每秒有几百万请求过来，订单系统就会给打挂掉

超过10万的请求提示说当前系统繁忙，请稍后再试

降级

高可用- 熔断

业务代码无侵入

高并发，高可用。

下订单，加积分（很少关心，积分系统出错，可以后续恢复之后再补回来）

分布式系统的流量防卫兵




出错后就转而去调本地的异常处理方法

实时QPS，峰值QPS(一台机器做压测，比如10台机器部署了改服务，那再*10)

高并发-seata

seata会有一个协调器，如果A发送add语句，告知协调器，B服务异常了，告知协调器，这时协调器会对A的进行反向操作，即执行delete（基于mysql的undo日志实现），从而实现事务的回滚

mysql–undo回滚日志
蚂蚁金服是和钱打交道–会使用seata—强一致性，但是加锁太多，性能有点低，实效性有点差，别的公司很少用

实时qps计算是使用滑动窗口算法实现的
淘宝，天猫是如何来控制事务一致性的

redis撑死几万，nacos能达1万3千多，

代码走向，设计精髓

注册有1，2，3，假设1，2弄完了，但是3没有，此时客户端读出来的就是脏数据

加锁不能实现高并发

使用mq保证分布式事务一致性

网关—门面模式（网关域名/order，网关域名/product，网关域名/pay----网关负责转发，就不需要在写订单服务域名或ip/order，商品服务/product，支付服务/pay）
注册中心-发布订阅者模式
spring-security-责任链模式

网关主要是以下配置

所有中间件深挖到原理以及架构思想（解决乐什么问题，整么解决的）
设计思想，全局考虑，性能，扩展性，能否解决可能出现的规模大起来之后的问题

部署时感知及时，又要运行时并发高–不可得兼，没有完美，只有适合，多级缓存就是为了并发

业务部门
基础架构部门（维护开发中间件）

fliter类：接口调用次数，抛异常次数，被sentinel限流次数，1s一个格子，都会去统计

划的越细，精度越高

统计近10s，这10个格子总请求数求和，总报错数求和，超过80%，就进行服务熔断
10秒内总请求数/10计算出qps，超过了阈值，就开启服务限流