为什么他能设计出更好的方法，而当时你却没有想到？

我们都希望自己设计的技术方案能够吸睛、惊艳、惊艳……然而，在实际情况中，并非如此。我们经常听到以下说法：

确实，上面是一个经常遇到的场景，所以你需要想想背后的问题和原因，为什么你会有这种感觉，如果这件事交给另一个人，他为什么能设计出更好的方法，但你当时没有想到？

2.原因

我个人觉得这个问题最重要的一点是关注这件事，因为我只看到这件事，需要完成一个具体的功能点，没有跳过这件事的表象，思考它是什么，要解决什么问题，有什么价值，这样想很有可能你现在的解决方案只是一个小点，没有从全局的角度去思考问题。我的老师曾经说过一个观点：如果你把手掌放在你的眼前，你只能看到这个手掌，如果你把手掌放在远处，你的视野会更宽。因此，愿景更为关键。不要只关注事物本身，你可以跳出来看看，也可以想更多。

讨论只是表象，背后有深层次的原因。个人认为是缺乏系统的思考。 “我只看到树，看不到森林。”这只是一个事实，你只需要完成手头的任务。有很多关于系统思考的书。如果您有兴趣，可以了解它们并帮助您更好地思考。

还没有结束。另一个重要原因是缺乏方法论指导，即没有办法去思考和解决问题。不同的人会有自己的方法，有方法论的指导。 ，发现一个问题并知道如何分析、思考和解决它比被动地接受一个特定的解决方案要好得多。下次场景发生变化时，很有可能现有方案无法支持。因此，有必要建立一套适合自己的方法论，并会在第二部分分享您的方法论。

3.技术广度和深度

广度和深度对我们来说并不陌生。我们都知道我们需要反映广度和深度，但我们不知道如何去做。广度觉得从数量和类型这两个维度去分析（应该还有其他的维度，你可以自己加），是为了让事情更加丰富。比如动物园里有不同的动物，种类更多，更能满足不同的人。深度主要体现问题的识别和创新的解决方案。一个没有人发现的问题，你却从中发现了，这就是深度，比如网购，在今天看来，这很正常，但在20年前，不是所有人都能想到的。现在也是电商业务，每个公司的打法和策略都不一样，体现在在某个领域的深度和深耕。

这里我用我自己的经验来说明：我之前在滴滴做优惠券业务（当时营销比较简单，就是单一优惠券业务），优惠券只是一种特定的营销手段，有就是卡、券，从技术上来说，就是丰富基础营销能力，从单一的优惠券能力到卡、券、积分、金营销行业的标准能力。这体现了广度，并且在数量和类型上都很丰富。以及如何体现深度？营销中的一个重要问题是如何预防和控制资金损失。一旦出现资金损失，问题就比较大了。因此，有必要仔细考虑并设计一个计划。当时，我们借鉴了稳定计划，将其分为事前、事中、事后三个阶段。控制资本损失包括每个阶段的不同解决方案。深度主要体现在问题的识别以及如何创新地解决问题。

4.如何证明技术方案是好的

当人们与他人分享和交流技术方案时，有些人会提出一些尖锐的问题，例如：为什么说你的技术方案好？其实这个问题很好，值得思考。

有一种很常见的情况。谈技术方案，说明背景和目标后，直接给出技术方案。其实，技术方案本身并不重要。重要的是你怎么想。思考的过程很重要，重点是WHY，HOW很重要，但WHY更重要。这里有两个原则：

技术方案设计方法

1.究竟什么是方法论

有些人经常讲方法论，而方法论也让人觉得更神秘，感觉像是一种虚幻的东西。百科全书对方法论的解释是：“方法论是关于人们理解世界和改变世界的方式的理论。”这个定义，大家还不知道它是什么，只知道它挺厉害的，但是不知道什么是方法论，有什么方法论，怎么用方法论，所以在这里说说自己的理解。

个人对方法论的理解是，方法论是一种使方法更有条理的方法。方法论分为两个词：方法和理论。所以，它首先是一种方法，方法是解决具体问题。比如大家熟知的稳定性构建、全链路压测、异常监控等都是具体的方法，但是这些方法都是一一分散的。这不是最好的方法。方法论强调好方法。然后看“开”。理论是一个讨论、分析和思考的过程。其最大的好处是使方法更好，或者以稳定性构造为例。现在有一套成熟的方法论，分为事前、事中、事后三个阶段，包括能力评估、全链路压测、强弱依赖……比较系统，分为事前、事中、事后。之后，覆盖整个过程，你基本上挑不出哪里不对劲。因此，方法论是对解决方案的进一步升华和提炼，形成一种更通用、更系统的方法，这不是虚幻的。

方法论是通过不完全归纳来总结的。方法论不是万能的。例如，你看到的所有天鹅都是白色的。如果某天出现了一只黑天鹅，那说明当时的感应是不完整的。归纳。

2.技术解决方案设计方法

下面提到的方法论都是存在的，我只是将这些方法论结合起来使用。下面总结了一些在我的工作中受益匪浅的方法。

