一.分布示框架最核心功能：RPC远程调用技术。常见比较熟悉的：RMI 、Web Service、Http
基于比较上述比较，综合考虑 RMI是比较合适的方案，基本没有学习成本。而跨语言问题基本可以勿略。
如果服务端是单个的话，这个方案就可以用了。实际上服务端是多个的 ，那么新的问题又来了。
负载均衡：这么多个机器调用哪一台?
服务发现：怎样发现新的服务地址呢？
健康检测：服务关宕机或恢复后怎么办？
容错：如果调用其中一台调用出错了怎么办？
二.分布式架构的三种解决方案
- 基于反向代理的中心化架构
- 嵌入应用内部的去中心化架构
- 基于独立代理进程的Service Mesh架构
1.基于反向代理的集中式分布式架构
这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队(一般是运维或框架)负责治理和运维。
常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性(Nginx比F5易于配置)。
Http+Nginx 方案总结：
优点：简单快速、几乎没有学习成本
适用场景：轻量级分布式系统、局部分布式架构。
瓶颈：Nginx中心负载、Http传输、JSON序列化、开发效率、运维效率。
2.嵌入应用内部的去中心化架构
这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。
这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。
我们所熟悉的 dubbo 和spring cloud Eureka +Ribbon都是这种方式实现。
相比第一代架构它有以下特点几点：
l 去中心化，客户端直连服务端
l 动态注册和发现服务
l 高效稳定的网络传输
l 高效可容错的序列化
3.基于独立代理进程的架构(Service Mesh)
这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡。
如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同第二代架构。
三.3种架构的比较
