1.什么是分布式系统？
若干多个独立计算机的集合，展现给用户的是一个统一的整体。
2.为什么会有分布式系统？——分布式系统开发的演进过程（来自官网）
ORM:Object Relational Mapping —对象关系映射
MVC:Model–view–controller —模型（Model）、视图（View）和控制器（Controller）
RPC：Remote Procedure Call—远程服务调用
SOA ：Service-Oriented Architecture—面向服务架构
2.1单一的应用架构—相当于鸡蛋放到了一个篮子里。肯定不好
将所有的业务一起统一打包到服务器上，此时存在一个问题，当需要某一个业务需要扩展，需要将所有的业务重新打包。不利于维护。这种架构只能去优化对象关系映射（，简称ORM），即简化对数据库的增删改查。
优点
- 开发简单，集中式管理
- 基本不会重复开发
- 功能都在本地，没有分布式的管理和调用消耗
缺点
- 效率低：开发都在同一个项目改代码，相互等待，冲突不断
- 维护难：代码功功能耦合在一起，新人不知道何从下手
- 不灵活：构建时间长，任何小修改都要重构整个项目，耗时
- 稳定性差：一个微小的问题，都可能导致整个应用挂掉
- 扩展性不够：无法满足高并发下的业务需求
2.2垂直的应用架构
将每一个具体的业务放在一台独立的服务器上，这样每一业务可以进行独立的扩展。 此时产生了两个问题。
- 每一个具体的业务，包括前端页面和后端的业务逻辑。前端页面经常改动，业务逻辑则是经常不变的。此时修改web页面，业务也需要重新进行打包等。所以前端web框架决定了架构的好坏。
- 业务和业务之间互相调用交互，有一些核心业务（公共模块）经常被调用，不能重复利用。
2.3分布式服务框架
将具体的业务进行解耦，分为web页面和业务逻辑两部分，此时业务逻辑不发生任何改变，就可以随意修改用户web界面了，此时将核心业务抽取出来，提高业务的服用。
此时产生了一个问题：如果web界面和具体业务不在一台服务器上面，页面调用具体的业务逻辑存在跨服务器问题。RPC远程过程调用决定了该框架的好坏。
跨服务器调用服务存在传输问题，如何对请求，以及请求结果进行高度的序列化和反序列化存在一定影响。
2.4流动计算架构
为了解决上述问题，出现了RPC（远程过程调用）。在分布式架构基础上，引入了调度治理中心，提高集群的利用率。
此时产生了一个问题，分布式服务框架，虽然解决了跨服务器调用的问题，将具体的业务进行了分离，如果业务量增大，服务器集群也会不断地增大，有的业务量小，却给了很多的服务器，有的业务量大，反而给的服务器少，此时就会造成了资源浪费的问题，我们想，谁可以动态的为我们管理一下服务器集群呢，谁业务量大，多分配服务器给它一些，谁的业务量小，就可以适当的减少一些服务器。此时产生了流动式计算机架构。
3.RPC（Remote Procedure Call）是指远程过程调用
一种进程间通信方式，一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
国王1和国王2之间不进行直接联系，而是通过太监1和太监2进行沟通，国王1通知太监1，说“我想国王2了”，于是太监1就通过丝绸之路联系到了太监2，太监2将国王1的请求转述给了国王2，国王2说“想得美”，于是太监2国王2的反馈结果通过丝绸之路告诉了太监1，太监1将结果再次转述给国王1，此时完成了服务器之间的交互。
这个过程中最重要的就是 序列化 和 反序列化 了，计算机只识别二进制数据，所以数据传输的数据包必须是二进制的，你直接丢一个 Java 对象过去，人家可不认识，你必须把 Java 对象序列化为二进制格式，传给 Server 端，Server 端接收到之后，再反序列化为 Java 对象。
3.1常用的RPC框架
Dubbo、 gRPC、 Thrift、 HSF（High Speed Service Framework）
RPC的性能由以下两点决定：
- 服务器与服务器快速建立连接的问题---通讯效率
- 在建立连接基础后，服务器之间传什么格式的数据也存在一定的影响。---反序列化效率。
4.Dubbo
Apache Dubbo |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
4.1Dubbo特性
面向接口代理的高性能RPC调用
服务器之间的服务调用，调用的是接口，不是具体的细节、
智能负载均衡
根据业务使用情况，动态分配服务器
服务自动注册于发现
注册中心上下线感知
高度扩展能力
内部核心插件，可进行扩展
运行期流量调度
灰度发布，例如新的业务产生了，新业务部署在一部分服务器上面使用，长时间后新业务运行没有问题，在适当增加新业务的服务器的数量，是一个不断过度增加服务器的过程。
可视化的服务治理与运维
提供可视化界面进行相应的查询
4.2Dubbo架构（4部分构成，服务消费者，服务提供者，注册中心，监控中心）
| 节点 |
角色说明 |
| Provider |
暴露服务的服务提供方 |
| Consumer |
调用远程服务的服务消费方 |
| Registry |
服务注册与发现的注册中心 |
| Monitor |
统计服务的调用次数和调用时间的监控中心 |
| Container |
服务运行容器 |
调用关系说明：
0.服务容器负责启动，加载，运行服务提供者。—start
1.服务提供者在启动时，向注册中心注册自己提供的服务。—register
2.服务消费者在启动时，向注册中心订阅自己所需的服务。—subscribe
3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。—notify
4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。—invoke
5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。—count
