拨云见日看什么是分布式系统？.docxVIP

拨云见日看什么是分布式系统？ 我觉得每个人脑子里一下子涌现出来的确定是格外具象的东西，就像下面这些： “分布式系统”等于 SOA、ESB、微服务这些东西吗？ 假如你一下子想到的是 XX 中心、XX 服务，意味着你把服务化的模式（SOA、ESB、微服务）和分布式系统错误地划上了等号。 那么，什么是“服务化”呢？服务化就像企业当中将相同岗位的人员划分到同一个部门管理，以此来收敛特定的工作入口，再进行二次安排，以提高人员利用率和劳动成果的复用度。服务化的本质是“分治”，而“分治”的前提是先要拆，然后才谈得上如何治。这时，高内聚、低耦合的思想在拆分过程中起到了一个格外重要的作用，由于这可以尽可能地降低拆分后不同组件间进行协作的简单度。所以重要的是“怎样拆“，还有如何循序渐进地拆，而这个过程中你到底是接受了何种服务化模式（比如 SOA、ESB、微服务等）并不是关键。 为什么说“怎样拆”最重要呢？我来举个例子，企业的组织架构包括三种模型：职能型、项目型、矩阵型。你可以把这里的企业理解为一个“分布式系统”，把后面的 3 种模型理解为这个分布式系统的 3 种外形。作为这个“系统”的全部人，你需要考虑如何拆分它，才能使得各功能组件相互之间可以更好地协作。假设，你要将一个总计 10000 名员工的企业按“职能型”拆分成 20 个部门，得到的结果是每个部门 500 人。 这时，假如工作是流水线式的上下游关系。一个部门完工了再交给下一个部门。 那么这时候是高内聚、低耦合的。由于一个工种只与另一个工种产生了关联，并且仅有一次。 但假如工作需要频繁的由不同职能的人员同时进行，会导致同一个部门可能与多个部门产生联系。 那么，这时是低内聚、高耦合的。由于一个工种需要和其他多个工种产生关联并且远不止一次。 可以看到服务化体现了“分治”的效果，这也是分布式系统的核心思想，因而从“分治”这个本质上来看，服务化的确是分布式系统，但分布式系统不只仅停留在那些服务化的模式上。 我信任，你在工作中参与开发的任何软件系统，处处都存在着需要拆分的地方，除非它的功能极简到只需要计算一个 1+1。比如，当我们在电商平台点击“提交订单”的时候，会涉及生成订单、扣除积分、扣除库存等等动作。电商系统初期全部的功能可能都在一个系统里面，那么这些操作可以写在一个方法体里吗？我想只需代码能够成功运转，大部分人是不会管你怎样写的。但是假如这时需要添加一个红包功能呢？信任你或多或少遇到过在几百上千行代码中去增改功能的事情，其中的苦痛应当深有体会。 要处理这个问题就是要做拆分，通过梳理、归类，将不同的紧密相关的部分收敛到一个独立的规律体中，这个规律体可以是函数、类以及命名空间，等等。所以，从这个角度来说“分治”的问题其实早就存在我们的工作中，就看我们能否有去关注它了。因而，这并不只是我们在进行服务化时才需要考虑的问题。 那么如何才能做好这个事情，更好的拆分力量正是我们需要把握的。假如只是由于看到其他人这么拆，我也这么拆，依据“二八准绳”，或许“依样画葫芦”可以达到 80% 的契合度，但是往往那剩下的 20% 会是耗费我们 80% 精力的“大麻烦”。要晓得，只要把握了核心宗旨，才能更快地找到最抱负的高内聚、低耦合方案。 “分布式系统”是各种两头件吗？ 又或许，听到分布式系统，你想到了某某 MQ 框架、某某 RPC 框架、某某 DAL 框架，把运用两头件和分布式系统错误地划上了等号。 这里需要搞清楚的是，两头件起到的是标准化的作用。两头件只是承载这些标准化想法的介质、工具，可以起到引导和约束的效果，以此起到大大降低系统简单度和协作成本的作用。我们来分别看一下： MQ 框架标准化了不同应用程序间非实时异步通信的方式。 RPC 框架标准化了不同应用程序间实时通讯的方式。 DAL（Data Access Layer，数据访问层）框架标准化了应用程序和数据库之间通讯的方式。 所以，虽然分布式系统中会运用两头件，但分布式系统却不只仅停留在用了什么两头件上。你需要清楚每一类两头件背后是对什么进行了标准化，它的目的是什么，带来了哪些副作用，等等。只要如此，你才能真正识别不同技术框架之间的区分，找到真正适合当前系统的技术框架。 那么标准是拍脑袋打算的吗？确定不是，正如前面所说每一次标准化都是有目的的，需要产生价值。比如，大部分两头件都具备这样一个价值： 为了在软件系统的迭代过程中，避开将精力过多地花费在某个子功能下众多差异不大的选项中。 在现实中，这点更多时候消灭在技术层面的两头件里，比如，数据库访问框架的作用是为了标准化操作不同数据库的差异，使得上层应用程序不用纠结于该怎样与 mysql 交互或者该怎样与 SQL SERVER 交互。由于与业务相比，技术层面“稳定”多了，所以做标准化更有价值，更能获得长期收益。但“