分布式概述及其带来的问题

分布式系统的概念

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。随着互联网的飞速发展，用户量急剧增多，互联网产品越来越多样化，内容越来越多，传统的单体结构系统已经无法满足需求，分布式系统就应运而生。分布式系统通过服务化，即SOA架构的方式，采用分而治之的策略，通过业务上的拆分，将海量用户的访问量进行拆分，以满足系统的高可用性，高性能，可伸缩，可扩展的需求。

由传统单体架构到分布式架构

J2EE架构

最早的传统架构是J2EE架构，就是Java平台企业版的简称，它极大的促进了企业开发和定制信息化系统的进展。J2EE架构将软件架构分成Web层（负责与用户交互或对外提供接口），业务层（实现系统的业务逻辑），数据层（对业务层处理的数据进行持久化）。J2EE架构对单体架构进行了分层，也在一定程度上进行了逻辑上的拆分，但是对多个业务的逻辑实现依然被放在同一个项目中，运行在同一个JVM中，随着业务逻辑的更加的复杂，系统在新功能的迭代上、运维商愈发的困难。

SSH架构

在J2EE架构还没有完全奠定地位时，SSH架构出现了，Struts的MVC模式，Spring的IOC控制反转和AOP面向切面编程，以及Hibernate、Mybatis的更加灵活轻便的数据持久化，使得开发效率大大的提高。但是整体结构依然是传统的单体架构，从J2EE到SSH，依然没有摆脱单体化。

服务化架构

J2EE和SSH的传统单体架构，随着互联网的发展，面对海量用户的高并发请求就愈发显得力不从心，业务模块耦合在一起，性能的瓶颈无法突破，运行维护以及后续开发也是困难重重，面对这些问题，SOA架构应运而生。

SOA架构即面向服务的架构，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来，使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。它的核心思想就是面向服务，并将多个服务连接起来，进行服务治理。SOA的实施具有几个鲜明的基本特征：可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。

SOA架构现在比较主流的实现方式有Web Service和ESB。

一、Web Service

Web Service使得运行在不同机器及操作系统上的服务可以互相发现和调用，通过某种协议交换数据。现在我们用的比较多的也就是这种形式，下图是Web Service的工作原理：

Web Service的实现方式有SOAP的方式和REST的方式。

（1）SOAP

SOAP是通过使用WSDL、UDDI来实现。WSDL基于XML的网络服务描述语言，WSDL 是一种使用 XML 编写的文档。这种文档可描述某个 Web service。它可规定服务的位置，以及此服务提供的操作（或方法）。UDDI 是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。是一个独立于平台的框架，用于描述、发现、集成Web Service。SOAP便是基于XML，使系统在http之上进行信息交换，它的请求便是XML形式的。

（2）REST

REST是一种软件架构风格，是一组架构约束条件和原则。相较于SOAP，REST更加的简洁方便，现在我们普遍使用的都是以REST实现Web Service的方式。那么REST风格是什么样子的呢？

首先我们先来了解一下REST风格服务的请求，比如我们需要对事件进行操作，url为：/api/event，我们发起的请求有如下规则：GET请求：获取事件、POST请求：创建事件、PUT请求：更新事件、DELETE请求：删除事件。其中需要具体对某一条事件进行操作的，比如要删除某一条事件则为：DELETE请求，url为：/api/event/id。需要更新某条事件则为：PUT请求，url为：/api/event/id，然后请求数据中包含该事件的内容。REST风格的服务应该是如上设计，而不是诸如：/api/event/getEvent、/api/event/deleteEvent之类的。REST风格的url中不应有动词，都是用名词。我们通过一张图来直观的看一下两者的区别。

通过上图我们能很直观的看出来，非RESTful风格的请求，对同一个资源的不同请求，分别有不同的url，而RESTful风格的请求，对同一个资源的不同请求，是相同的url，通过请求方式的不同，进行不同的操作。RESTful风格的请求，更加的简洁规范。

其次是状态值，我们通常返回给前端的数据，经常会有比如status：0之类的后台定义的状态值，还需要前端沟通了解状态值代表什么意思，而REST则建议使用Http的标准值，比如200表示请求成功，400表示请求异常，500表示服务器异常诸如此类。

REST有如下需要满足的约束特征：

1. 客户端-服务器：客户端与服务器隔离开来，由客户端发送请求，服务器响应。

2. 无状态：客户端发送的请求必须包含本次请求所需的所有信息，服务器不保存客户的任何数据在另一个请求中使用。

