谈谈技术架构的设计方法

这篇文章我其实更想跟大家聊聊一些常用的思考方法，思考问题的方式对了，往往可以帮助大家少走弯路。,,技术常用思考方法,技术思考本质还是结构化思考，所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，为此我分为了技术架构设计的方法和技术 Leader 的思考方法两类。,0—>1,这个思考方法的含义是：,当我们在一堆迷茫和混乱中不知道如何下口时，应该先贴近问题本身，还原客观事实，并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大家围绕着这样的一个初始版本去叠加和丰富其他维度的内容，直到方案的共识。,我举一个实际的 CASE，大家在谈某平台能力升级的方案时候会经常喜欢用 PPT 画一些模块图，试图通过一些抽象的词汇来厘定清楚边界，核心概念。大家以为是在讲本质讲原则但实际所有人听了都是云里雾里，不知所云。因为通过概念去推导概念是无法真正回答问题的。,而比较好的应对方法我总结为以下三个步骤：,用户故事的串联，基于交互流程和真实的数据来描绘这件事在客观世界中用户视角看来是怎么发生的。这就是我们找准一个大家都能够共识的视角，让所有人快速把客观事实搞清楚画出来这个 1，而这个 1 就是后续讨论的靶子 。这个 1 的表现形式我认为往往都是很简单的，要么是交互时序图，要么是 Excel 表格，而不是复杂的模块概念图。,只是树立起来 1 这个初始版本，还远远不够。因为第一个步骤只是将模糊、混乱的东西通过一种方法信息化表达出来，这还远远达不到使用的程度。所以还需要将上述信息进行结构化的整合与提炼，因为信息只有经过结构化才能够变成有意义的知识，才能够与之前的经验形成互动，也才能够进行初版的设计加工。比如对数据流的处理，就会发现有哪些是可以合并的同类项，有哪些平衡校验逻辑等。,通过第二步的处理把 1 这个版本变得更加丰满，但是要形成完整的可实施方案还远远不够。我们还需要加入更多维度的校验和抽象，比如进一步抽象以看透其本质，比如加入重要异常，ROI，合理性等扩展性等多方的视角去做校验。,所以大家以后在遇到很多方案谈不清楚的时候，不要去听别人讲什么原则，概念，价值等等虚头巴脑的东西。把大家拉回来，回到最简单的最朴素的东西来对焦，那就是 一张交互序列图 或者 一张表格。越快速从一堆迷茫中快速提炼出这个 1 ，就越容易快速拿到结果。,1—>0,这个思考方法的含义是：,当我们在做一个方案时面临无数因素无法抓住关键点时，我们应该考虑删除法（把这个 1 拿掉不要行不行）去寻找决定性因素，以确保我们是真正的抓到了关键点。,我举一个实际的 CASE，每年都会做技术规划，相信这是很多架构师/Leader 很痛苦的事。痛苦的根源就是在脑子里面有无数需求，有无数的待优化点，也有无数的想法在萦绕，看到每个点觉得值得在新一年做攻坚。最终多半形成的就是一个表格，把今年要做的事罗列下，最多还排个优先级，好一点的换个形式变成 xmind 或者 PPT，再稍微好一点的可能会搭配上业务的目标和策略打法。但透过这些表面现象，其本质就是一个表格，没有抓住重点的表格。相信大家应该都看得蛮多的了。,如何应对这类问题我总结为一下几个技巧：,很多时候我们都在谈，要抓住事情的本质，要具备化繁为简的能力，其实就是在谈通过表面的结果去探究真实的原因。所以在看哪些是决定性因素时，大家不妨用因果法去检验：这个因素到底是深层次原因还是诱导的结果。,有时候各个因素之前并不是单纯的因果关系，而是依附关系，就像是树枝依附在树干上一样。而我们要找到决定性因素，可以尝试这个方法去检验：如果把这个因素去掉会不会影响全局，是不是导致结论不成立。通过这样多轮的分析，是可以绘制出来树干的与树枝的关系，这个树干就是要找的决定性因素。,有时候各个因素之间可能没有直接或者间接关系，或者这个关联关系太弱很难通过以上两个手段去确定关键点。可以尝试支点撬动的办法，即寻找可以激发这一堆要素的关键要素。我之前给团队举一个例子，国家抓经济肯定不可能是米面粮油各种琐碎地抓，肯定是找到几个关键点起到支点撬动的作用，如房地产行业。抓住这个就能够带动上下游产业，进而激发各行各业。,以上是目前实践下来的抓取关键点的一些方法。但这里一定也要注意一个粒度问题，千万不要走极端。比如一提关键点，就去思考本质，一提到本质就去找根因，一找根因就挖到人性，然后得出来就是人性的原罪问题。这种都是没有任何营养的做法，也不利于事情的推动解决。,1—>2,这个思考方法的含义是：,当我们思考一些抽象问题/方案时候，需要对问题进行拆分（一分为二），通过分而治之的方法来确定每个小问题的边界，通过对小问题的解决来降低全局的思考难度，以尽快形成解决方案。,这个应该不需要举例子了，大家日常都应该有所接触，这里只是列举几个比较典型的技术架构动作：,拆解是非常好的一个将问题分而治之的办法，但要注意的是要做有机的拆解而不是物理的分解。比较典型的案例就是关于故障指标这个课题的处理，我是见过有团队层层分解，把故障指标分解到每个同学身上，这是极其错误的做法，也不可能得到想要的结果。我们应该是要做拆解，就是把要守住故障指标这个结果拆解成哪几类关键动作，进而要求团队关键动作做到位，而不是强行分解指标。,做过实际研发的同学一定遇到一些业务需求的讨论，很多时候来来回回扯不清楚，而且经常会出现产品说这是技术架构问题，技术架构说这是业务需求问题，业务方说这是产品设计问题的现象。要解决这个僵局就需要把这个问题进行解剖，一层一层解剖清楚，把业务需求问题描述清楚，把产品设计搞清楚，把技术方案搞清楚。每一层都面向上游屏蔽下游的细节，才有可能把问题定义得清楚。一般来说，将这件事参与的角色进行解剖会更容易看得全面，更透彻。,以上是我实践对问题拆分的一些方法技巧，凡事多看几层终归是能够更加有结构性地认知事情本事，也越有利于问题的解决。,1—>N,这个思考方法的含义是：,当我们思考一些技术方案时候，不要仅局限在当时当刻的条件约束，要适当考虑系统的承载从 1 变到 N 的过程中的对系统架构带来的挑战。,做技术架构师的都知道做架构要求有前瞻性，不能被业务拖着走。但很多时候我们其实没有仔细思考如何才能够做到前瞻性，我总结为最关键的考虑的因素就是时间，把时间拉长来考虑关键生产资料可能发生什么变化，通过去架构这种变化所得出来的方案就具备了前瞻性。一般意义上来说，我们平台演进的生产资料抽象地归纳为三类：,针对这几个生产资料我抽取了几个技巧去思考如何从 1 扩张到 N：,从业务场景的变化情况来看，的确充满很多不确定性。也遇到过一种典型的业务与架构的死循环的情况：前端业务面临太多不确定性需要技术架构给予专业意见和评估，但是技术架构认为业务啥都想不清楚还要我评估这评估那，两边就开始互相死锁。,而比较好的做法就是架构能够基于自己的经验和业务变化的理解，将可能性进行罗列考虑，然后给出来基于 XX 业务假设下，系统架构需要 XX 量级的工作量做 XX 样的能力迭代升级，可以做到 XX 的业务效果和价值，但需要进一步 XX 的业务输入。这就是架构考虑所有的可能性的含义，是需要给予业务的选择。,但技术架构实施却未必是要留有太多的空白，架构要大但是实施要小，对于值得留白的地方做好扩展设计，对于实在看不清楚的地方就要明确拦截（宁愿不做也不错做），将可能性留足但也不瞎埋坑。,我常常去听一些故障复盘会议，在谈以后如何改进的时候很多同学都价值观爆棚，说以后XX类变更都加签上我来审核一道，我确认没问题再往后走。虽然这种精神值得鼓励但是这种做法实在是很不值得推荐，这样沉淀出来的平台其实是非常脆弱的，在做技术方案时一定要思考能够交给系统的绝对不能用流程，能够做到领域模型校验的千万不要靠旁路系统的侧面印证（如不必要场景下的核对）。,很多技术同学都希望做高并发大流量的系统，但很多时候在写代码的时候身体很诚实，怎么简单怎么来。实际做的时候既不考虑大流量也不考虑高并发，对于资损风险考虑也极其少，而且基本上都很有道理：现在的业务量没到不需要考虑那么多，这种事发生概率极其小一期先这样……要对技术架构做提前思考就必须从每行代码做起，提前考虑高并发大流量和严谨性。,通常来说大家其实都比较喜欢从 0 到 1 的过程，按照互联网的迭代式打法，后面的 1 到 N 的过程也会被不断压缩。所以提前在 0 到 1 的过程加入 1 到 N 的架构预判非常重要，因为很多时候结构性的问题在最开始就决定了，而且只有一次机会。,-1<—>1,这个思考方法的含义是：当我们思考一些技术方案时候，不要一条道走到黑，要前后、上下、左右、正反多个方面去思考，让技术方案具备更多维的视角。,我把常用的技巧总结如下：,日常也 review 了很多同学产出的架构方案和系分以及测分，大家对于正常业务需求功能的论述基本上都没有啥大问题，按部就班去写就可以。但普遍的问题都是对问题的反面论述不多，如支付正常流程浓墨重彩，退款/拒付等逆向流程就没那么细致，业务功能正常流转论述很饱满但是异常场景就寥寥几笔。但正面与反面结合起来才是完整的一体，而且对反面的思考其实是对正面的有益补充。而且通常来说，我们在正面出现的概率大于反面，但是反面出现差错的影响所需要付出的精力却远远大于正面。,在 review 技术架构方案风险相关的内容时，我都会特意问一下，如果出现 XX 问题最坏的业务影响是什么。为什么是问最坏的业务影响，是因为如果谈风险那肯定都是有一点点的，不利于大家去深究最关键的问题。通过极限设问，其实是激发大家去做最坏的打算，有了最终极的兜底手段才能够更乐观去做技术变更。,在 review 代码或者逻辑结构时，在深挖细节和关键点后，我时常会拔出来看看整体的逻辑结构是不是饱满，是不是对称，是不是美。最简单的例子就是写了 if 我一定要有 else，不然没对称结构就让我很不舒服。因为我相信对称的美就是一种生产力，因为美的东西一定是简洁且直达本质的。而我们写程序要的就是逻辑清晰简单直达业务本质，逻辑结构清晰的基本上没大问题，不清晰（如变量瞎命名，方法无语义）的深挖下去多半都能发现大问题。根源就是逻辑清晰代码才清晰，代码不清晰基本上就是逻辑混乱，逻辑混乱就会产生 BUG。,M*N —> M+N,这个思考方法的含义是：当我们思考技术问题时，可以尝试从系统耦合的角度去思考，尝试找一些突破口。,我举一个实际的 CASE，高速公路网的连接不是把所有目的地之间都修一条高速公路，而是会选择修建复用的高速公路主干道 + 分支道路的方式来组织这个网络。一条一条串联的方式就是耦合在一起的，这就是 M * N。通过主干道 + 分支道路的方式 就是解耦的，M + N 就能够组建这个高速网络。,在技术架构上如何运用解耦这个技法，我有如下几个提炼。,在业务和技术架构发展的前期，把很多东西糅杂在一起是最快解决问题的方法。但随着业务和平台架构的进一步演进，势必是要做解耦，目的就是重新去界定各个模块的边界，平衡新的业务发展要求下各方发展快慢的诉求差异，通过解耦互相松绑快速发展。,这种技法在服务化的分布式架构中非常常见，基本上跨域的平台架构升级都有解耦的影子。,解耦上下游关联性其实更多是在技术模型的抽象上，但在落入到技术模型范畴之前，还有就是我们在做更加抽象的解决方案探讨时要注意解耦各个角色之间的依赖。上述【架构考虑所有可能性但做有限明确实施】中提及的就是最好的案例。其实这里的本质表达就是，技术架构的设计应该要与商业选择，产品设计等解耦开来。,通过这一层的解耦其实能够多个角色之间基于 SLA 去交互，并且能够基于自身的专业思考给予对方更多的选项和可能性。很多时候的前瞻性和竞争力可能就是比别人多一个选择。,解耦思考法其实很有意思，几乎所有的大型平台架构升级都有这个思考法的影子，所以下次没啥思路的时候可以从这个角度做一个审视思考，说不定是有新的收获。,以上是我在做技术架构方案时沉淀总结的一些思考方法，这些思考方法不可能解决遇到的所有实际问题，只能算是一个思考提示，在遇到问题可以尝试从这几个方法去看看是否有灵感。基于方法论但是不局限于方法论才是方法论最大的意义和价值,作者简介：知明，蚂蚁金服国际事业群资深技术专家，全球资金平台技术负责人，负责了蚂蚁全球化进程中底层资金清结算、外汇等平台能力的搭建和迭代演进。