1、技术变革
2、开发框架
2.1、框架图
2.2、说明
ORM - 一台主机承载所有的业务应用
MVC - 多台主机分别承载业务应用的不同功能，通过简单的网络通信实现业务的正常访问
RPC - 应用业务拆分、多应用共用功能、核心业务功能 独立部署，基于远程过程调用技术(RPC)的分布式服务框架 提高业务功能复用及项目的整合
SOA - 粗放型的RPC分布式实现了大量的资源浪费，提高机器利用率的 资源调度和治理中心(SOA) ，基于现有资源的高效利用，进一步提高服务的能力
微服务 - 随着互联网的发展、各种技术的平台工具出现、编程语言的升级、开发规范的标准化等因素，中小型企业也有了相应的能力来发展更轻量级的SOA模式。
3、微服务
3.1、单体架构到微服务架构拆分架构图
3.2、服务注册管理中心图
3.3、说明
在微服务架构的场景中，有一个组件服务Service Registry,它是整个"微服务架构"中的核心，主要提供了
四个功能：服务注册和服务发现、下线处理、健康检测等。
服务注册：当服务启动后，将当前服务的相关配置信息都注册到一个公共的组件 -- Service Registry中。
服务发现：当客户端调用操作某些已注册服务 或者 服务的新增或删除等，通过从Service Registry中读取这些服务配置的过程。
目前，Service Registry的最佳解决方案就是Zookeeper。这就是我们要学习Zookeeper的目的之一。
4、分布式
4.1、什么是分布式系统
其实，除了ORM的部署场景之外，其他的几种模式，都是需要大量的主机服务组合在一起实现共同的业务功能，像这种多个服务彼此之间通过消息传递进行通信和协调的系统，我们都可以称之为 分布式系统 或者 分布式架构。
4.2、分布式常见问题
如果分布式系统内部多个功能，没有对数据通信、业务逻辑进行限制约束的情况下，可能会有如下常见问题：
问题 描述
随意分散 服务主机在空间上随意分布，主机角色随意变换
同等角色 服务主机之间没有主从角色之分，导致任意主机都处于同等地位，导致任意一台主机故障都影响全局。
并发请求 分布式系统的多个节点，可能会并发的操作一些共享的资源，例如数据库和分布式存储
资源抢占 服务主机的分散特性，缺乏统一管理，导致某一时刻或者某一时段导致资源冲突或抢占
故障发送 上面的各种因素导致各种故障层出不穷，而且无法快速定位
4.3、分布式特性
目前来说，随着互联网的发展，各种软件技术，尤其是设备计算能力的提升，所以很多企业在项目的开启就应用了 分布式架构。
在分布式系统中各个节点之间的协作是通过高效网络进行消息数据传递，实现业务内部多个服务的通信和协调，基于服务本地设备的性能实现资源的高效利用。
分布式系统的设计目标通常包括几个方面：
可用性：可用性是分布式系统的核心需求，衡量了一个分布式系统持续对外提供服务的能力。
可扩展性：增加及其后不会改变或者极少改变系统行为，并且获得相似的线性的性能提升
容错性：系统发生错误时，具有对错误进行规避以及从错误中恢复的能力
性能：对外服务的响应延时和吞吐率要满足用户的需求
4.4、一致性协议
我们在项目架构在运行过程中 为了保证 业务保持基本可用 过程中定制的各种规约或者通信格式，都可以将其称为 一致性协议。
一般情况下，我们会基于集群的方式实现分布式的 可用性、可扩展性、容错性等的目标，那么我们如何保证集群中的数据的一致性呢？
4.5、一致性模型
4.5.1、说明
一般情况下，我们会基于 集群的方式实现分布式的 可用性、可扩展性、容错性等的目标，这个时候，集群中各个主机之间的通信信息是否一致的就非常重要了。
所谓的一致性是集群内部各个主机系统对外呈现的状态是否一致，即时业务出现问题的时候，这是所有的节点也要达成一个错误的共识。如果各个主机之间通信的数据不一致，就会导致各种分布式的场景问题。
在一个集群系统中，为了保证所有的主机系统能够处于一种相对的平衡状态，我们一般会基于传递数据本身和主机角色的方式来实现，所以我们可以从两个方面来进行分析：
数据本身：将所有的更新数据，同步到整个集群系统，保证数据的最终一致性。
主机角色：client向多个server主机系统发起访问(包括并行访问)请求时，如何获取相同的更新后数据。
4.5.2、传递数据本身
强一致性(Strong Consistency)
通过对业务逻辑和数据顺序的控制，实现数据的读写完全是一致的，因为其在并行场景下的阻塞效果，所以在分布式场景中，实现的效果不是太好。
顺序一致性(Sequential Consistency) 服务端对于接收的客户端请求，将这些请求放到一个序列中，按照顺序来执行数据请求。
更新场景：5个客户端发起更新数据请求，服务端接到请求后，按照顺序将所有请求放到要给队列中，然后按照队列顺序，依次获取请求进行处理；
同步场景：服务端接收n个客户端发起的读取请求，因为受到本身的性能限制，所以划分一个队列，批量按照顺序，依次读取。
因果一致性(CausalConsistency)
一种特殊的顺序一致性，对于有事务性要求的多个请求，会自动通过其内部的机制，将这些请求进行顺序排列执行，因为这里涉及到事务性场景，所以对于非事务的操作请求，相对来说降低了一些标准。
比如：一个事务涉及到三个进程A-B-C，进程A在更新完数据，进程B基于进程A更新后的最新值进行操作，进程C基于进程A更新后的最新值进行操作，依次类推。与事务操作无关的进程X在操作的时候，无所谓。
4.5.3、从角色角度
状态复制机(State Machine Replication)
一个服务端集群，有多个server主机组成，每个server主机的更新都在本地实现。
每个服务端都有一个一致性模块来接收客户端请求，没接收一次用户请求，一致
性模块的状态就发生改变，通过 状态机系统 对所有的一致性模块的状态进行管
控，只要所有的模块状态是一样的，那么server主机本地执行后的最终数据值就
是一样的，从而实现服务的容错效果。
GFS、HDFS、Chubby、ZooKeeper和etcd等分布式系统都是基于复制状态机模型实现的。
拜占庭将军问题(Byzantine Failures)
一个服务端集群，有多个server主机组成,每个server主机接收到client请求后，根
据自己本身的特性进行分析并给出执行的策略，多个server主机通过专用的通讯
方式来进行协商，并达成最终的共识结果(少数服从多数)，然后按照最终的结果进
行操作执行，从而实现服务的容错效果。
FLP定理(Fischer,Lynch ,Patterson)
三位科学家在1985年发表的分布式理论，最小化异步网络通信场景下，因为消息
通信是延迟的，所以可能会出现 只有一个节点故障(没被其他节点发现)时，其他
节点不能达成一致。这证明了在异步场景中永远无法避免的一种现象。
比如：三台主机ABC异步方式通信，在正常协商之间，因为C主机突然网络故障，
导致无法实现剩余两台的少数服从多数，从而导致业务终止执行。
4.5.4、复制状态机流程图
4.6、一致性协议
为了保证集群内部的多个节点间状态是一致的，无论是 状态复制机、专用通信方式、亦或是其他模型，必不可少的一个内容就是 如何实现多主机间的 状态机信息同步、专用通信等 -- 一致性协议。
常见的一致性协议主要有两种：
2PC：二阶段提交(Two-Phase-Commit)
事务的提交过程分为两个阶段来处理，提交事务请求和执行事务提交。
3PC：三阶段提交(Three-Phase-Commit)
事务的提交过程分为三个阶段来处理，提交事务申请、提交事务预操作、执行事务提交。
4.6.1、二阶段提交(Two-Phase-Commit)
第二步的时候在本地记录相关日志，便于异常情况下的数据恢复
优点：简单方便
缺点：同步阻塞、单点问题、及协调者异常导致的其他数据不一致问题
4.6.2、三阶段提交(Three-Phase-Commit)
第四步的时候在本地记录相关日志，便于异常情况下的数据恢复
优点：降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点：参与者在接收到预提交请求后，如果网络无法正常通信，可能导致异常情况下，依然执行事务
