如何 5 分钟做出高明的架构决策

作为一名 IT 从业人员，我们从来不缺需求的慰藉。在与形形色色的需求过招中，我们的思维、眼界和经验也得到了了充分的锻造。需求就是我们的磨刀石。

那么，当一份需求摆在我们面前的时候，我们如何去评估这份需求的合理性呢？如果需求是合理的，那么我们又该如何去设计它，实现它，并达到综合最优的效果呢？

很多时候，即使是从业多年的技术人员，初次面对一份需求，我们大概率是迷茫的，对于需求的方方面面难以给出一份透彻的、全面的评估意见。

01 理论导入

那么有没有一套行之有效的思考框架，可以指引我们有条理的进行分析呢？下面就给大家介绍一下笔者自己的经验。

首先，面对一份全新的需求，我们需要利用超级思维，从宏观的业务战略出发，避免窄巷思维。任何一个产品在设计之初，都有自己的定位和策略，我们称之为业务战略。所以，理论上任何需求都需要服从本产品的业务战略，如果不符合，只要产品的业务战略仍然有效，这样的需求肯定是要被驳回的。

其次，在满足业务战略的大前提下，需要考虑需求的技术方案。同理的，任何技术方案也是需要从顶层架构出发，并遵从之。

其次，谋篇布局。需要思考在当前的人力资源、在途需求等约束条件下，用哪种方式可以最快成本最低且未来友好的方式来实现它。

其次，需要前瞻性的进行风险识别。提前甄别出本需求和技术方案影藏的风险点，并制定相应的应对措施。

其次，不得忽略组织和协作的因素。任何需求和方案最终需要人去落地，人却是比较复杂的因素，尤其是组织中的人。没有组织的保障，要想顺畅的实现一个需求和落地一个方案，往往会发出“理想很丰满，现实很骨感”的无力感。

最后，需要对未来发展趋势和客观规律的洞察。这里面的趋势包括产品发展方向、团队结构。

02 案例分析

当然，仅凭上述文字描述，大家八成还是不知该如何运用。下面以笔者所在公司的实际案例进行阐述。

笔者所在公司是一家面向灵活就业人群发佣报税服务商。原有成熟产品 A，公司客户可以通过 A 提供的能力，自由进行发佣报税。因为公司在本赛道精耕细作数年，对本赛道的市场、运营有着较丰富和前沿的经验，加上公司有着深厚的技术积累，因此，决定将这些影藏的能力进行产品化，以赋能同行中小型友商，助力他们的系统化、科技化和运营正规化。于是推出了新产品 B。B 是一款全新的行业 SaaS 产品，本公司作为技术服务提供商，提供 SaaS 系统的开发和运维，友商可以订购该产品，实现与本公司 A 产品类似的运营能力。

无论是 A 还是 B 产品，都有一个需求，每一个银行对公账户都有每日转账金额限制，且不同的银行对不同的账户限额数值不一样，是分别申请的，且银行需要根据现行业务规模审批。如果某一天某个银行账号发放金额较多，一旦超过限额，当天所有转账交易全部失败，直至第二天自动恢复。

A 和 B 产品中，理论上 B 产品上的对公账户都是入驻 B 系统的友商的（我们称之为服务商），但是在运营过程中，存在少数我司对公账户同时在 A 和 B 使用的场景。产品提出一个需求，对每个对公账户每日转账金额进行实施记录，一旦接近某账户预设的限额，就发出告警，让运营人员提前感知并介入。A 产品的技术人员提出一个方案，即无论是 A 还是 B 系统，每完成一次转账，即向 A 系统中的一个 S 模块上报一次数据，由 A 系统的 S 模块统一管理。

那么，该需求和技术方案是否合理呢？

我们套用上面的思考框架。

从业务战略层面出发，B 产品设计之初是为同行而服务的，因此跟 A 产品数据隔离是必须的，而且不同系统用户体系、数据体系肯定也是隔离的。从这一点出发，产品设计的在 A 系统统一收集 A/B 系统对公账号的转账汇总数据，不符合数据隔离的要求，用户体系和数据体系上也无法实现。所以本需求是可以驳回的。

那么，假设产品修改需求，遵从 B 系统的业务战略，分别在 A/B 的管理端去维护和管理限额数据呢？毫无疑问第一条约束是已经满足了。那么需要考虑从顶层架构设计出发，A/B 的应用架构如何设计？首先，如果该功能强耦合做在 A 系统中，那么也是不可取的。因此 A/B 系统的发展轨迹完全不同，这样强耦合的设计会导致双方紧密捆绑。其次，如果该功能独立成一个服务，大家共用是不是一个好的方案呢？虽然比上一个方案好，但是涉及到安全认证、研发步骤协调等问题，会增加系统的复杂度，同时项目进度制约因素增加，尤其是后面的迭代需要同时考虑兼容 A/B 的不同需求和节奏。最好的方式是各自独立。

接下来从谋篇布局的层面来考虑。上面已经确定该功能在 A/B 系统分别独立实现。那么是不是 A/B 都需要独立开发一遍呢？并不是。实际情况是 A 对该需求的紧迫性和强烈性都高很多，同时 B 的研发团队目前正在处理其他需求，无暇分身，那么完全可以 A 先实现，之后 B 直接复制并适配性改造，既可以实现最低成本的首次开发成本，又不妨碍大家后续各自的独立演进。

风险识别角度来看，按照上述设计，风险相对可控。如果采用其他方案，后续 A 需求变更，或者 B 有其他需求，都需要协调，如果忽略了其他一方对本功能的依赖，可能导致另一方功能异常。

我们调整坐姿，目标投向组织和协调。如果是复用的方案，那么研发进度需要协调，系统间调用的技术方案需要协调，后续的版本升级也需要协调，协调成本大大增加了。

最后，从趋势和规律洞察来看。现阶段虽然有少数对公账户存在复用的场景，但是长期来看，这只是特殊案例，因此没必要把 A 和 B 的数据融合在一起去解决当前的非常态情况。况且复用问题完全可以通过其他非技术手段来解决。譬如对于 A 系统，在设置阈值的时候，可以减去在 B 系统的转账金额间接实现（如 Z 账户日限额 1000W，原本设想的阈值设置是 900W，该账户在 B 系统最大发放额是 50W，那么实际设置阈值可以是 800W）。

一个行之有效的思考框架，如同一本旷世秘籍，拥有它，善用它，在与各式各样的方案对决中，往往能够凌厉狠决，直抵要害，无往而不利。