Spring Cloud常用组件及设计原则

SpringCloud的Hoxton版本，和之前的版本相比，用新的组件替换掉了原来大部分的组件，老的组件现在处于 停更不停用 的状况。
详情见下图（× 的表示之前的组件，现在停更了的；√ 的表示新的替换后的组件）：

描述：

服务注册中心：

Eureka：官方停止更新，并且已经有更好的替代产品了，可以使用，但是官方已经不建议使用了（重度患者）。

Zookeeper：某些老系统，以前是用的Zookeeper + Dubbo，后来做技术升级，结果发现SpringCloud的Eureka停更了，然后就用了最少的技术切换，那么就用了Zookeeper做注册中心。

Consul：go语言开发的，也是一个优秀的服务注册框架，但是使用量较少，风头都被Nacos抢了。

Nacos：来自于SpringCloudAlibaba，在企业中经过了百万级注册考验的，不但可以完美替换Eureka，还能做其他组件的替换，所以强烈建议使用，是学习的重点。

服务调用：

Ribbon：也进入了维护状态，停止更新了，但是Spring官方还在使用（轻度患者）。

LoadBalancer：Spring官方推出的一个新的组件，打算逐渐取代掉Ribbon，但是现在还处于萌芽状态。

服务调用2：

Feign：Netflix 公司产品，也停止更新了。

OpenFeign：Spring社区等不了Netflix更新了，然后就自己做了一个组件，不用Feign了。

服务降级：

Hystrix：官网不推荐使用，但是中国企业中还在大规模使用。

Resilience4J：官网推荐使用，但是国内很少用这个。

Sentienl：来自于SpringCloudAlibaba，在中国企业替换Hystrix的组件，国内强烈建议使用。

服务网关：

Zuul：Netflix 公司产品，公司内部产生分歧，有的人想自己出一个Zuul2。

Zuul2：也是Netflix 公司准备出的产品，但是由于内部分歧，所以Zuul2已经胎死腹中了。

gateway：Spring社区自己出的网关组件，官方隆重介绍和极度推荐的网关服务组件。

服务配置：

Config：目前也在使用，风头被Nacos抢了。

Nacos：来自于SpringCloudAlibaba，后来居上，把Config给替换了。

服务总线：

Bus：SpringCloud原生的服务总线组件，现在风头也被Nacos抢了。

Nacos：来自于SpringCloudAlibaba，后来居上，把Bus给替换了。

最新组件体系介绍

Spring Cloud体系组件对比

综上可以看出，Nacos 是重中之重，一个组件就替换掉了原来的几个组件。

延伸系统设计的几个原则

ACID[传统关系型数据库]

[注意:]NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）;NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏

1. 原子性 Atomicity
2. 一致性 Consistency
3. 隔离性 Isolation
4. 持久性 Durability

1. 原子性[A]

保证事务中的所有操作全部执行或者全部不执行.

2. 一致性[C]

保证事务操作之前和之后都是一致的.

3. 隔离性[I]

多个事务并发的话，应该和多个事务串行执行效果一致.

事务的四个隔离级别：

• 串行化：保证所有情况下都不会发生。【锁表】
• 可重复读：会出现幻读。【会锁定所读取的所有行】
• 读未提交：会出现脏读、幻读、不可重复读。【隔离级别最低，并发性能高】
• 读已提交(默认): 会出现幻读、不可重复读。【锁住正在读取的行】

总结：四个级别逐渐增强。每个级别分别解决一个问题，事务级别越高，性能越差，大多数环境下ReadCommit情况下就可以了。

脏读、幻读、不可重复读:

• 脏读：一个事务读取了另一个事务未提交的数据，而这个数据有可能被回滚。
• 幻读：事务不同独立执行时发生的一种现象。事务1读取指定Where条件的结果集，然后事务2插入一条新数据，而这条新数据刚好满足事务1所查询的条件，然后事务1再次查询时，看到了事务2新提交的数据。【幻读强调的是新增、删除。同样的条件，两次查询的记录数不同】
• 不可重复读：在一个事务范围内，两次查询得到不同的结果。【不可重复读强调的是修改。同样的条件，两次查询的记录值不同】

4. 持久性[D]

事务执行完之后，对于数据库的影响应该是持久的.

CAP原则[分布式系统]

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

1. Consistency 一致性
2. Availability 可用性
3. Partition tolerance 分区容错性

它们的第一个字母分别是 C、A、P。
Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

1. 一致性[C]

任何操作都是原子的.发生在后面的事件可以看到前面发生事件的结果
(注意:这里的一致性是指强一致性)

2. 可用性[A]

对于用户的每一个请求在有限时间内内返回结果.

“有限时间内”: 是指 对于用户的请求，系统必须存在合理的响应时间，否则用户便会对系统感到失望

“返回结果”:是指 响应结果能够正常反映请求的处理结果，即成功或失败,而不是让用户困惑的结果

3. 分区容错性[P]

系统在遇到任何网络故障时，仍能对外提供可用性和一致性服务，除非整个网络发生故障.

结论: 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

1. 数据库事务一致性需求很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。
2. 数据库的写实时性和读实时性需求对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3. 对复杂的SQL查询，特别是多表关联查询的需求任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

BASE原则[CAP的补充]

BASE理论是对CAP中一致性和可用性的权衡总结.

1. 基本可用：Basic Available
2. 弱状态：Soft State
3. 最终一致性：Eventually Consistent

1. 基本可用[BA]

分布式系统在出现故障时，允许损失部分可用性，但是系统还是可用的.

2. 弱状态[S]

也称为软状态，和硬状态ACID相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3. 最终一致性[E]

系统中的数据，经过同步之后最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。