paypal外贸门户网站,二 建设电子商务网站的必要性,企业营销策划实训,工作站做网站1.背景
有了前两篇的帐号权限提取和功能设置提取的架构演进后#xff0c;有一个问题就紧接着诞生了#xff0c;对于诸多业务方来说#xff0c;关键数据源的迁移如何在各个产品落地#xff1f; 要知道这些数据都很关键#xff1a;
对于帐号#xff0c;获取不到帐号信息是…1.背景
有了前两篇的帐号权限提取和功能设置提取的架构演进后有一个问题就紧接着诞生了对于诸多业务方来说关键数据源的迁移如何在各个产品落地 要知道这些数据都很关键
对于帐号获取不到帐号信息是无法让用户约会和入会的对于权限用户有没有某个功能如海外加速直播、虚拟背景完全依赖于权限数据对于功能设置参会人入会是否要静音是否能开启视频则取决于用户的功能设置项
这么关键的数据又做了如此大的调整从业务方角度不得不考虑两个问题
如何降低各个业务服务的接入难度即使各个服务都费力的将代码接入一旦上线后发现问题如何快速补救
这是一个全局性的问题需要统一考虑否则之前看似合理的架构优化却可能因为对接时的实际困难而落不了地。
也就是这些非功能层面的问题却有可能让一个架构优化中途夭折我们需要从软件工程层面解决这些问题。
2. 思路
从业务对接的角度来看我们要解决两个典型问题
如何减少对接的工作量如何降低对接后的上线风险
这两个问题我们通过以下4步来解决。
2.1 代码调用归一化处理
当系统中各个业务层都直接访问DB时我们是很难作数据源调整的所以我们首先要作的是数据访问的归一化处理。简单讲就是把业务层对DB的访问收扰到一个公共库中包括两个层面
服务内部所有业务接口访问帐号设置类数据都通过公共库来访问系统层面所有服务访问帐号设置类数据都通过公共库来访问
如下图所示
在这个收拢的过程中我们主要做几件事
统一封装数据的访问接口各个业务都走相同的接口来访问数据统一数据格式例如所有业务访问帐号都返回同一套数据结构体数据源没有改变但各个服务由直接依赖DB改为依赖公共库
2.2 接入新数据源
作了代码调用的归一化处理后我们接入新数据源基本只需要改动公共库。具体工作为
抽象一套数据访问的接口让新数据源和老数据源都实现同一套接口从新数据源获取到数据后可能需要做下数据格式的转换让新、老数据源返回的数据格式统一
抽象接口定义类图如下所示
这套接口屏蔽了老数据源和新数据源的获取差异这样业务服务接入新数据源的工作量能降到最小。
2.3 快速回退支持
通过前面两步公共库已经提供了新、老两套数据访问接口业务方可能只需要一行代码改动做个选择即可。这里我们想讨论的一个问题是当接入新数据源上线后发现问题如何处理
第一种选择把版本回退回退到老数据源的版本这会带来其它修改如客户故障修复也被牵连回退第二种选择我们做一个配置开关通过修改配置快速回退到老版本其它修改都不受影响
不难发现第二种方式明显更稳妥配置简单示意如下
# AccountStore的实现版本选择
AccountStoreMode v2可能还需要在AccountStore的初始化代码中作一点改动来支持版本选择比较简单这里就不示例了。
2.4 降级处理
回退主要是解决已经出故障后如何快速恢复的问题也就是不论我们恢复多快至少已经有一部分用户受到了影响那是否有什么办法来避免故障发生呢
有我们可以做数据获取的降级处理做法也比较简单当从新数据源获取不到时可以尝试从老数据源再获取一次。
有同学可能有疑问降级会不会带来数据的正确性问题 确实有一定的概率用户的帐号权限已经在新数据源发生变更降级访问老数据获取到的还是旧数据如果用户正好要使用依赖此权限项的功能则有一定概率与用户预期不符。 但是问题在于当面临帐号都获取不到的产品可用性问题时个别功能是否符合预期这类局部问题还有那么重要吗而且还是一定概率。
这时候我们就要做权衡评估哪个问题带来的影响更小两害取其轻。 软件开发中往往很难有完美的方案有时候因为技术复杂度有时候因为成本这时候做权衡就很重要选一个我们能够掌控、团队有能力实施、结果有一点折扣但也能接受的方案往往更实用。 小结
本文以前面两篇文章账号权限提取和功能设置提取为背景介绍了当外部依赖发生变化时如何及时调整业务服务的结构设计。通过引入外部依赖防腐层来减化架构调整带来的对接工作量并降低对接新数据源的上线风险。
在软件设计中防腐层往往被描述为一个适配器用以将外部依赖和内部业务逻辑解耦。还是之前那个观点名称叫什么不重要重在能用它解决项目中的实际问题。
防腐层的适用范围远不止于此其实从长远角度考虑产品系统中很多模块都应该设计外部依赖防腐层像数据库、外部服务接口、消息队列、缓存等。这些看似稳定不变的基础设施却会在某天因为一个市场风向或客户需求而被公司要求果断的替换掉例如信创带来的技术国产化浪潮……
参考阅读
从帐号权限提取的视角来看架构演进从功能设置提取的视角来看架构演进
