十万个为什么之为什么需要分布式架构

在刚刚接触分布式这个词语的时候，可能许多同学们会纳闷，到底什么是分布式，分布式能做什么和我们平时用的集中式架构有什么区别。下面就让我们一起去了解分布式架构吧~

分布式系统

简单的来说，分布式系统就是一大批服务器组成一个集合，服务器之间使用网络通信进行数据传输和服务调用。相对于单机系统，其性能得到提升，对于用户来说，仍然是一个整体连贯的系统。

为什么要用分布式架构

集中式系统是一种Scale out/in，想要提高系统服务性能，要么就是升级多核增加CPU核心数量提高处理能力，要么就是提升其他硬件性能。提升硬件的天花板低，因此当企业的服务扩展到一定程度，无法从提升硬件水平来提高服务质量，分布式架构应运而生。

为了让同学们更好的理解为什么要选择分布式架构，我们可以从分布式架构的历史发展上入手，分析每个阶段所用架构存在的问题，以及如何使用更新的分布式架构进行解决。

分布式架构的发展历程

单体应用

相信大多数看这个文章的同学都有着单机应用开发的经验，在单体应用开发中，一般以MVC(Model, View, Controller)模式开发，这种单体应用开发模式的特点如下：

1、所有的代码统一打包成一个部署文件——war或者jar。

2、代码调用的api都是本地库或者是代码中的，基本上不存在远程服务调用。

3、当需要发布新版本时，必须停下所有业务进行升级。

在业务发展的初期，大家使用的初始架构都是单体应用，应用的服务体量没那么大，也不需要存在高并发、扩展性的考虑，仅仅只需要解决业务需求。但是这种单体应用架构随着公司体量的增大和使用人群的扩展，存在许多问题：1、随着业务的增加，代码量也随之增加，代码之间相互调用，对于新人的学习成本增加。2、出现bug时，问题可能出现在代码的每一个角落，排查问题成本增加。3、单体应用的可维护性差，扩展性差，当有新业务接入时，基本上需要修改所有的业务逻辑，牵一发而动全身。

RPC架构

RPC(Remote Procedure Call)，远程方法调用。其功能简单来说：比如两台服务器A和B，在A服务器上部署了一个应用，在B服务器上部署了一个应用，A服务器可以使用RPC架构通过网络传递表达调用语义和传达调用的数据，达到远程调用服务的功能。

目前比较常用的RPC框架：Dubbo，Thrift，Avro-RPC， Hessian，gRPC

RPC过程及技术栈：

1、服务提供者发布服务，定义服务接口，数据结构。

1、客户端和服务器端之间建立TCP连接，RPC的所有数据交换使用这个TCP连接进行传输。(现在更多使用的是netty)

2、客户端将远程调用的语义和入参序列化为二进制，然后通过寻址将序列化的二进制发给服务器。(序列化和反序列化常用技术：xml，json，hessiaon等)

3、服务器收到请求，进行处理，处理完成的结果，序列化成二进制之后传输给客户端。

4、客户端反序列化结果，return服务器端的请求结果，RPC过程结束。

如果想要使用RPC框架实现大型应用，必须要加上服务治理节点。服务治理节点需要实现动态注册，动态发现，服务管控，调用链分析等功能，复杂度高。

SOA面向服务架构

SOA可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

通常的SOA的实现是通过ESB，WSDL来处理。其粒度通常来说是比较粗的。也存在服务治理方面的问题。关于SOA的详细细节不过多赘述，可以参考SOA面向服务架构

微服务架构

传统的SOA是一种面向服务的单体架构，强调服务共享和重用，经过几十年的SOA实践探索，人们已经发现服务的解耦性必须高于服务的复用共享性，因此催生了微服务架构。官方给微服务的定义为：1、一些独立的服务共同组成系统；2、每个服务单独部署，跑在自己的进程中；3、各个服务为独立的业务开发；4、分布式管理；5、强隔离性。

简单来说，微服务架构是采用一组服务的方式来构建一个应用，服务独立部署在不同的服务器或者相同服务器的不同进程中。服务之间使用数据进行通信，比如RPC或者HTTP等。不同的服务之间相互不影响，甚至可以使用不同的编程语言进行开发。