大型互联网应用技术方案

发布于: 2020 年 06 月 29 日

服务注册发现

  1. eureka:AP模型,服务发现时间缓慢,如果使用默认参数,服务发现极限情况需要超过一分钟,集群模式服务信息通过Http同步,由于本身集群信息无法分片存储,在大规模集群场景下eureka节点间由于心跳续约,服务上下线等变动需要通过广播同步信息,eureka服务端会承担大量请求,不适合大规模集群场景。

  2. zk:CP模型,保证一致性的同时,在主节点选举过程中整个集群面临不可用的情况,同样不适合于大规模集群场景。

  3. nacos:CP和AP都可以支持,集群之间使用Raft协议同步数据,通过namespace,group,clustername实现服务隔离,方便自定义灰度逻辑

网关(往往集成鉴权,埋点等自定义功能,结合nginx使用)

  1. Zuul:服务动态路由,阻塞式IO

  2. Gateway:服务动态路由,结合Webflux支持异步,内部支持限流,负载均衡

熔断限流

  1. hystrix:主要通过线程池的方式实现服务间线程隔离,避免因为调用某个故障服务,夯住己方所有线程,导致服务雪崩,支持信号量隔离

  2. sentinel:主要通过信号量的方式进行资源隔离,支持QPS限流,热点资源限制,关联资源限制,服务熔断降级等等,相比hystrix更加轻量级,限流方式更加丰富。生产环境使用需要修改sentinel dashbord源码,结合nacos实现限流规则持久化生效,结合es实现流量监控数据持久化。

分布式事务

  1. 强一致性

  2. 传统TCC:try-confirm-cancel,需要实现自我补偿机制,较为麻烦

  3. 重写jdbc commit方法,假提交,等待事务管理中心通知,决定最终提交还是放弃,该方案对性能影响较大,不推荐

  4. seata:TM事务发起者,TC事务协调中心,RM分支事务。TM负责向TC申请开启全局事务,拿到全局事务ID XID,记录在header中,分支事务执行期间加锁,执行完毕后直接提交,但是会记录下undo日志,通过base64转码存储于数据库中,如需回滚直接通过undo日志回滚,性能较好,无侵入。

  5. 最终一致性

  6. 通过MQ异步通知,如执行失败,通过手动ack重试一定次数,直到最终成功。如果重试期间均未成功,则进入死信队列,开发人员手动处理,对性能无影响。

用户头像

石印掌纹

关注

还未添加个人签名 2018.11.22 加入

还未添加个人简介

评论

发布
暂无评论
大型互联网应用技术方案