3. 分层系统：可能会有中间层的服务来处理诸如安全、缓存等问题，以提高系统的性能，但是与服务器隔离开，客户端不必了解其中的细节。

4. 可缓存：可以适当的缓存请求，提高效率。

5. 统一接口：客户与服务之间的交互，子服务之间的交互需要有统一化的接口。

二、ESB

ESB是企业服务总线的简称，是用于设计和实现网络化服务交互和通信的软件模型。ESB没有中心化的服务节点，每个服务都是通过总线的模式插入系统，并通过总线的流程编排和协议转接能力来组合实现业务处理能力。下图是ESB的架构：

SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

传统的单体结构系统将服务，数据库放进一个单体的物理机，就是一个节点。分布式架构是基于网络的，将系统进行服务化，做拆分，放在一个个单体的物理机上，就是一个个节点，通过网络将这些节点连接起来，使节点之间能够正常的通信，就需要遵循RPC协议，使用一些RPC框架。

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，为通信程序之间携带信息数据，RPC使得开发包括网络分布式多程序在内的应用程序更加容易。RPC的主要目标是让构建分布式系统更加方便，在提供强大的远程调用能力时不损失本地调用的语义简洁性。运行时,一次客户机对服务器的RPC调用,其内部操作大致有十步，他的工作原理如下图所示：

现在比较常见的开源的RPC框架有Dubbo、Spring Cloud、Brpc、Grpc等框架，其中Spring Cloud中整合了服务治理，负载均衡，容错保护等一些优秀的开源组件，一般用来开发现在很流行的比较轻量级的服务化架构，微服务。

分布式系统中我们面临的问题

现在我们基于网络构建分布式系统，将多个系统连接起来，就要面临我们使用单体架构时不会遇到的问题。

一致性问题

分布式系统中的一致性指应用系统的一致性和数据的一致性。多个系统之间互相通信，就有可能遇到例如：

(1) 调用超时：系统A调用系统B超时，系统A得到超时反馈，但不确定系统B是否已经处理结束，就会造成不一致。

(2) 掉单：系统A和系统B分别为对方的上下游，如果系统A中存在一个订单，而系统B中不存在，就会导致掉单。

(3) 缓存与数据库的不一致：面对海量的访问请求，我们经常会需要在数据库前加一层缓存，这个缓存与数据库之间如何保证一致性。

CAP定理

CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多实现两点，三者不可兼得。CAP定理主要是针对分布式系统各节点之间的通信提出的定理。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的请求。

分区容错性（P）：分布式系统中的节点之间的通信有可能失败，在这种情况下，系统要能够容纳这种错误。

分布式系统中必然存在着分区，而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。那么根据CAP定理，C与A我们只能择其一实现。那么为什么实现P的情况下，C与A不可兼得呢，我们来分析一下。

假设节点A与节点B，它们中的数据是一致的，然后我们发起请求，修改了节点A中的数据，节点B中的数据也要相应的更改，但是出现了网络延迟等问题，节点B中的数据没有更改，依然是旧数据。这时，请求节点B中的数据，但是数据还没有同步，那怎么办呢？如果我们要满足一致性，就应阻塞这次请求，等节点B中的数据得到更改，这样可用性就无法满足；而如果我们要满足可用性，那么我们就要返回节点B中的旧的数据，这样一致性就无法满足。所以我们就需要结合实际情况，做出取舍，是满足一致性还是满足可用性。

其他

其他还有比如分布式事务的问题，一个设计多个子系统的事务如何实现；还有分布式系统的缓存，搜索，日志，配置中心等，都与单块系统差别很大，就需要用到Redis、Elasticsearch等技术来解决。

总结

根据上边的概述，我们可以总结出分布式系统的关键点。当从一个单块系统演变成基于网络，连接多个节点的分布式系统，为了节点之间的通信，接口设计上就必须更加的规范，统一；然后服务不再全部放在一台服务器上，所以各节点的之间的一致性就必须想办法解决；节点之间互相远程调用，需要满足我们之前所说的RPC协议，我们就需要选择合适的RPC框架进行分布式系统的开发；为了满足分布式系统的缓存，搜索等功能，我们需要选择适合的技术，来解决这些问题。

参考文献

https://www.cnblogs.com/xybaby/p/7787034.html

李艳鹏《分布式服务架构：原理、设计与实战》

https://www.imooc.com/article/283841

https://blog.csdn.net/qq_21383435/article/details/80032375