分布式系统主要包含的内容很多，我就针对两个核心方面做一下解读：分布式应用服务和对象远程调用、数据的分布式存储。先说说分布式应用服务以及对象远程调用的元老之一：
EJB/RMI（Enterprise Java Beans/Remote Method Invocation）吧！
分布式应用和对象远程调用那个时候的Java工程师，对于EJB的大名如雷贯耳，曾经EJB VS Spring大战（Spring With Not EJB）让程序员们的论战激情兴奋。其实争论的主题就是需不需要组件间实现分布式调用，并在分布式网络环境保持住组件状态，到底什么是分布式环境的组件状态呢？所谓分布式服务组件的无状态 VS 有状态
简单点说，有状态就是后端服务组件让远程调用过程看起来更像本地化调用，客户端不用考虑过多组件状态hold的问题，这样更容易设计出纯粹的面向对象化组件。而无状态反过来，后端服务组件专注于接收客户端请求并处理问题，给予客户端回应就够了，不要hold住状态徒增烦恼，状态保持的事情让客户端自己解决。
例如：购物车就是个例子，无状态的购物车，服务组件是让客户端通过cookie解决购物清单问题；有状态的购物，组件服务是自己保持住购物清单状态，那么客户端和服务端的对象看起来责任更清晰。
Rod Jonhson（Spring之父）就是用这本书掀起了当年的Spring的夺位之战。
大战最终的结局大家已经很清楚了——Spring逆袭完胜，EJB从此淡出江湖。无状态调用模式成为了主流，当然EJB本身的问题也不少，虽然之后EJB3标准由Hibernate作者重新操刀设计，也是为时已晚。曾经我也是EJB力挺者之一，也跟着EJB一起淡出江湖了！_"
其实这种胜出，本质上是分布式系统架构向单态架构的认怂。JavaEE的头牌EJB（企业级JavaBean）在当时代表着一种超前的设计，这种设计架构也算是当前流行的微服务架构的前浪吧，只是被拍死在了沙滩上。我们看看当时EJB VS Spring 架构：
上面的图是JavaEE的组件服务通讯图，有独立部署的远程Remote EJB容器，也有和WEB一起部署的本地Local EJB容器，它们作为组件互相之间通信（RMI），既可以WEB应用访问EJB，也可以EJB访问EJB，通过JTA（JAVA事务接口）统一管理数据库的事务操作，实现真正的分布式事务。像不像现在的微服务，像不像现在的常用的RPC调用，作为分布式系统架构，难道它不标准吗，难道这个架构它不美吗！！！
我们再看看Spring早期逆袭的架构：
上图是Spring的SSH架构图，典型的单实例架构，通过一个AOP切面拦截技术，对程序员代码层面的实现了事务调用的隐藏和透明化，让开发专注于自身的服务。这就很有亲和力，架构看起来是不是很简单。
对了，就是用这种简单的架构打败了看起来很美但复杂的架构。所以你问我，分布式系统的优点是什么？它很美，通过网络服务的组件化，实现更纯粹的面向对象模型，给程序员一个统一的编程模式来应对分布式服务在网络上的复杂性。
那分布式系统的缺点又是什么呢？
头号缺点，部署复杂，就凭这点，就极不利于测试，严重影响敏捷。这个真的不是单EJB部署复杂，只要是分布式应系统，就一定部署复杂，我们可以想想目前的微服务，再轻量化设计，依然逃不开部署复杂的问题，虽然生产环境部署分开发布也有好处，但是90%的部署都发生在开发阶段，那么频繁的测试、开发调试和重新启动部署，对于个体程序员来讲，就是比单实例服务要更加是个沉重负担。
第二个缺点就是将原来集中在数据库的SQL访问模式转变成了网络服务之间的接口调用，无论是EJB也好，微服务也好，这种分布式系统的调用模式本质都是反人性的，因为人都喜欢集中在一个中心去解决问题，形式简单，出现变化更容易定位和适应，分散不同地方的服务，无论从服务编排也好，接口变更也好，错误跟踪也好，让人去处理都太费劲了。