畅聊分布式体系架构

或许我们都忘了当年用短信和邮箱的时代，信息通讯并不是很及时迅捷。我们都普遍认为是那时候网络不够发达。的确这是一部分原因，但是其实另一部分的原因就在于集中式服务响应能力不足。这个应该怪英特尔和摩托罗拉（如果记得 68000，应该知道这个巨人）吗？我觉得不应该，至少当时他们已经很了不起了，将芯片带入了模块化的进程。究其原因就在于集中式本身瓶颈的限制。

打个简单的比方，你在大学食堂打饭和在快餐店点单，你会明显发现，食堂的效率远不及快餐店。注意他们的做法：

食堂流程是厨师接到订单后：

1. 准备配料；

2. 起锅加入调料；

3. 加入食材；

4. 爆炒几至十几分钟；

5. 取盘出锅；

6. 递送；

7. 循环第一步；

快餐店接到订单后：

1. 订单由报单人拆分；

2. 每组人负责一个菜式；

3. 每个人负责做菜的组成流程；

4. 最后由前台直接按菜单根据分类取菜装盘。

没错，仔细体会就很容易发现三点特征：（1）并行化；（2）模块化；（3）流水线。而这就是分布式体系架构的优势所在。接下来，我们来讲两个实际例子。

在 X 宝之前，任何普通人都应该最早接触到的转账交易系统是银行 ATM 等背后的一系列的对客交易系统。这些系统早期往往都是会将数据集中化的系统。多地的数据库资料最终都会同步到一台数据库服务器上。所以这就是为什么银行总在 5 点前关门，当时需要手工输入一遍当天的台账信息，而由中央集中对大额数据做一致性处理和校验的工作，然后用户需要等几天才能到帐。现如今早已不是这种模式，而我也没必要了解，毕竟今非昔比。而 X 宝交易的速度却出其的快？归结 java 语言完全没必要，银行系统早期还用 C/C++呢！他里面就运用了分布式体系架构。首先利用模块化开发功能性的微服务，将数据分布式存储在数据库集群中，并且按照多种类型情况保存冗余的版本数据。启用上百个微服务组群，通过 nginx 进行微服务的均衡负载，并且专人管理一组或多组服务或数据集。虽然这样会使系统异常雍肿庞大，但是却会在实际中却非常灵活高效，是不是很像会跳舞的大象？这样就可以根据每个自定义的模块来对异地的数据进行处理，而且由计算机系统负责数据流程间的校验和维护。这种模式只是分布式体系结构的一种企业模式，另外的可以参考 Mate(前 facebook)和 V 社如何活用 bittorrent 技术。

为什么科技圈大佬都喜欢用企业邮箱，而不是 IM 工具呢？性价比和安全性。金融上用分布式无可厚非，完全不必担心前期成本，他们会比较日后的收益和成效性，风险承受能力非常强。所以巴菲特和比尔能霸榜多年。而对于科技性企业来说，企业内部的员工体量一般没有上百万以上。分布式体系结构获取和分析大数据信息的能力简直是逆天的强大。用这种架构虽然对普通用户的便利性很高，但是对科技企业而言，如果针对性的定位分析数据，无疑是皇帝新衣，暴露无遗。所以大佬们都不愿意成为其他人的嫁衣。至于金融圈，彼得林奇曾提出过“预测经济完全是徒劳无益的，不要试图预测利率。艾伦·格林斯潘是美联储的头儿。他无法预测利率。他可以加息或降息，但是他无法告诉你 12 个月或者两年后利率将是多少。你无法预测股市。”

如果你是一个架构师，你在对分布式系统架构的评估时，必须权衡个中利弊关系，切莫盲目追逐性能或者成本。当然，我们所处的信息时代只是比之前的稍好，稍完善，但必须相信未来一定会有更好的系统架构来弥补如今的不足或者取而代之。

说句实话目前的系统架构体系太多太杂，虽然用分布式和模块化来缓和人数增长所造成交流冲突，达到人月增长趋于相对缓慢的增长。如人月神话所言，信息交流的成本往往会成为人月因人数增加的主要原因之一。但是对业务需求的过分追求，疯狂蚕食各个领域的利益来对冲信息系统的成本，这让我十分哗然。不应该过分追求信息系统如何十全十美，而是将复杂的事情做到简单，简单做到极致。正如 Tesla 和 Rivian 目前所努力的成果，不是也行之有效吗？而我正在尝试从极简主义的角度来重新定义软件。