Spring Cloud体系组件对比及系统设计原则
组件体系介绍
Spring Cloud体系组件对比
| 功能 | Alibaba套件 | Netflix套件(停更) | Spring Cloud原生 | 其他 |
|---|---|---|---|---|
| 注册中心 | Nacos | Eureka | Consul | Zookeeper,Etcd |
| 远程调用 | Dubbo | Feign/Ribbon | -- | -- |
| 熔断限流 | Sentinel | Hystrix | -- | -- |
| 网关 | Nacos-discovery | Zuul | gateway | -- |
| 配置中心 | Nacos-config | -- | Config | -- |
| 消息驱动 | stream-rocketmq | -- | stream | kafka,RabbitMQ |
| 链路追踪 | -- | -- | sleuth+zipkin | -- |
| 分布式事务 | Seata | -- | -- | -- |
延伸系统设计的几个原则
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网站来说，关系数据库的很多主要特性却往往无用武之地
- 数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。- 数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。- 对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
BASE原则[CAP的补充]
BASE理论是对CAP中一致性和可用性的权衡总结.
1. 基本可用：Basic Available
2. 弱状态：Soft State
3. 最终一致性：Eventually Consistent
1. 基本可用[BA]
分布式系统在出现故障时，允许损失部分可用性，但是系统还是可用的.
2. 弱状态[S]
也称为软状态，和硬状态ACID相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3. 最终一致性[E]
系统中的数据，经过同步之后最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
