简介：怎么去体现技术方案设计的深度是大家广泛关怀的一个问题，这个问题不是个例问题，因而本文次要分享下作者集体的一些观点和认识。

文章次要分为三个局部：

第一局部次要剖析为什么技术计划没有体现出深度，找到问题后就好解决，并提出技术计划的广度和深度特色。

第二局部是技术方案设计的方法论，次要包含了本质论、矛盾论、系统论、演进论四个方法论，形成一个闭环反馈链路。

第三局部是通过具体的案例，重复使用第二局部的方法论论述在实例的案例中如何去利用，加深对方法论的了解。

技术计划体现广度和深度

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 对于大家来讲，入门比较简单，基本上能看得懂，没太大的难度。平台侧不须要像之前那样齐全投入人力去学习业务知识、开发、测试上线。

总结

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

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