【JS】技术方案设计的方法论及案例分享

• Z时代
• 2024-01-10
• 分类：技术分享

简介： 怎么去体现技术方案设计的深度是大家普遍关心的一个问题，这个问题不是个例问题，因此本文主要分享下作者个人的一些观点和看法。

技术方案体现广度和深度

1. 方案设计常见的反馈

我们都希望自己设计的技术方案能够让人眼前一亮、叹为观止、拍案叫绝……，然而在实际情况下，却并不是这样的，我们经常听到如下的说法：

• 场景简单：业务场景很简单，怎么也设计不出花儿来。
• 复杂度低：业务复杂度低，很难讲得出挑战来。
• 亮点少：运用的技术亮点少，基本上都是现有的中间件或框架来完成。
• 设计普通：方案缺乏新颖，业内也是这么做的，没有体现出自己的设计能力。
• ……

的确，上面反而是经常遇到的场景，那么需要思考下背后的问题和原因，为什么会有这样的感受，如果这个事情交给另外一个人去做，为什么他能设计出更好的方法，而当时你却没有想到呢？

2. 原因探究

个人觉得这个问题最为核心的一点是就事论事，因为只是看到这个事，需要完成某个具体的功能点，而没有跳去这个事情的表象，去思考到底要什么、解决了什么问题、价值是什么，这样思考很有可能你现在的解决方案只是其中一个很小的点，没有站在全局去思考问题。曾经我的老师讲过一个观点：把手掌放在眼前，你只能看到这个手掌，如果把手掌放在远处，你的视野就更广了。因此视野更关键，不要只关注事情的本身，可以跳出来看看，或者你能想到的更多。

就事论事只是一个表象，背后还是深层次的原因，个人觉得是缺乏体系化的思考，"只见树木、不见森林"，没有从不同的维度上去思考问题，只是线性的思考，直接的表现就是【就事论事】，只把手头上的事情完成即可。讲体系化思考的书籍很多，大家有兴趣可以去了解下，帮助自己更好地思考问题。

到这里其实还没有结束，还有一个重要的原因是缺乏方法论引导，就是没有形成自己的一套方法去思考问题、解决问题，不同的人会有自己的方法，有了方法论的引导，拿到一个问题，知道怎么去分析、思考、解决，远比只是被动地接受一种具体的方案要好，下次场景变了，很有可能现有的方案是不能支撑的，因此需要建立一套适合自己的方法论，具体在第二部分会分享自己的方法论。

3. 技术广度和深度

广度和深度对于我们来讲并不陌生，大家都知道要体现出广度和深度，却不知道怎么去做。广度觉得从数量和类型两个维度去分析（应该还有其它的维度，大家可以自行补充），是让事物更加地丰富，比如动物园里有不同的动物，种类比较多，就能更加满足不同人的观赏需求；深度主要体现出问题的识别和创新解决上，一个问题大家没有发现，而你从中发现了，这就是深度，比如网上购物，站在今天来看，再平常不过了，但在 20 年前，并不是每个人能想到的。现如今，同样是做电商，每个公司的打法、策略是不一样的，这就体现在深度上，深耕于某一个领域。

这里拿自己的经历来说明：之前本人在滴滴是做优惠券业务（当时营销比较简单，就是单一券业务），优惠券只是一种营销的具体手段，行业内有卡、券、分、金，那么对于技术来讲就是丰富营销基础能力，从单一券能力发展至卡、券、分、金的营销行业标配能力，这个就体现了广度，从数量、类型上丰富了。而怎么体现深度呢？营销中有一个重要问题是如何防控资损，一旦有资损，问题就比较大，因此需要去好好思考和设计方案，当时借鉴稳定性方案，分成事前、事中、事后三个阶段去防控资损，每一个阶段里又包含了不同的方案，深度主要体现对问题的识别，以及怎样创新地去解决，重点是创新，做到人无我有、人有我优。

4. 怎样证明技术方案是好的

大家在和别人分享、交流技术方案时，有人会提出一些尖锐的问题，比如：为什么说你的技术方案是好的？其实这个问题非常好，值得大家去思考。

有一个很常见的情况，大家去讲一个技术方案时，把背景、目标讲完之后，直接给出了技术方案，其实技术方案本身并不重要，重要的是你是怎么思考的，思考的过程非常重要，强调的是 WHY，HOW 很重要，但 WHY 更重要。这里有两个原则：

