开发者学堂课程【高校精品课-西安交通大学-数据库理论与技术：第三课】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/12/detail/25
第三课（三）
内容介绍：
一、 背景
二、 阶段一：单机阶段
三、 阶段二：应用服务器和数据库服务器分离
四、 阶段三：应用服务器集群
五、 阶段四：数据库压力变大，数据库读写分离
六、 阶段五：使用搜索引擎缓解读库的压力
七、 阶段六：引入缓存机制缓解数据库的压力
八、 阶段七：数据库垂直/水平拆分
九、 阶段八：应用的拆分
十、 分布式系统的意义
十一、分布式系统的优势
十二、主流的分布式架构：SOA 架构
十三、主流的分布式架构：ESB（企业服务总线）
十四、SOA 所要解决的核心问题
十五、主流的分布式架构：微服务（MicroServives）架构
十六、微服务的特征
十七、SOA 和微服务架构的差别
十八、分布式架构的理论基础
十三、主流的分布式架构：ESB（企业服务总线）
因刚才这种架构是 PUB 方式，服务和服务之间都可以相互调用，而企业服务总线，利用 ESB 企业服务总线，相当于一个中介或者一根管道，用来连接各个服务节点。存在是基于不同协议的不同服务，主要完成消息转换，解释，路由的工作，让不同的服务互联互通。叫做 ESB。
10年做核高基的项目，做国产中介，其中就做 ESP。企业服务总线也是面向服务架构的一种，没有 ESB，各个服务之间相连相当于一个地方私搭乱建，电线乱搭，现为了市容整顿弄得更加规整，可认为是 ESB，服务都连接到 ESB上，通过 ESB 转接，做服务的路由，负载均衡都能做。为一个临时基础中介 ESB。
十四、SOA 所要解决的核心问题
l 系统集成：从系统角度看，各个系统之间怎么互联互通，目的是
将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星性结构，这步往往需要引入一些概念和规范，比如ESB，以及技术规范、服务管理规范既服务治理。因服务越来越多要进行管理，所以叫做服务治理。数据有叫做数据治理，现各个大数据都存在数据治理叫做数据治理平台，数据质量的管理等一系列管理平台。但是这核心问题是有序既建立秩序。
l 系统的服务化：站在功能角度，把业务逻辑抽象成可复用的、可
组装的服务，通过服务的编排实现业务的快速再生。这里运用另一概念叫做服务编排。服务编排也叫做工作流，工作流里的工作流引擎可把服务串接起来，形成服务流程化，即为服务编排。服务编排有服务编排语言，方式有很多。目的是把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用；这步要解决的核心问题是【复用】。既东西可以复用。
l 业务的服务化：站在企业角度，把企业职能抽象成可复用、可组
装的服务，把原来职能化的企业架构转变为服务化的企业架构，进一步提升企业对外服务能力。核心问题是【高效】。既 SOA 要解决的核心问题。
十五、主流的分布式架构：微服务（MicroServives）架构
l 微服务体架构和 SOA 架构非常类似，可认为微服务是 SOA 的升
华，只不过微服务架构强调的是“业务需要彻底的组件化和服务化”，既将业务彻底的组件化和服务化，原先单个业务系统被拆分为多个可以独立开发、设计、部署运行的小应用。然后这些小应用在组合，即为微服务架构。
l 这些小应用通过服务化完成集成和交互。组件表示就是一个可以
独立更换和升级的单元，就像电脑中的 CPU、内存、显卡、硬盘一样，独立而且更换升级而不影响其他单元。
l 如果把 PC 机的各个组件以服务的方式构建，那么这台 PC 机只需
要维护主板（相当于 ESB 既企业服务总线）和一些必要的外部设备就可以。这就是微服务架构。
l 微服务组件都是以组件方式提供服务，例如 PC 机调用 CPU 做计
算，用内存存放数据，磁盘持久存，长期保存，放入磁盘里；短期放入内存里。这时调用只需知道组件地址即可。组件都有地址。微服务架构的架构图如下：
微服务架构中还有好多内容，因为微服务另一架构为云原生，前面提到的 AI 原生 nitifu，clude-nitifu云原生，其中核心的东西，微服务，还有开发和运维一体化，而且现开发越来越快速截断，截断周期越来越短。一个软件开发，从启动可能花费一年，半年，两三年才开发出来。现在很少这样。尤其是互联网公司都是快速截断，每天不停迭代，系统每天正常运转，使用的微信，淘宝，电商的平台，后台的技术团队除了运维，每天还开发新功能，新功能开发测试上线，这个周期越来越快既快速迭代。快速迭代不断发展需要大量人才的投入。
十六、微服务的特征
l 通过服务实现组件化。
l 开发者不再需要协调其他服务部署对本服务的影响。
l 按业务能力来划分服务和开发团队。团队组织也有变化，微服务
体架构上来后，开发的手段技术，还有团队组织都会发生一系列变化。
l 开发者可以自由选择开发技术，提供API服务。
特征一：去中心化
该主题后面还会提到，区块链的口号中，第一个就是去中心化。
1、 每个微服务都有自己私有的数据库持久化的业务数据。
2、 每个微服务只能访问自己的数据库，而不访问其他服务的数库。
3、 业务场景下，需要在一个事务中更新多个数据库。这种情况也
不能直接访问其他微服务的数据库，而只能通过其他微服务进行操作。既访问自己的数据库，别人数据库里的不能访问，要访问需告诉别人，让它自己去访问。这就是设计原则。
4、 数据去中心化，主要目的是降低微服务之间的耦合度，不同的
服务采用不同的数据库技术，因这时的数据库技术很多，可以才用传统的，比如 SQL、newSQL，qinSQL或者老SQL，NoSQL。
5、 复杂场景下，包含多个微服务，通常在客户端或者中间层（网关）进行处理。特征二：基础设施自动化运维既 devops，自动化部署，自动化运维 Docker，像现在的容器技术。这些技术都与这个有关。
十七、SOA 和微服务架构的差别
l 微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，
同时以 SOA 的思想进入到单个业务系统内部实现真正的组件化。
l Docker 容器技术的实现。Docker 容器在云计算中，提到云计算
想到 I,A，X,既服务 service。比如 An-sarvice 基础设施服务，既机器的硬件，将基本的系统搭建好，给提供了这种硬件还有操作系统。还有 pass，既平台基础服务，Docker 属于这层，Docker 是容器，实际为 say-pass容器技服。现很多微服务放置于这种容器里，而且这个容器轻量化既一个文件，在网上迁移或者搬运非常方便。使用起来非常方便。后面还有 dock 数据技服、sass 为软件技服，严格讲为应用技服，应为ask。比如系统安全，安全在云里可作为服务的技服，这就是所有的服务，这就是云计算的特点。提到云计算就抓住几个词：虚拟化，比如 ask 就是虚机，PDM既虚拟机。虚拟机有不同类型的，有虚拟机监控器，在操作系统做虚机，虚机里做操作系统，也有可能整个做虚机在虚机上去除不同的操作系统。现更多的用 D ocker,这个服务通过类似于有很多技术来独立运行。
l SOA 注重的是系统集成，而微服务关注的是完全分离。
下面介绍分布式基本架构的基本理论东西。分布式系统是单独一门课，架构围绕分布式的一些东西。
十八、分布式架构的理论基础
l ELP 不可能原理
l CAP 定理
l BASE 特性
l 一致性哈希
l PAXOS 算法
以上都是分布式架构理论层面。还有拜占庭将军问题，区块链里的故事机制就会使用拜占庭。
FLP 不可能原理
l 网络通信可靠情况下，分布式系统的共识问题无通用的解法。实
际上是否定性的东西。在异步分布式系统当中，即使通讯正常，还没断，但是有节点发生故障或者有恶意节点，这时无法达成一致，分布式系统的核心问题为共识问题或者一致性问题。既如何保证一致。
l 具体表述：在网络可靠，但允许节点失效（即便只有一个）的最
小化异步模型系统中，不存在一个可以解决一致性问题的确定性算法。
l 提出并证明该定理的论文“Impossibility of Distributed
Consensus with One Faulty Process”论文第一个词就是不可能性，然后分布式一致性。叫菲谢尔，既在故障进程当中，在分布式系统中，在1982年就提出。
l 启示
不要浪费时间去为一个异步分布式系统设计能在任意情形都能
实现共识的确定型算法。既算法不存在。
l 例子
1、假定有四个人 ABCD，分别位于地球的不同位置，对某一个提案进行投票。投票为：某个时候，A和D投票同意，B投票拒绝，C 收到三人的投票，本来C也要投票，如四个人都投，那结果就出来。假设两个人同意，两个人反对，就会没有结果。假设 C 同意，三比一，提案通过。但C睡着了既节点故障。这时，A、B 和 D 将永远无法在有限时间内获知2最终结果。
2、A、B 一直等待，一旦出现故障。假设没有故障既大家都正常，系统都会出意外，都会出现各种各样的原因，比如突然停电、进程死掉、系统瘫痪诸多问题。他们无法知道是因为 C 没有回答（可能是时差问题，因分布全球，不同时区，C 可能正在睡觉）还是因为回答时间过长导致一直无法收到 C 的答复。也有可能是网络问题，投票了或者作答了，但是网络线路断了或者是网络问题，消息没穿过来。
3、如果可以重新投票，则类似情形可以在每次取得结果前发生，这将导致共识过程永远无法完成。
l 启示
允许节点失效情况下，纯粹的异步分布式系统无法保证一致性在有限时间内完成。
l 另一表述：异步的分布式系统不能同时保证活性和安全性！
形式化方法中既形式化验证中，系统有两个性质，一个叫活性，一个叫安全性。安全性既系统坏事永远不发生。假设车的系统，不可能两边同时是红灯，或者同时是绿灯，发生撞车。活性就是总会有绿灯，车能走，不能说永远没有绿灯。这就是活性。系统能动态。安全性就是系统仅此发生的动态，互斥的东西，不能发生的事情永远不会发生。
在异步的分布式系统中，这两个性质不能同时达到，如果要保证安全性就要牺牲活性，反之，要保证活性就要牺牲安全性，只能二选一，不能全部得到。
1、 活性反映客户端的请求最终会被处理，既发一个命令，最终会
得到响应，不会永远石沉大海。既好事总会发生。
2、 安全性反映分布式系统处理了来自客户端的请求后不存在不一
致的状态。
l 折中方向
按照这个原理，在做设计时，就必须按照这个原理进行折中，但不理解为不做事，所以在理解比特币时，觉得他很厉害，因按照这个原理有些东西是弄不出来，将基础传在一起，就弄出来了。因为有些是违反分布式系统的理解，既比特币的设计。
弱化活性，弱化安全性。不可能原理有个前提就是有可能会发生故障，将它打破既不让其发生故障。投入大量金钱，重复多弄几个，为了保险，所有重复多弄。
就像航天系统一样，为了保证可靠，都会有备份，所有都做备份，特别是关键东西都要有备份，既坏了就有东西顶上，不至于坏了就没办法。
