分布式——1.系统概述

1.什么是分布式系统

分布式系统就是把一个大的系统拆分成多个服务，每个服务部署在不同计算机中运行，服务间通过网络通信，协调运行，共同为用户提供服务。
以电商系统为例：按照功能可以将系统分为 用户、商品、订单、交易等，将以上的服务组合在一起组成一个电商系统。

1.1分布式系统解决了哪些问题

1.提高了系统的并发量
随着系统功能的完善，用户量不断增长，系统的并发请求越来越高，原有的单一系统架构难以满足性能的要求，系统拆分后，可以将流量分摊到服务的各个节点中，减少单点的访问压力。
2.提高研发团队的开发效率
随着系统代码量增加，开发人员增多，所有的开发人员都维护同一套代码，常常会引起代码的冲突，每次发布版本都是全量的部署。系统拆分后，每个服务都有自己的代码仓库，减少了代码的冲突，每次测试只测试自己的服务，也只是发布自己的服务，只要保证接口不变就可以了。

1.2分布式系统特点

分布性：
分布式系统中的各个节点，部署在不同的服务器上，而各个服务器也可以部署在不同的地理位置，来实现异地灾备等功能。
并发性：
分布式系统中并发是很常见的。比如多个节点同时访问同一个共享资源，如数据库，分布式存储等。
三态：
既分布式服务间调用的三种状态 成功、失败、超时
CAP理论：
CAP原则又称为CAP定理，只的是在一个分布式系统中，Consistency(一致性)，Availability(可用性)，
Partition tolerance(分区容错性)，三者不可兼得
一致性（C）：在分布式系统中的所有数据，在同一时刻为相同的值。
可用性（A）：在集群中一部分节点故障后，集群还能响应客户端的读写请求。
分区容错性（P）：在分布式系统节点同步数据时，由于网络的不确定因素，可能导致系统中节点数据不一致的情况，为分区容错性，这在分布式系统中是必须要满足的。因此我们只能在C和A中选择一个实现。
CAP理论仅适用于Nosql场景，不适用于数据库系统

2.分布式系统带来的问题

2.1任务分解

如何把一个大的系统拆分成若干个小的服务，在分布式系统中是一个重要的问题，其中比较著名的就是领域驱动模型。
领域驱动模型(DDD:Domain-Driven Design)：
软件开发不是一蹴而就的，在开发前我们需要进行业务的梳理，在梳理的过程中会形成某个领域的概念，以概念模型一步步驱动软件的设计，通过设计实现领域模型，这就是领域模型的概念。
通俗的讲就是，在软件设计之前要与业务人员沟通，熟悉业务，在此过程中，建立业务模型，根据业务模型进行分布式系统服务的设计。

2.2节点通信

服务间采取什么样的通信方式，以保证系统业务可以正常的运行，常用的通信方式有RPC、消息中间件等。

2.3网络分区（脑裂）

当分布式网络出现异常时，导致节点间的延迟不断增大，最终导致分布式系统中，只有部分节点能够正常通信。
如下图：系统初始状态有6个服务节点组成系统统一对外服务，在网络异常时，导致系统出现两个环境同时对外提供服务，（既server4、server5、server6从原来的系统中分裂出去组成一个新的系统既为脑裂）

3.分布式和集群的关系

分布式就是将一个业务拆分成若干个子业务，部署在不同的服务器上，提高系统的性能。
集群是将同一个业务部署在多个服务器上，提高业务的可用性。

4.系统架构演变过程

单点架构：应用服务和数据库服务在同一个服务器上

应用服务和数据库服务部署在不同的服务器上

应用服务部署多个节点，组成应用服务集群。提高系统的可用性和吞吐量。

数据库读写分离：分离数据库的读写请求，增加数据库的性能

分离数据库的查询和搜索请求，增加单独的搜索服务器。

增加缓存服务器，提高系统的查询性能

数据库拆分：一般mysql的单表数据量要控制在500w-1000w之间，超过1000W会有性能问题

此博客主要说了一下分布式系统的概念，分布式系统架构的演变过程，以及演变过程中架构的变化而引入的问题，并没有给出响应问题的解决方案，解决方案会在后续的博客中给出。