• 三段论：大提前、小提前、结论。一定要先讲大提前，它是一个有力的支撑，比如写议论文时，平时常写"鲁迅说过 xxxxx"，这个就是大提前；在技术方案设计上，就是要看业内的方案、业界的标杆在哪里，和它有什么不一样、创新了什么，一目了然，往往大家忽略了这个大提前，直接讲自己的方案，怎么证明你的就是好的呢？没有对比就没有感觉。

• 环境论：有时业内还没有具体的方案，或者是当下你的公司不适合业内顶配的方案，比如"中国特色社会主义"，它就是强调当前的环境，结合了具体的业务场景来权衡考虑的，并不是行业内的最优方案就是适合你的，方案的设计一定要有权衡、选择，设计出最适合当前环境的方案。

技术方案设计的方法论

1. 方法论到底是什么

经常有人讲方法论，方法论也让人感觉比较玄乎，感觉是一种虚无缥缈的东西，方法论在百科中的解释是：“方法论是关于人们认识世界、改造世界的方法的理论”，看了这个定义，大家还是不清楚它到底是什么，只知道它挺厉害的，但不知道方法论到底是什么、有哪些方法论、应该如何去运用方法论，所以这里谈下自己的理解。

个人对方法论的理解是方法论是让方法变成更方法的方法，方法论拆分成两个词方法和论。因此它首先是一种方法，方法是为了解决具体的问题，比如大家熟知的稳定性建设，全链路压测、异常监控等都是具体的方法，但这些方法都是一个个散的点，并不是最好的方法，方法论强调的是好的方法；然后再看"论"，论是议论、分析、思考的过程，它最大的好处是让方法更好，还是拿稳定性建设来讲，现在有成熟的方法论，分成事前、事中、事后三个阶段，事前包括容量评估、全链路压测、强弱依赖……，这样讲就比较成体系，将它划分成事前、事中、事后，覆盖了整个过程，你基本上挑不出什么毛病出来。因此方法论是对解决方法进一步的升华和提炼，形成更通用、成体系的方法，它并不是虚无缥缈的东西。

方法论是通过不完全归纳法总结出来的，方法论并不是万能的，比如你看到的天鹅都是白色的，万一哪天出现了一只黑天鹅，就说明当时的归纳是不完全归纳的。

2. 技术方案设计方法论

下面所说的方法论都是存在的，自己只是组合运用了这些方法论而已，下面总结下自己工作中使用的一些受益比较大的方法论。

本质论是我第一个受益的方法论，本质论强调的是透过现象看本质，这句话听起来是比较简单的，但要做到却是非常难的。看透本质至关重要，能让你真正把控事物的核心，我个人的一个方法是使用不超过 15 个字概括出事物的本质，因为本质的东西是简单的、美的、直揭主旨的，所以判断是否抓住了事物本质的一个标准就是用简单的话能否概括出事物的主旨。比如高并发，现在不再是一个新鲜的词汇，甚至大学生都知道怎么去做，缓存、异步操作、并行……，这些都是具体的措施，问高并发到底是什么，大家都能回答一些，比如流量大、系统压力大、用户多……，这些都是具体的特征，用一句话概括高并发：有限的资源应对大量的请求，概括出了高并发的根本特性，抓住了本质的东西就比较解决问题。带应届生的时候，我提到一个观点：工作三年以后，要能说得出 10 句对技术本质理解的话，提早给自己定下目标，在平时中积累一些思考和沉淀。

矛盾论揭示的是事物之间的矛盾，矛盾是推动事物不断发展的动力，一般从事物本质中，可以看到一些矛盾出来，比如上面高并发的本质是有限的资源应对大量的请求，有限对大量本身就是一对矛盾，找到了矛盾就去解决矛盾，解决的一个方向就是平衡矛盾，矛盾解决了，问题自然就解决了，比如现在资源是大量的，完全可以应对大量的请求，这样高并发的场景对于你来讲就不是一个问题。

系统论是从系统各个要素出发，多维度思考问题，最为简单的是从矛盾双方出发思考问题，比如有限的资源，能不能让资源的数量变多呢？能不能提升资源的处理能力呢？……，从这些方向去思考，思路就一下子打开了，所谓的缓存等常说的方法只是一个个具体的解决手段，我们需要更加立体、多维的解决思路，再结合具体的场景、现状组合一些解决方法。

演进论强调事物是进化的，符合事物的发展规律和人的认识，有可能我们想得非常完善，不可能等所有的事情都做好了再上线，得有计划、分阶段地解决问题，优先解决主要矛盾、核心诉求。也有可能经过一段时间之后，事物的主要矛盾发生了变化，我们的方案也得演进式设计。

技术方案设计案例

下面拿三个具体的案例来讲怎么将方法论落地于实际的技术方案设计，让大家能够感觉到方法论的真正作用，不再是一种虚的感觉。

