Spring Cloud要点记录

一、用微服务的原因（好处）& 弊端

1.1 用微服务的原因（好处）

１、将一个大项目拆分成Ｎ个小项目，方面项目管理，降低复杂度。将１００人的开发团队拆分成Ｎ个小团队进行开发
２、高峰时期，能做到有针对性的扩容，比如双１１扩容订单、支付、商品等流量高的服务；而单体服务扩容是整个扩容，更浪费资源
３、OOM等异常影响范围缩小化。比如日志服务发生OOM不可用，不会影响订单、商品等核心服务。

1.2 微服务弊端

１、架构复杂性增加
２、数据一致性问题
３、事务一致性问题（多个服务，分布式事务）
４、消耗通讯问题
５、定位问题复杂性问题

二、Spring Cloud & Spring Cloud Alibaba的关系

随着企业的业务发展，现有技术已经没有办法去支持业务的进行，需要对架构进行演进和改变，很多企业就会选择用微服务架构，主流微服务架构有两个：Dubbo、Spring Cloud。Spring组织在早期大部分微服务组件都是Netflix研发的，这个公司研发了很多组件，比如：Hystrix、Ribbon、Eureka、Zuul(第一代)，但这些组件在2020年初全部停止更新。Spring Cloud Alibaba即将被Spring组织纳入第二代微服务架构。

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案，此项目包含开发分布式应用微服务的必须组件，方便开发者通过Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

Spring Cloud旗下产品

三、Spring的版本名规则

举个例子：spring-web-2.0.3 RELEASE

2：主版本号，当功能模块有较大更新或者整体架构发生变化时，主版本号会更新
0：次版本号，次版本表示只是局部的一些变动
2：修改版本号，一般是bug的修改或者是小的变动
RELEASE：希腊字母版本号，此版本号用户标注当前版本的软件处于哪个开发阶段

四、希腊字母版本号

Base：设计阶段，只有相应的设计没有具体的功能实现
Alpha：软件的初级版本，基本功能已经实现，但存在较多的bug
Bate：相对于Alpha已经有了很大的进步，消除了严重的bug，但还存在一些潜在的bug，还需要不断测试
RELEASE：最终版，没有太大的问题

五、Spring Cloud和Spring Boot版本对应关系

Spring Cloud与Spring Boot 需要版本对应，否则可能会造成很多意料之外的错误。

Spring Cloud和Spring Boot版本对应关系

六、熔断&降级区分

6.1 服务降级举例

下单接口调用远程加积分接口，当某一天加积分接口挂了，下单服务会在本地提供一个降级接口来记录xx订单xx用户需要加xx积分，然后定时扫描日志来给用户补偿加积分，这就是服务降级。

6.2 服务熔断举例

远程加积分接口暂时已经挂了，如果下单接口每次下单时还是去请求网络调用远程加积分接口，然后再走本地降级接口，这样会浪费系统资源，如果用熔断功能，可以设定30秒内加积分接口失败5次就熔断的规则，后面执行下单接口就不会再网络请求远程加积分接口了，而是直接调用本地的降级接口，记录补偿加积分日志。过了30秒后再尝试网络请求远程加积分接口（加积分接口可能会在未来某个时间修复启动）

6.3 关系

熔断和降级一般是联系在一起的，熔断时需要调用降级接口。Spring Cloud Alibaba用Sentinel来做服务限流、熔断、降级

七、电商系统微服务架构图

电商系统微服务架构图

图片来源

八、CAP & BASE原则

8.1 CAP 原则

C：一致性（Consistency）
A：可用性（Availability）
P：分区容错性（Partition tolerance）

P(分区容错)：一般是针对多节点部署的系统，分区指网络分区（由于网络原因节点之间无法通信同步数据），容错指系统节点出现分区了对外依然要能提供服务，不能说分区了导致整个系统不能提供服务了。

在满足P的前提下，Client发一条数据给节点1，因为分区产生这条数据暂时无法同步给节点2。如果要保证整个分布式系统的数据一致性（C）,肯定要牺牲掉可用性（A），也就是整个分布式系统对外暂时不可用，不然Client对节点1和节点2的这条数据查询的结果就不一致了。同样的道理，如果要保证A那肯定要牺牲掉C了，因为数据还没在节点间同步，Client查询节点1和节点2的这条数据结果肯定不一样。

8.2 BASE原则

BA：基本可用（Basically Available）
S：软状态（Soft State）
E：最终一致性（Eventual Consistency）

CAP原则是三选二，BASE原则是CAP的折中，C、A、P三个都要，但不用100%的保证每一个原则，分布式系统肯定优先保证P，多数时候是在C和A之间做权衡选择

8.3 各注册中心满足的CAP原则

mysql单机（CA)
eureka集群（AP）
zookeeper集群（CP）
nacos集群（AP或CP），临时节点走AP，持久化节点走CP
redis集群（AP）

8.5 脑裂问题

脑裂：集群（Master-Slave的情况）的脑裂通常是发生在节点之间通信不可达（分区）的情况下，集群会分裂成不同的小集群，小集群各自选出自己的master节点，导致原有的集群出现多个master节点的情况。