本质主义是我受益的第一个方法论。本质主义强调通过现象看到本质。这句话听起来比较简单，但实现起来却非常困难。看透本质是非常重要的，这样你才能真正掌握事物的核心。我个人的一个方法是用不超过15个字来概括事物的本质，因为事物的本质是简单的、优美的、直截了当的，所以判断一个事物的本质是否被抓住的一个标准是不是可以用简单的语言来概括事情的要旨。例如，高并发不再是一个新词汇。连大学生都知道怎么做。缓存、异步操作、并行……这些都是具体的措施。如果你问什么是高并发，每个人都可以回答。比如流量大、系统压力大、用户多……这些都是具体的特征。高并发可以用一句话来概括：有限的资源响应大量的请求，总结高并发的根本特征设计方法论包括哪些分析，抓住本质。而不是解决问题。带新同学的时候，我提过一点：工作三年，如果你能说10个字就能明白科技的本质，提前给自己定下目标，在日常生活中积累一些思考和沉淀。

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

系统论从系统的每个要素出发，从多个维度思考问题。最简单的就是从冲突双方的角度考虑问题。例如，有限的资源可以增加资源的数量吗？资源处理能力能否提升？ …，从这些方向思考，想法立即打开。所谓缓存等常被提及的方法只是具体的解决方案。我们需要更多立体、多维度的解决方案，结合具体场景和现状。一些解决方法。

进化论强调事物是进化的，符合事物的发展规律和人们的认识。有可能我们有一个非常完美的想法，不可能等一切都搞定后才上线。必须有计划地分阶段解决。优先解决重大矛盾和核心诉求。也有可能经过一段时间后，事情的主要矛盾发生了变化，我们的计划不得不进化设计。

技术方案设计案例

我们以三个具体案例来说明如何将方法论应用到实际的技术方案设计中，让大家感受到方法论的真实作用，不再是一种虚假的感觉。

1.高并发技术解决方案

高并发之前很流行，大家可以说一些解决方案，比如使用缓存、MQ、并行……说说我们的一些想法。

问题定义：高并发的本质是有限的资源来处理大量的请求。它的核心问题是现状不足以支撑如此大量的请求，系统负载过高。很有可能网站打不开，用户也下载不了。单一现象。

问题分析：高并发的矛盾在于有限的资源发出大量的请求。解决这个矛盾就解决了高并发的问题。下一步是平衡这些矛盾。一般采用“中和”的思路，就像中医一样：感冒病用热药，热病用感冒药。因此，我们会从资源和请求两个维度来思考。是否可以增加资源：横向扩展常见；资源可以加强：性能优化很常见，性能优化可以分为前端优化、网络优化、计算优化、存储优化、程序优化……。请求可以减少吗？比如通过答错题、合并请求等，一下子打开解决问题的思路。

解决方案很重要，但设计过程更重要。一旦你知道问题是什么以及如何分析它，解决方案就会自然而然地出来。最重要的是分析过程。

2.异步处理技​​术

说到异步处理，大家想到的最简单的解决方案就是MQ了。 MQ是一种常见的技术方案，如下图所示： 贷方系统将目标信息发送给贷方系统。每天大约有 4,000 笔交易。偶尔一天几次，影响贷款。如何解决这个问题呢？使用 MQ 是最容易想到的。当时公司没有使用MQ中间件，所以建一个是不现实的。我们该怎么办？

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

问题分析：借鉴MQ的设计原理，发送方先将消息发送给Broker，消费者从Broker拉取消息进行消费，抽象出异步处理的本质是数据暂存+选择性处理，那么问题来了，数据临时存放在哪里，内存呢？文档？数据库？ ……，是拉还是推，定时还是随机的选择……，想了想，发现除了MQ之外还有很多其他的解决方案。总结出一般的解决方案，可以在不同的具体环境下推导出来。不同的场景。当时设计的方案是将数据存储在ftp服务器上，实现起来比较简单。没有最好的解决方案，只有合适与否。莫非公司没有MQ中间件，所以这件事情解决不了？

3.可扩展性技术解决方案

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

问题定义：业务方想快速上线，但实际开发需要2周时间。主要原因是他们不了解业务，需要有一个熟悉的阶段。这个阶段需要很多时间，真正的开发时间并不多。为什么？解决这个问题？

问题分析：虽然主要矛盾找到了，但很明显一个方向是涉及到业务方的发展。平台只是起到一些支持和答疑的作用，但是让业务方的同学进来，有一个挑战：别人没学过Flink，你让他发展，业务方愿意吗？进一步抽象整个业务，我们发现我们的需求场景在变化设计方法论包括哪些分析，实时指标也在变化，但是整个流程是不变的。表示为y = f(x)，也就是计算一个x，转化成结果就是y，所以当时我整理了一下，什么变什么不变，从变数中找到常数这里需要的另一个能力是抽象分层。如果只把 f() 看成一层，那么就只有一层抽象层。如果里面有复合函数，那么就有多个抽象层，这取决于问题。不同的人设计的抽象层次是不同的。当时借鉴了 Flink 的一些设计思路，将整个过程商业化。业务方只要选择并勾选一些信息，就会自动生成 Flink SQL，然后点击运行。对于大家来说，SQL 上手比较简单，基本可以理解，也不算太难。平台方不需要像以前一样投入充分的人力来学习业务知识、开发、测试和上线。

总结

本书将分享一些技术解决方案设计的想法。整个方法论包括本质论、矛盾论、系统论和演化论。通过三个具体案例来说明如何使用该方法。