1. 高并发技术方案

高并发在之前是非常火的，大家也都能说出一些解决措施，如使用缓存、MQ、并行……，下面谈下自己的一些思路。

问题定义：高并发的本质是有限的资源应对大量的请求，它的核心问题就是现状不足已支撑那么大量的请求，系统的负载太高，很可能出现网站打不开、用户下不了单等现象。

问题分析：高并发的矛盾就是有限的资源对大量的请求，解决了这个矛盾就解决了高并发的问题。接下来就是平衡这对矛盾，一般是采用"中和"的思想，就像中医治病：寒病用热药、热病用寒药，因此就会站在资源和请求两个维度去思考。资源能不能变多：常见的有水平扩展；资源能不能变强：常见的是性能优化，性能优化又会分成前端优化、网络优化、计算优化、存储优化、程序优化……。请求能不能减少呢？比如通过答题错峰，合并请求等等，这样解决问题的思路就一下打开了。

解决方案是重要的，但设计的过程更为重要，清楚了问题是什么、怎么去分析，解决方案自然而然就出来了，重要的还是分析的过程。

2. 异步处理技术方案

说到异步处理，大家最容易想到的方案就是 MQ。MQ 是常见解决的技术方案，如下图所示：贷款端系统向放款端系统发送标的信息，一天的量大约有 4000 多笔，每天偶尔有几个是超时的，影响放款。怎么去解决这个问题呢？用 MQ 是最容易想到的，当时公司还不有用到 MQ 中间件，去搭建一个不现实，怎么办呢。

问题定义：现有的系统能力无法支撑实时处理，同步调用对系统的压力很大，很有可能某个时间点系统的负载比较大，处理慢了接口调用就超时了。

问题分析：借鉴 MQ 的设计原理，发送方将消息先发送至 Broker 上，消费方从 Broker 上拉取消息消费，抽象出异步处理的本质就是数据暂存 + 择机处理，那么问题来了，数据暂存在哪里呢，内存？文件？数据库？……，择机处理的方式是拉还是推，定时还是随机……，这样一思考，发现除了 MQ 还有很多其它的解决方法，总结出通用的解决方案后，可以在不同具体的环境中演绎出不同的方案。当时设计的方案就是将数据存储到 ftp 服务器上，实现也比较简单，方案没有最好，只有适不适合，难道公司没有 MQ 中间件，这个事情就不能解决了吗？

3. 可扩展性技术方案

可扩展性设计是现在一个非常典型的场景，当时遇到的场景是实时人群计算场景，每当业务方提一个需求过来，就要进行对数据口径，然后熟悉业务方的一些业务，接下来就是编写 Flink 任务，测试、核对，最后上线，整个流程下来至少 2 周，需求提一个简单需求，很疑惑为什么要 2 周才能上线。

问题定义：业务方希望快速上线而实际开发要 2 周的矛盾，究其主要原因是不懂业务，需要有熟悉的阶段，这个阶段耗时比较多，真正开发的时间不多，怎么去解决这个问题呢？

问题分析：虽然主要的矛盾找到了，很明显的一个方向是让业务方的开发参与进来，平台只做一些支撑、答疑的作用，但是让业务方的同学进来，就有一个挑战：别人没有学过 Flink，你让他来开发，业务方愿意吗？对整个业务进一步的抽象，发现我们的需求场景是变化的，实时指标也是变化的，但整个流程却是不变的，用 y = f(x) 来表示，就是来一个 x 经过计算、变换成结果 y，所以当时就梳理出了哪些是变化的、哪些是不变的，从多变中找不变的东西。这里还需要一种能力是抽象分层，如果把 f() 只当作一层，就只有一个抽象分层，如果里面它还有复合函数，那么就有多个抽象层，这取决于对问题的思考，不同的人设计出的抽象层次是不一样的。当时借鉴了 Flink 的一些设计思想，将整个过程产品化了，业务方只要选择、勾选一些信息，就会自动生成 Flink SQL，然后点击运行即可。SQL 对于大家来讲，入门比较简单，基本上能看得懂，没太大的难度。平台侧不需要像之前那样完全投入人力去学习业务知识、开发、测试上线。

总结

本要分享了技术方案设计的一些思路，整个方法论包括本质论、矛盾论、系统论、演进论，通过三个具体的案例阐述怎么去运用方法论。

作者：高福来（不拔）
原文链接
本文为阿里云原创内容，未经允许不得转载

以上是 【JS】技术方案设计的方法论及案例分享 的全部内容， 来源链接： utcz.com/a/112453.html