开发者学堂课程【高校精品课-西安交通大学-数据库理论与技术：第三课】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/12/detail/25
第三课（三）
内容介绍：
一、 背景
二、 阶段一：单机阶段
三、 阶段二：应用服务器和数据库服务器分离
四、 阶段三：应用服务器集群
五、 阶段四：数据库压力变大，数据库读写分离
六、 阶段五：使用搜索引擎缓解读库的压力
七、 阶段六：引入缓存机制缓解数据库的压力
八、 阶段七：数据库垂直/水平拆分
九、 阶段八：应用的拆分
十、 分布式系统的意义
十一、分布式系统的优势
十二、主流的分布式架构：SOA 架构
十三、主流的分布式架构：ESB（企业服务总线）
十四、SOA 所要解决的核心问题
十五、主流的分布式架构：微服务（MicroServives）架构
十六、微服务的特征
十七、SOA 和微服务架构的差别
十八、分布式架构的理论基础
七、阶段六：引入缓存机制缓解数据库的压力
l 访问量不断增加，就会发现有些内容属于热点内容，大家就都会去访问，这就造成数据冷热不均，这需要了解。有的数据冷，有的数据热。冷热会变化，就像话题一样，一段时间一个话题很热，热一段时间既隔一段时间热度就会过去，这就是传播规律。一个话题一直热是比较少的，大部分是热一段时间可能就来新的热点，新的热点注意力就转移。数据也一样，所以每次都要从数据库重新读写，这时用到缓存，这里提到几个产品名字，redis 数据库，都可作为应用数据库的缓存。缓存原理之后再进行讲解。
l 另外的场景，对某些用户的 IP 的访问频率做限制。既用户场景针对特定机器或者 IP 地址，如果访问过高，就限制。假设访问过高有可能是恶意的，既受到攻击。那这个内存中就又不合适，放数据库又太麻烦，那时候可以使用 Nosql 的方式，比如 mongDB 来代替传统的关系型数据库。就有很多这种解决方案。
八、阶段七：数据库垂直/水平拆分
数据库垂直/水平拆分既分库分表。这在分布数据库设计当中分库分表就经常被提到，架构达到这个阶段进行分库分表。
演变过程中，交易、商品、用户的数据还在同一个数据库中，尽管采取了增加缓存，读写分离的方式，但是随着数据库的压力持续增加，数据库瓶颈仍然是最大问题。因此，考虑对数据库进行拆分，拆分有两种：垂直和水平。
l 垂直拆分：把数据库中不同业务数据拆分到不同的数据库。原来一个库，先将交易、商品、用户分别弄三个库既垂直拆分。比如：学校有综合库，教务，科研，人事，现分别教务，科研，人事各放入一个库中，将其拆分开。
l 水平拆分：把同一个表的数据拆分到两个甚至更多的数据库中，水平拆分一般来说，当单个表容量已经达到上线，因每个数据库表有容量上线，既爆表。一旦爆表，数据库可能瘫掉。既量太多，这时将表拆分到几个库里，即为拆表。表也拆分，既表拆分即为分布。原本一个表放在一个库里，现在一个表拆分成几个表。也可按地域拆，按各种各样的方式将一个表拆分开。
九、阶段八：应用的拆分
l 随着业务的发展，业务量越来越大，应用压力越来越大。工程规模也越来越大，这时候考虑应用拆分，一般使用领域模型，可将应用，商品，交易分成多个子系统。大型电商网站架构也会有，都会经历演变过程。早期可能从很小的单机的网站开始，变得越来越庞大，越来越复杂，非常庞大的技术中心，有一推技术人员，维护人员，商户人员。商户要做销售，各种商户关系，就变得非常庞大和复杂既逐步成长起来。
l 这样拆分后，可能会有相同的程序代码，比如用户操作，商品和交易当中都需要查询，就导致每个系统都会有用户查询访问相关操作。这些操作一般将其抽象出来，否则就会存在问题。这就是基础架构应用架构中的改变。既面向服务的(SOA)，面向服务器的架构，这属于应用型主机架构。数据库里其实不是数据主机，这就是应用拆分。
l 拆分后，各个服务之间怎么进行通信？已拆分，可将每个应用看成一个服务，在云化后就变成虚拟的东西既服务的东西。
l 系统分布式开发的技术，RPC 远程控制，这里有很多相关的技术，包括：webservice。有远程控制来实现。
l 通过前期这些技术解决服务之间的通讯问题。但是，互联网本身还是在不断发展，所以架构演变和优化还是在持续当中。
十、分布式系统的意义
l 之所以要发展分布式系统架构，主要是因为单机系统有许多缺点等待被解决，这是最根本的问题。假设单机系统没有问题，就没必要考虑分布式系统。所欲首先要是分布式系统有问题。
l 升级单机处理能力的性价比要低，单机处理能力主要依靠本身的 CPU，内存，磁盘。通过升级硬件来这种垂直扩展方式来提升性能，成本会很高，性价比越来越低。
l 单机处理能力存在瓶颈：CPU、内存、磁盘都有自己的瓶颈，就算不惜成本去提升硬件，但是硬件的发展速度和性能还是有限制。因空间有限。
l 单机本身的稳定性和可用性这两个指标很难满足互联网应用的需求。
十一、分布式系统的优势
l 资源共享：机器越多，系统数据，程序、外设，资源等都可以由各个系统共享，因共享使得性价比提升，这是经济性就好。
l 性价比更高：采用廉价的微型机，与同样功能的大、中型计算机相比，分布式微型机的价格仅为前者几分之一甚至几十分之一。
l 采用模块化结构：系统实现通用化与系列化，系统的扩充更方便，可以对系统进行重构，实时地动态分配与管理系统，适应不同的环境要求。
l 可靠性高：避免单点故障问题。假设中间有个别机器坏了，可能会对性能有少的影响，但不会导致全面瘫痪。以容错方式运行，增加可靠性。
l 响应速度提升
十二、主流的分布式架构：SOA 架构
最基本的是 SOA，既面向服务的架构，这与计算有关。云计算有意识无意识都在用都听过，云计算里关键的东西，一是虚拟化，将实的机器虚拟化。二、面向服务，体验，多租户。
云计算商户角度，把原来的机器自荐变成租用，租用能共享，因为租用的东西不属于自己，因为用完后还回去，别人有需要就拿去用。但是自己买一台机器，花很多钱，吃不饱，没有那么多东西去算，去存。可能会导致资源空闲，资源空闲造成浪费。云计算是公共的，对全社会开放，只要交了钱注册用户都可使用。首先是一个商业模式，商业模式变后对计算机本质没有改变，云计算对计算机本质没有改变。假设房子，原本房子是买来住，还是租来住，对建房子的人来说没有本质区别，因为盖房子，不管是买还是租，还是要按专业去建。计算机系统也一样，数据库系统，操作系统跟买还是租，这时商业型，技术层面还是这么做。这个没有本质区别。既面向服务体架构。这有关键的词——面向服务。吕健直观的讲解什么是面向服务，理解为：直面应用的东西为面向服务，但有点抽象。打一个直观的比方：比如进入电梯里，电梯里有楼层按钮，1、2、3楼，这不是面向服务，因为按1、2、3楼，但是将接口进行修改，修改为餐厅，综合厅，会议室，住宿，这就为面向服务。因调用接口时，比如到餐厅，直接按餐厅，就不用考虑几楼。假设按几楼，就不是面向服务。因为到几楼，还要问餐厅在几楼，餐厅在二楼。这是一种理解。面向服务更加面向用的方面，把软件以服务接口的形式暴露出来，功能只是使用就不用将软件安装到机器里。互联网上通过协议，就可远程调用服务。这就是面向服务。这时一种现在的架构。
l SOA 本身是一种设计理念，包括多个服务，服务之间通过相互依
赖，相互调用提供一系列完整的功能。服务与服务之间可以相互调用。
l 服务之间以独立的形式部署运行，服务之间通过网络进行调用。
架构图如下：
应写成 service，而不是 APP。如果写成 APP 的话，在移动的互联网里，一般叫 matterAPP 为原应用。
