1_分布式架构的演进

集中式到分布式的发展

1. 集中式的问题
   1. 大型主机太过复杂, 导致培养一个能够运维大型主机的人成本高.
   2. 大型主机很贵.
   3. 单点问题: 一台大型机出现问题, 那么整个系统将不可用.
2. 使用分布式的意义
   1. 通过垂直扩展(升级CPU, 内存等)的方式提高性能, 成本原来越高.
   2. 处理能力存在瓶颈, 即硬件的发展和性能也是有限的.
   3. 单机系统存在的可用性和稳定性问题, 这点我们又必须得解决.

分布式架构的常见概念

1. 集群
   • 集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台.
2. 分布式
   • 分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”. 这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信.
3. 节点
   • 指一个能够独立按照分布式协议完成一组逻辑的程序个体, 具体的项目中, 一个节点表示操作系统上的一个进程.
4. 副本机制
   • 副本指在分布式系统中为数据或服务提供的冗余.
   • 数据副本指在不同的节点上持久化同一份数据, 当某个节点的数据丢失时, 可以从副本上提取数据.数据副本是分布式系统中解决数据丢失问题的唯一手段.
   • 服务副本表示多个节点提供相同的服务, 通过主从关系来实现服务的高可用方案.
5. 中间件
   • 中间件(Middleware)是处于操作系统和应用程序之间的, 为开发者方便的处理通信, 输入输出的软件.

架构的发展过程

1.  单应用架构
   • 互联网早期, 会把所有的软件和应用部署在一台机器上, 这样完成一个简单系统的搭建.
   • 
2. 应用服务器和数据库服务器分离
   • 随着网站的上线, 访问量的提升, 服务器的负载会慢慢提高. 在服务器超载之前, 我们应该去提高网站负载能力.
   • 这时将web服务器和数据库服务器拆分, 不仅提高了单机的负载能力, 也提高了容灾能力.
   • 
3. 应用服务器集群
   • 随着访问量的继续增加, 单台应用服务器已无法满足需求, 这时我们可以增加应用服务器.
   • 通过应用服务器集群将用户请求分流到各个服务器中, 提升负载能力.
   • 此时多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务.
   • 
   • 而此时就会出现各种问题, 如用户请求由谁来转发到具体的应用服务器, 用户如果每次访问到的服务器不一样, 那么如何维护session.
4. 数据库压力变大, 数据库读写分离
   • 假如我们单纯的把数据库一分为二，然后对于后续数据库的请求，分别负载到两台数据库服务器上，那么一定会造成数据库不统一的问题.
   • 所以我们一般先考虑读写分离的方式.
   • 
   • 而每个数据库又可以实现主从的模式
     • 主从数据库之间的数据同步 : 可以使用 mysql 自带的 master-slave方式实现主从复制.
     • 对应数据源的选择: 如mycat
5. 使用搜索引擎缓解读库的压力
   • 数据库做读库的时候, 模糊查找效率不是特别高.
   • 这个时候就需要引入搜索引擎了, 使用搜索引擎能够大大提高我们的查询速度，但是同时也会带来一 些附加的问题，比如维护索引的构建.
   • 
6. 引入缓存机制缓解数据库的压力
   • 随着访问量的持续增加, 逐渐出现许多用户访问统一部分内容的情况, 对于这些热点数据, 我们可以使用缓存技术, 如Redis作应用层的缓存.
   • 
7. 数据库的水平/垂直拆分
   • 尽管采取了增加缓存，读写分离的方式，但是随着数据库的压力(IO, 数据量)持续增加，数据库的瓶颈仍然是个最大的问题.
   • 垂直拆分：把数据库中不同业务数据拆分到不同的数据库.
   • 水平拆分: 把同一个表中的数据拆分到两个甚至跟多的数据库中.
   • 
8. 应用的拆分
   • 随着业务的增多, 应用的压力越来越大, 这个时候就可以考虑讲应用拆分, 按照领域模型将我们的用户, 商品, 交易拆分成多个子系统.
   •