一种屏蔽复杂业务逻辑的数据转换获取方案

孙宏良  2019年8月9日

【问题背景】

        基于复杂业务场景，尤其是微服务架构下的复杂业务场景。我们将业务拆分、解藕，将服务能力拆分复用，从而尽可能隔离复杂服务间的相互影响。

        当服务链条长，依赖复杂的时候，每个业务服务只关心自己的业务逻辑，但是如何去获取关联服务的数据却成了比较头疼的问题。

        考虑一下这样的业务场景：客服系统接入用户后，如何获取散落在各个系统的数据从而支持客服回答用户的问题呢？

        说真的，图中示意的系统和数据与真实情况下相比简直是九牛一毛。这是要客服的rd把每个服务的接口都调一遍吗？简直是在虐待我们可怜的rd同学～ 就算不用把每一个服务都调一遍，部分服务可以由相关的服务包装起来，但是包装的服务怎么知道你要不要被包装服务的数据呢？如果不关心你要什么数据，那么它相关联的N多系统真的都要调用一遍吗？如果不包装，那些间接的关系，客服的rd又如何能知道这么多复杂系统的相互关系呢？

        痛点问题：能不能在不关心复杂业务逻辑的情况下，通过一个主键Id获取到其他所需要的数据？

        之前在我们的项目中，广泛使用了“宽表”的方案，该方案只需要有一个服务关心整体的业务逻辑，通过监听Binlog、业务消息等推送发现数据变化，获取并按照业务逻辑组装数据，写到一个大宽表中。宽表的载体我们不做讨论。这种方案能够将数据获取的复杂性屏蔽在自己的服务内，并且支持筛选、分页查询等数据表天然支持的特性。真乃苦了一个人幸福千万家的好设计～

        但这种设计我却不敢苟同～优势明显，缺点也不太容易接受。为啥要苦一个人啊？这个同步来数据的实时性怎么样啊？一个表动不动就有上百列啊有木有？最不能接受的是，所有业务系统的底表变化、数据逻辑变化都会直接引起这个服务的崩溃啊！！谁会想着告诉你我们的业务变了呢？

【方案概述】

        构建有向加权图，数据类型当作顶点，数据的转换方式当做路径。通过计算顶点间的最短路径，就可以得到获取目标数据所需要的调用。

        我们将可以将上面的示意图生成如下图所示：图数据结构

        其中，圆代表数据顶点，箭头代表某种转换，可以使用根部数据获取头部数据，相同颜色的箭头为同一转换。由于一个转换可以一次性转换出多个数据，因此我们简单画一条箭头到所属的业务服务上。图中我们假设，“订单号”可以转换到用户信息和订单Id；而订单号除了获取用户信息外，还可以获取到提供商品的仓库、商品、物流等信息；而要获取供应商信息，就不得不通过商品获取了。

        通过订单Id获取全部数据的路径是什么？ 黄（用户信息、商品信息、物流）、绿（供货商）、红（供货仓库）

        通过订单号获取全部数据的路径是什么？蓝（订单Id，用户信息）、黄（商品信息、物流）、绿（供货商）、红（仓库）

        我们只需要将有哪些顶点写入配置、将有哪些转换写入配置，接可以得到这张转换图。而我们不关心从一个顶点到一个目标订单到底要怎么转换，交给最短路径的算法即可。

        当然，上述模型表述较为简单，

【优势】

1. 业务服务只需要提供自己紧密关联的数据转换方式即可，方式的形式不限，可以使用策略模式支持不同方式；
2. 数据使用方只需要关心自己当前的数据以及想要得到的数据，无需关心数据的转换过程；
3. 业务服务直接提供数据接口时，数据一致性极高；
4. 业务服务无需分别做数据转换的工作；
5. 对业务变化有一定的适应能力；
6. 存在多条路径时，能够找到最优的路径（实效、可靠性等）

【劣势】

1. 串联调用，获取时常由接口调用总时长决定，可能较慢；
2. 串联调用，路径服务损坏将造成整体的不可用；
3. 所有数据顶点唯一，不可以重名；
4. 不支持任意数据的筛选、查询；

【改进】

1. 可以通过重试机制解决串联路径中，单个服务不稳定的问题；
2. 可以通过备份存储的方式，存储返回结果，对窗帘路径中单个服务当机降级；
3. 结合宽表的能力优势，宽表拼装数据时可以使用本方案，将两种能力进行结合解决筛选查询的问题；

 

——————————————————————————————————————————————————

作者介绍：

        我是来自 车好多集团-毛豆新车 的一名毛豆粒，负责供应链履约中台的架构设计。在我看来，新车业务商品价值高、管理复杂，流程多、系统也多。如何构建一套高可用、低耦合、可快速迭代且能适应业务飞速发展的技术架构是我内心的追求。

        希望有更多的机会与更多的技术伙伴一起交流成长，大家互相分享，同步提高。

        也希望看到文章的朋友，对我们的团队感兴趣、加入我们。

内推邮箱：sunhongliang@guazi.com  邮件标题请包含“内推申请”字样