用一个实例项目重新认识分布式系统

前言

对于分布式系统的理解不能光停留在理论上，本文旨在通过一个实际的案例来阐述分布式系统框架的基本概念，起到抛砖引玉的效果。

背景

• 第一次提到分布式系统，应该还是十几年前，当时的互联网还没有这么火热，相关的技术也没有如今这样成熟。
• 那是一个涉及银行安全系统的集成项目，项目的需求主要是对企业用户的票据加密与支付核验服务，项目的难点在于：1、安全服务系统做为一个独立的子系统 ，需要跟银行现有支付后台业务系统进行完美对接；2、系统集成后整个业务处理过程不会影响原有业务系统的性能。

• 当时的系统架构是这样的：

  
  在这里插入图片描述

单机系统的弊病

• 我们暂且不说银行业务系统后台那庞大的小型机集群，只看项目集成的这套系统：这是一个典型的单机系统架构，该系统只做为一个中间系统嵌入原有银行系统框架中，系统使用C语言编程，与客户端及接口通信均采用底层Socket通信。

1. 客户端组织报文将信息提交给支付密码系统；
2. 支付密码系统进行密码核验，得出核验结果，并将核验日志保存到数据库中，保存完成后将核验结果与用户报文转交给银行业务接口；
3. 银行业务接口进行校验，若核验结果错误，则返回客户端核验错误信息；若核验成功，则交由后台系统继续业务处理过程。
4. 银行业务后台系统处理完毕，返回最终结果。

在这里插入图片描述

• 由于前期业务逻辑设计的不合理，支付密码系统被错误地架在了客户端与银行支付后台业务的中间；没有管理功能，后台管理只能通过配置文件进行。
• 另外单机版的系统架构，远远达不到高可靠高性能的要求，系统一旦宕机，银行系统企业票据远程支付业务就处于瘫痪状态。

1. 应用服务与数据库未分离，导致单机负载高；
2. 应用服务只能单机多进程运算不支持并发，更没有负载均衡处理，导致业务堵塞。
3. 交易业务存储依赖于关系型数据库，且没有缓存处理技术，数据库读写压力大。
4. 底层通讯以BIO方式进行，通讯效率低下。
5. 日志处理不支持异步处理模式，抢占系统资源。
6. ...

在这里插入图片描述

• 当然，这个项目还是上线了，付出的代价是把系统的服务器进行了高配的升级，并加入了EMC的存储，通过双机热备的方式来保证系统的高可用性；其次银行在业务端也做了限制，每个银行网点只允许一台终端有权限能处理该业务....

  
  在这里插入图片描述

尝试分布式改造

• 假设一下，如果我们通过现在成熟的中间件及框架对该系统进行分布式改造，应该怎么做？
• 我觉得应该主要解决以下两个问题：

1. 业务逻辑的合理性：业务功能分层并梳理出合理的业务逻辑是首要任务，（微服务拆分、中台化管理其实说的也是这个道理）

2. 引入合适的分布式框架或中间件，解决一切单点的问题：比如分布式RPC框架、异步消息日志系统、负载均衡机制等

   
   在这里插入图片描述

为什么要分布式

• 分布式架构与传统的单机架构最大的区别在于分布式架构能解决两个方向的扩展问题：一是横向扩展，二是纵向扩展；

1. 横向扩展：主要解决的是容量的扩展问题，不管单台服务器的性能多高，支撑的能力总是有上限的，所以我们在架构上必须能做到支持横向扩容，即理论上随着请求的无限增长，系统的容量也是具备无限增长的能力。比如：上述案例中交易系统的RPC接口与管理系统中的API接口都具备容量横向扩展的能力。
2. 纵向扩展：主要解决的是业务的扩展问题。当业务扩展时，业务逻辑的复杂度也会不断上升，所以在架构上需要根据功能定义进行纵向层次的划分，且该功能层次划分能符合业务快速迭代的要求。比如：上述案例中将系统功能纵向划分为3次层次，RPC接口定义为与银行交易系统交互的业务功能层次，API接口定义为与外部查询与审计系统交互的业务功能层次，管理应用定义为后台管理功能层次。

• 用一句话来概括：分布式系统目的就是能利用更多的机器，处理更多的业务与数据。

  
  在这里插入图片描述

分布式系统特性

• 看了上面的案例，我们首先厘清了这样一个概念：分布式系统不是一个专门面对互联网的架构（虽然目前绝多大数的互联网应用系统都是分布式甚至是微服务架构），那分布式架构的主要特性有哪些呢？

1. 透明性：用户根本不会感知到这是一个分布式系统，对于用户来说从请求到最终业务完成，是一个黑匣子。
2. 可扩展性：分布式系统具备横向容量扩展、纵向业务扩展的能力。
3. 高性能：单位时间内处理的任务越多越好，每个任务步骤处理的平均时间越少越好。
4. 可用性：一般来说，分布式系统是需要长时间甚至7*24小时提供服务的，系统可用性需要达到99.999% 。

分布式系统的最大问题

分布式系统的最大问题，我们必须要深刻理解和牢记一点：分布式系统是不可靠的。 分布式系统中重要的理论和设计都是建立在分布式系统不可靠这一基础上的，因为系统不可靠，所以我们需要增加一些额外的复杂设计和功能，来确保由于分布式系统的不可靠导致系统不可用性的概率降到最低。

分布式系统一般会引入冗余机制，在任务执行序列中不管是主节点还是冗余节点，都需要达到一致的状态。比如：在上述案例中，交易系统调用核验接口，如何保证所有核验的节点的状态一致性需要用到中间件进行解决。

写在最后

• 前段时间读了许多关于“分布式系统”的书及文章，有基础理论的，有技术发展趋势的，有实际案例解析的...，为了让自己带着思考，真正去了解这个概念，于是动手写了这篇文章。
• 分布式系统解决问题的思路是早就有的，分布式系统也不仅局限于互联网行业的应用，我们把这个思想掌握了，研究透了，在遇到实际项目时才能从架构师的角度去解决问题。
• 很多Java程序员在初入学习分布式框架时，往往只对各种中间件进行生搬硬套，但真正掌握好计算机基础知识，如操作系统、计算机网络，对学习分布式系统是大有益处的。