1. 分布式系统定义

分布式系统（Distributed System）是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。分布式系统是建立在网络之上的软件系统。

随着互联网发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

2. 应用的架构演进

第一阶段

2.1 单一的应用架构（All in One）：

当网站的规模很小，访问量很小，可以把所有功能放在一个应用，然后打包这个应用放在服务器上。如小型的购物系统，收银系统。这样开发简单，部署简单。

优点：

1. 开发简单
2. 部署简单

缺点：

1. 拓展不容易，如果需要修改或是拓展某个功能，都需要把整个应用重新打包，再重新部署到服务器上。
2. 协同开发不容易，多人开发同一个应用，容易把代码改坏

第二阶段

2.2 垂直应用架构（Vertical Application）：

可以将之前的大应用拆成几个独立的互不相干的小应用，每一个小应用独立部署到不同的服务器上。哪一个功能需要修改，就只改那个功能，或是流量增加了，就增加服务器。

优点：

1. 协同开发容易
2. 性能拓展容易，如某一个功能或模块访问量大了，只需要为该应用增加服务器

缺点：

1. 界面 + 业务逻辑的实现分离，美工一改页面，整个应用就要重新部署
2. 应用不可能完全独立，大量的应用之间需要交互

第三阶段

2.3 分布式服务架构：

当业务越来越多，交互越来越多，我们就可以把他们的核心业务单独抽取出来

比如，可以将功能的界面和业务逻辑分别抽取出来。这样的好处是，比如我们需要修改界面时，只需要修改界面后，重新部署应用并重启承载界面应用的服务器，而用户业务的服务器还在运行不受影响。

这里有一个点，RPC（远程过程调用）：

原本的单体应用中A功能要调B功能，只需要在同一个进程内（同一个Tomcat进程）调用。而现在A功能和B功能在不同的服务器，需要用到RPC来实现。

分布式架构的难点就是，如何进行RPC，以及如何拆分业务，更好的实现功能服用。

该阶段的问题：

1. 资源浪费，如某一个功能访问量很小却又很多服务器在跑，另一个功能访问量很大却只有很少服务器在跑，需要有一个架构来调度

第四阶段

2.4 流动计算架构：

• 调度、治理中心 基于访问压力实时管理集群容量，提高集群利用率

3. RPC

3.1 定义

RPC（Remote Procedure Call）是指远程过程调用，核心就是两台服务器架起一个网络通信，然后发起请求，响应结果。

它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP/IP或UDP，为通信程序之间携带信息数据。RPC将原来的本地调用转变为调用远端的服务器上的方法，给系统的处理能力和吞吐量带来了近似于无限制提升的可能。在OSI网络通信模型中，RPC跨域了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

3.2 过程

(1) 客户端（client）以本地调用方式（即以接口的方式）调用服务； (2) 客户端存根（client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）； (3) 客户端通过sockets将消息发送到服务端； (4) 服务端存根( server stub）收到消息后进行解码（将消息对象反序列化）； (5) 服务端存根( server stub）根据解码结果调用本地的服务； (6) 本地服务执行并将结果返回给服务端存根( server stub）； (7) 服务端存根( server stub）将返回结果打包成消息（将结果消息对象序列化）； (8) 服务端（server）通过sockets将消息发送到客户端； (9) 客户端存根（client stub）接收到结果消息，并进行解码（将结果消息发序列化）； (10) 客户端（client）得到最终结果。 RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。 注意：无论是何种类型的数据，最终都需要转换成二进制流在网络上进行传输，数据的发送方需要将对象转换为二进制流，而数据的接收方则需要把二进制流再恢复为对象。

3.3 影响RPC性能因素

1. 通信效率：框架能否快速在各个服务器之间建立起连接
2. 序列化与反序列化效率：框架序列化与反序列化机制速度

所以RPC的两个核心模块：1. 通讯 2. 序列化