分布式系统次要蕴含的内容很多，我就针对两个外围方面做一下解读：分布式应用服务和对象近程调用、数据的分布式存储。先说说分布式应用服务以及对象近程调用的元老之一：
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 也好，微服务也好，这种分布式系统的调用模式实质都是反兽性的，因为人都喜爱集中在一个核心去解决问题，模式简略，呈现变动更容易定位和适应，扩散不同中央的服务，无论从服务编排也好，接口变更也好，谬误跟踪也好，让人去解决都太吃力了。
因而 Spring 的单体服务就是凭借着部署简略、适应麻利、人性化等特质，战胜了 EJB，分布式系统第一次完败。然而为什么最终仍然演化出了微服务架构呢？而且热度不减当年，其实我认为就是已经 EJB 热度的又一次轮回，SpringCloud 也开始了当年 EJB 之路。微服务在架构拆解之路上，甚至开始了数据库和微服务打包独立的状况，上面是微服务的架构模样：
上图是 API 网关进行多个微服务的调度，微服务之间相互调度，每个微服务领有本人的独立数据库，都是从一个传统 Master 单库切分而来，Master 库也逐步成为数据中心库，提供根底数据交换和数据分析（OLAP）
咱们看看微服务的架构和下面的 EJB 分布式架构如许的像，其实都是一个血脉遗传下来的，那就是分布式系统。然而微服务演变到拆库就真的好吗？我不敢苟同，咱们能够把数据库的不同数据表比喻成一个家庭的多个成员，难道把家庭成员强行拆开就肯定好吗？家里原来专用一台电视机，当初拆分一个成员，就要配一台电视，难道看电视还要跑回来看吗？这就是类比了数据字段到底是冗余，还是走接口调用？这个会让设计者太苦楚的，实质是反兽性的。
为什么非要这样做呢？说到底就是想让关系型数据库实现垂直切分，造成更好的性能程度晋升，也就是说，问题根子出在关系型数据库身上了，关系型数据库人造就不反对分布式化，无奈更好的实现数据库级的程度伸缩，所以未来肯定是分布式数据存储系统代替关系型数据库的时代。因为咱们如果有了一个便宜且性能弱小的数据库系统，通过程度伸缩解决性能问题，咱们又何必吃力的搞业务数据的垂直切分呢！这就是下来说分布式存储的关键作用。
分布式数据存储
数据的分布式存储具体表现形式也就是分布式数据库，分布式数据库不同于分布式应用服务，不存在开发测试阶段吃力的公布重启，所以并不影响敏捷性；另外数据调用都集中在一个拜访代理上，因而不须要像分布式应用服务那么反兽性的思考接口治理，分布式数据库的程度伸缩力，恰好解决了微服务必须分库的难堪问题，能够让程序员专一于数据拜访的业务问题上。既然这么多益处，为什么不能大规模利用呢？问题的本源就出在事务上了！
为什么关系型数据库就具备 ACID 的事务的劣势呢？先简略点说说事务的原理，事务就是对数据的加锁解锁，给数据行集加锁，我（事务）要解决一行数据，我（事务）就申请一把钥匙，给数据行上个锁，其他人（事务）等着我解锁了，其他人能力拜访。这个操作放到以单机设计为主的关系型数据库上好解决，然而放到现在的分布式数据库环境，这就特地麻烦了，因为数据被分成片，散布在不同的机器节点库中，事务加锁就要定位到所有相干的节点，事务问题就酣畅淋漓地体现出了分布式系统在网络环境中多节点合作的复杂性，合作越严密的事件，分布式系统干起来越吃力，为什么 Key/Value 数据库，例如 Redis 用起来最舒服，也很风行，就是数据相互之间没什么协作关系。
分布式数据库事务这个够呛的问题，也没有难住平凡的计算机科学家们，例如：TIDB 继承自 Google Percolator，应用 Percolator 事务模型，实现了分布式事务。也就是当初又呈现的一个 新名词：NewSQL，传统关系型数据库 ACID 个性 +NoSQL。
咱们先说说分布式数据库的要害是什么？就是对一大块数据进行分片（分块 / 分区），平平整整地放到不同的物理节点上，放弃每个节点的数据量差不多是最佳的，这样吞吐性能最好，若节点有的多，有的少，这就是呈现歪斜了，那么数据多的节点就会承载更大的数据拜访压力。
不同的数据节点有管理者进行治理，有的管理者是集中式任命的，例如 HDFS 的 namenode，有的管理者是被推举的，例如 Elasticsearch master node。总之分布式数据库就有治理节点负责调度数据节点，也有数据节点服务数据读写。就是这么一回事儿。
上图就是两种不同的数据管理形式，第一个是主从模型，例如 HDFS 的分块，由 namenode 对立负责数据块节点的调配调度；第二个是对等模型，例如 GlusterFS，也就是每个节点即是主又是从，要害看本人节点的数据是否匹配申请。
咱们再看看分布式事务的架构有如许简单，就看看 TIDB 的架构吧！
上图是 TIDB 作为一个整体存在，作为玩分布式数据库的专家看了这个架构都会头大。
TIDB 作为面向客户端的 SQL 申请和逻辑解决者，PD 是集群的管理者，TiKV 又通过 key/value 的模式长久化数据，TIDB、PD、TiKV，各自又是分布式集群，那么事务的发动、数据路由由 PD 负责，SQL 的接管、事务过程的管制由 TiDB 负责，数据的落地由 TiKV 负责。通过这么一个责任分工明确的体系，就造成了真正的分布式事务。
其长处就是事务加锁终于去中心化了，达到了分布式数据库技术航行最远的中央了，这可是谷歌的 Percolator 论文在 2011 年就发表了，谷歌真的是神族所在地。
可付出的代价仍然不小，第一个很显著，物理机器少不了，然而能到了这份上的业务也不在乎这么多资源了。第二就是 TiDB 的事务过程管制是在内存中进行的，等事务一致性同步好了，才会进入 TiKV 长久化，因而内存的耗费肯定不得了，遇到延时类 bug，内存就有可能因为数据洪水决堤，最初的问题还是网络交互太频繁了，保障一个良好的网络环境极为重要。
好，就聊这么多吧，心愿本文的一些浅见使咱们对分布式系统有一些更粗浅的了解，一句话：分布式系统太简单了，你很难去管制它，须要的是深刻去了解它。
[url]https://www.iqiyi.com/paopao/…[/url]