- 为什么要使用分布式架构
- 分布式的术语
- 概念区别
- 分布式架构的演进之路
- 分布式架构带来的问题
- 历史渊源
随着物联网行业的发展,系统业务的扩张,对计算机硬件的要求也越来越高了,单台设备做的再好,也很难满足业务需求
- 分布式和微服务的区别
分布式: 分散压力 解决三高(高性能,高可用,高并发)问题
微服务: 分散能力 解决的是业务耦合问题
PS：本身没有严格的区别和关系，一般来说大型的互联网项目都是基于微服务的分布式架构
分布式的术语- 基于微服务的分布式架构
微服务: 系统中存在多个不同的模块相互独立,协调工作
分布式: 每个模块都有多个相同的服务器提供性能和可用性保障
- 高可用
系统中部分节点宕机时,其他节点能够继续顶替它提供服务,则可以任务系统是高可用的
- 集群
多台服务器作为一个整体提供一类服务,这个整体就叫做集群。
如zookeeper的master和slaver部署在多台服务器上,共同组成一个集中式配置服务,我们客户端只需要连接其中一个服务器(客户端不关注是哪一台机器)即可,当这台机器挂了,其他节点能自动顶替他提供服务,这时候说明系统具有高可用性。
- 复杂均衡
请求发送到系统时,使用一定的策略达到集群内部服务器的最优使用
- 正向代理和反向代理
概念区别正向代理: 系统内部服务器访问外部网络时,统一通过一个代理服务器将请求发送出去,在外部服务器看来就是代理服务器发起的访问,此时代理服务器实现的就是正向代理
会所对外的广告肯定不能是自己去发漂亮性感技师的传单，可以找各种黄牛进行宣传找客户，这样对于客户来说，只认识黄牛，而不知道会所的情况，也保证了会所的安全性（万一碰上了仙人跳呢）-----这就是正向代理
反向代理: 外部请求进入系统时,代理服务器将该请求转发到系统的某台服务器上,对外部服务器来说,与之交互只有代理服务器,此时服务器实现的就是正向代理
当客户需要会所技师提供服务时，直接找各种黄牛带路去会所找到可以为自己提供DBJ服务的会所技师，这样对于会所来说，服务提供了，钱赚了，同时也避免了直接面对客户（万一碰上了便衣呢）-----这就是反向代理
- 集群与分布式
集群: 相同的人干同样的事(A1 A2)
分布式: 不同的人干同一件(配合)事(A1 A2+B1 B2 + C1 C2)
- SOA和微服务的区别
这两个没有一个严格的区分标准
| 区别 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独或者小块逻辑 |
| 耦合性 | 通常是松耦合 | 总是松耦合 |
| 开发组织 | 任何类型 | 小型、专注功能交叉团队，为了快速迭代 |
| 管理 | 中央管理（整体） | 分散管理（分散管理） |
| 便利性 | 对人员要求高 | 对人员的要求低一些（团队拓展也快） |
- 单体架构应用
最开始的应用架构， 一台服务器开着web服务器、数据库，web服务器和数据库共享一个cpu，承受并发能力有限
单体架构的演变： web服务器和数据库各自单独部署服务器，应用服务器和数据库完隔离开来，相互不影响，增加的系统的可用性
- 垂直应用架构
随着访问量的增加，单台服务器已经无法满足我们的需求，这个时候我们可以通过集群化应用服务器的方式来提升系统的负载能力
系统达到这个阶段，各个问题也接踵而至：
用户的请求过来，有谁来转发到应用服务器（谁来负责负载均衡）
用户如果每次访问到的服务器不一样，那么如何维护session，达到session共享的目的。
此时，系统架构又有了如下演变
此时多个服务器都访问同一个数据库，数据库压力大，这个时候就需要对数据进行水平扩展（读写分离）
由于关系型数据库的上限太小，随着业务增加，访问量继续增加，数据库就成为了瓶颈，这时就引入了搜索引擎和缓存来提升系统性能：
这时我们系统承受并发能力搞了，但是系统的可扩展性不高，还是一个一个的单一系统，当整个系统庞大起来，难于维护，此时就需要服务化了
- 分布式架构（独立子系统）
这样服务基础化以后，各个功能比较明细，系统的扩展性比较高，当需要服务时就添加服务，当某个服务承受不住压力时，可以新增一个集群服务
这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所有会导致每个系统都会有用户查询的相关操作，这些相同的操作需要抽象出来，否则就是一个坑，所以需要通过服务话的方式来解决这个问题 - 分布式架构（服务化）
我们基于网络构建分布式系统，将多个系统连接起来，就要面临我们使用单体架构时不会遇到的问题。
- 网络延迟：性能、超时
这带来的是系统整体的性能降低，还会带来一些其他问题，如果系统的资源锁定，所以系统调用一般需要设定一个超时时间，但是过度的延迟会有可能会引发系统间的RPC调用超时。这就是分布式系统调用的三态结果：成功、失败、超时，一般能采用的方案就是异步化、重拾等
- 网络故障：丢包、乱序、抖动
- 一致性问题
（1）调用超时：系统A掉系统B，系统得到反馈超时，到不确定系统B是否已经处理结束，就造成结果不一致
（2）掉单：系统A和系统B分别为对方的上下游，如果系统A中存在一个订单，而系统B中不存在，就会导致掉单。
（3）存与数据库的不一致：面对海量的访问请求，我们经常会需要在数据库前加一层缓存，这个缓存与数据库之间如何保证一致性。
对于数据一致性问题，解决模型有三种：
Strong Consistency（强一致性）：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统、RDBMS、Azure Table都是强一致性的
Week Consistency（弱一致性）：不同副本的值有新有旧，需要应用做更多的操作才能获取到新值
Evantual Consistency（最终一致性）：一旦更新成功，各副本的数据在最终将达到一致
弱一致性和最终一致性一般来说是异步冗余的，而强一致性一般来说是同步冗余的。异步通常意味这更好的性能，但也意味着更复杂的状态控制，同步意味着简单，但也意味着性能下降
- CAP定理
CAP定理，指的是在一个分布式系统中，Consistency(一致性)、Availability（可用性）、Partition tolerance（分区容错性），最多实现两点，三者不可兼得。CAP定理主要是针对分布式系统各节点之间的通信提出的定理。
一致性（C）:在分布式系统中的所有数据备份，在同一时刻是否同样的值。
可用性（A）:在集群中一部分节点故障后，集群整体是否还能响应客户端的请求。
分区容错性（P）：分布式系统中的节点之间的通信有可能失败，在这种情况下，系统要能够容纳这种错误。
分布式系统中必然存在着分区，而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。那么根据CAP定理，C与A我们只能择其一实现。那么为什么实现P的情况下，C与A不可兼得呢，我们来分析一下：
假设节点A与节点B，它们中的数据是一致的，然后我们发起请求，修改了节点A中的数据，节点B中的数据也要相应的更改，但是出现了网络延迟等问题，节点B中的数据没有更改，依然是旧数据。这时，请求节点B中的数据，但是数据还没有同步，那怎么办呢？如果我们要满足一致性，就应阻塞这次请求，等节点B中的数据得到更改，这样可用性就无法满足；而如果我们要满足可用性，那么我们就要返回节点B中的旧的数据，这样一致性就无法满足。所以我们就需要结合实际情况，做出取舍，是满足一致性还是满足可用性。
