【分布式】—架构设计

1.2、分布式架构设计

1、SOA和微服务

SOA 各模块间相互调用，ESB来隔离各模块，各模块都走ESB。
特点：1.有序。2.复用。3.高效。

微服务架构：业务需要彻底的组件化和服务化
特点：1.组件化。2.按业务能力划分服务和开发团队。3.去中心化。4.基础设施的自动化。

差异：1、微服务没有强调ESB，而是到各个模块去组件化。
          2、SOA注重的系统集成，微服务是完全独立完全分离。

2、领域驱动设计及业务驱动划分

3、分布式架构的基本理论CAP、BASE以及应用

a、分布式一致性的问题

数据一致性就是指在对一个副本数据进行更新的时候，必 须确保也能够更新其他的 副本，否则不同副本之间的数据 将不一致


     
那么如何去解决这个问题？按照正常的思路，我们可能会 想，既然是因为网络延迟导致的问题，那么我们可以把同 步动作进行阻塞，用户 2 在查询的时候必须要等到数据同 步完成以后再来做。但是这个方案带来的问题是性能会收 到非常大的影响。
所以我们没有办法找到一种能够满足数据一致性、 又不影响系统运行的性能的方案。
强一致性（保证数据一致性，但是会影响系统的性能。）、弱一致性（系统的性能很好，保证请求后有成功或失败返回，jin尽可能的保证某个时间内数据的一致性。）最终一致性（最终一致性是弱一致性的一个特例，系统 会保证在一定时间内，能够达到一个数据一致的状态。是弱一致性 中非常推崇的一种一致性模型，也是业界在大型分布式系 统的数据一致性上比较用的多的模型 ）

b、CAP

一致性(Consistency)、可用性(Availability)、分区容错性(Partition-toleranc)

这三个基本需求，最多只能同时满足其中两项_(CP/AP)_

CAP并不是一个普适性原理和指导思想，它仅 适用于原子读写的NoSql场景中，并不适用于数据库系统

c、BASE

1、基本可用（搜索有1s变成2s。降级页面（当前访问量过多））

2、软状态 （状态机） 待支付、交易处理中、交易成功、交易失败

3、数据最终一致性 （基于MQ）

核心思想：即使无法做到强一致性，但每个 应用都可以根据自身业务特点，采用适当的方式来使系统 达到最终一致

4、什么是分布式架构下的高可用设计

1.避免单点故障

a、负载金恒技术（failover选址/硬件负载/软件负载/去中心化的软件负载（gossip（redis-cluster）））

b、热备 （linux HA）

c、多机房（同城灾备、异地灾备）

2、应用的高可用性

a、故障监控（系统监控（cpu、内存）/链路监控/日志监控）自动预警

b、应用的容错设计、（服务降流、限流） 自我保护能力

c、数据量 （数据分片、读写分离）

5、分布式架构下的可伸缩设计

垂直伸缩 （提升硬件能力）

水平伸缩 （增加服务器）

CDN 内容分发网络。

6、构建高性能的分布式架构