# springcloud2_registration_center **Repository Path**: meetu/springcloud2_registration_center ## Basic Information - **Project Name**: springcloud2_registration_center - **Description**: springcloud2_registration_center - **Primary Language**: Java - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2019-04-09 - **Last Updated**: 2020-12-19 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README ## ## 坑 1. Q:feignClient在调用时一直报错 - A: https://blog.csdn.net/huangzhen1991/article/details/81460791 ## 选型spring-cloud 1. 注册中心 [对比](https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/?utm_source=tuicool&utm_medium=referral) 1. [eureka](https://github.com/Netflix/eureka) - 优势: 1. 最早的springcloud注册中心,已经被众多厂商应用 - 劣势: 1. 2.x版本已经停止开源,开源版本停止在1.9.X,未来不明朗 1. 1.9.x eureka与其他starter集成,版本会受到限制 1. [consul](https://www.consul.io/intro/vs/index.html) - 优势: 1. 使用者多 1. 集群配置部署方便,应用本身只有一个consul文件 1. 管理页面交互友好 1. 注册中心/配置中心在一起,没必要额外引入和部署config starter - 劣势: 1. 没找到 1. [nacos](https://github.com/alibaba/nacos) - 优势: 1. 注册/配置中心一并提供 1. 在nacos页面维护数据,配置文件有历史记录 1. alibaba背景,正式版本一旦发布有可能成为主流 - 劣势: 1. 尚存在于springcloud incubator中,未正式发布,未来不确定 1. 配置中心 1. [config](https://github.com/spring-cloud/spring-cloud-config) - 优势: 1. 配置文件直接读取git远程仓库,历史版本清晰 - 劣势: 1. 自动刷新需要集成bus,mq/kafka,一个配置中心需要额外依赖内容太多 1. [consul](https://www.consul.io/intro/vs/index.html) - 优势: 1. 页面管理配置 1. 实时在客户端内存刷新配置文件,无需额外引入和部署config,bus,mq/kafka - 劣势: 1. 配置文件无历史版本记录 1. [nacos](https://github.com/alibaba/nacos) - 同注册中心理由 1. [Apollo](https://github.com/ctripcorp/apollo) - 携程开发的配置中心,没用过 1. 网关 1. [gateway](https://github.com/spring-cloud/spring-cloud-gateway) 1. 1. [zuul(1.0/2.0)](https://github.com/Netflix/zuul) 1. Netflix推出的网关,没研究 1. 分布式事务 1. ACID:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability) 1. 分布式事务的几种形态 1. 2PC 1. 各个服务会锁定资源,如果总流程耗时,则资源锁定时间越长,性能低 1. XA 1. TCC - 为了更好地介绍TCC,这里先引入这么一个概念:最终一致性 - 最终一致性目前没有公认的定义。一般来说,它是指事务进行中,某些分支的中间状态可以被事务外观察到,即"读未提交",从而导致多个分支的状态可能不一致,但所有分支 最终 会达到要么全部提交,要么全部回滚的一致状态。 - 很明显,最终一致性部分牺牲了ACID中的C和I,但它带来了可观的收益:资源不再需要长时间上锁,极大地提高了吞吐量。 - 但是会产生短暂脏读? by gaowen 1. SAGA 1. ## TODO 1. 分布式事务(XA,TCC)及具体实现方案选择(fescar(seata)) 1. 相同服务不同节点间的日志管理 1. 细粒度拆分服务和数据库,连表查询如何解决 ## 附录 1. [CAP理论](http://www.ruanyifeng.com/blog/2018/07/cap.html) 1. [https://springcloud.cc/](https://springcloud.cc/) 1. [lombok](https://projectlombok.org/) 1. [consul中文demo](https://blog.csdn.net/liuzhuchen/article/details/81913562) 1. [分布式事务] - [分布式事务的形态](https://blog.csdn.net/skyesx/article/details/82834439) - (https://blog.csdn.net/weixin_42849915/article/details/81865476) - (https://blog.csdn.net/xiaodong19881106/article/details/80329557)