架构师必备逻辑思维

上次“技术琐话”刊发了张凯江老师的聊架构上篇《“构建”世界的能力-架构能力》，读者们反响强烈，特刊发下篇，以飨读者。

— 4 —

推理模式-架构师必备逻辑思维

    我们认识世界的过程中，潜意识或有意的运用大量的推理。推理就是从一个或几个已知判断推导出一个新判断的思维形式。任何推理都包括：推理依据的已知判断（前提）和推出的新判断（结论）。推理的几种方式：类比法、归纳法、演绎法、归因法。我们在工作、演讲、取舍、决策...时，无数次的应用了这些推理模式，但是我们可能当成常识来理解，反而忽略人类如何有此类能力。

     我们掌握了推理的原理，会优化我们推理的过程，更加“客观”的认识这个世界。甚至我们学的的目的，就是为了增加推理前提的宽度（更多领域）和深度（更准确）。具体网上搜索了解，这里举例说明一下：

l类比推理法：物以类聚人以群分

    类比推理是两个对象在一系列属性上相同，而且已知其中一个对象的还具有其他属性，由此推断另一个对象也具有同样属性的推理。它不是一种证明，用于探索新思路、新发现的一种观点和手段。

1、鲁班类比带齿的草叶和蝗虫的牙齿，发明了锯；

2、人类仿照鱼类的外观和它们在水中沉浮的原理，发明了潜水艇；

3、设计模式的概念最早起源于建筑设计大师Alexander的《建筑的永恒方法》一书，尽管Alexander的著作是针对建筑领域的，但他的观点实际上适用于所有的工程设计领域，其中也包括软件设计领域。在《建筑的永恒方法》一书中，Alexander是这样描述模式的：模式是一条由三个部分组成的通用规则：它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题解决方案的核心设计。

l归纳、总结法，看啊看的就找到规律了：

1、每天开车回家，发现连续好几个周五晚上，回家时间比平时晚半小时。

2、总结个规律，发现周五晚上高峰期确实比平时堵。

3、倘若周五有赶飞机等急事，需要提前预备半小时时间。

4、如果周五赶飞机遇到下雨呢？

5、如果春节期间北京的周五呢？

... ...

     归纳推理又分为完全归纳推理和不完全归纳推理。着重你看到的是否足够多（样本足够多），你总结的规律能否拟合此类现象（样本的好坏），你想找的规律是否称之为规律（模型假设是否合适）。如果了解机器学习的原理，这些很好理解。 个人建议大数据时代，对数据sense要积极建立，不能像父辈或没文化人一样一样，看到几篇赞扬祖国文章就觉得祖国一片美好；看到几篇诋毁祖国文章，就觉得满眼都垃圾。（真心期望推荐系统更加智能一些）。针对架构师，见过或经历过很多案例，可以采用类比法，然后归纳总结推理。不能拿一年的经验工作十年；而是工作十年，至少积累十年的经验。这样才有可能爆发出、演绎出更多的经验，不担心技术更新、行业更新。

l演绎推理法：（大前提、小前提、结论）三段论：

1、大前提：redis发布版本中自带了redis-benchmark性能测试工具，可以使用它计算qps。假如我使用50个并发连接，发出100000个请求，每个请求的数据为2kb，测试4核8G机器redis服务器性能，测试结果每秒44150.11个请求，既QPS4.4万。

2、小前提：现在有个场景，50并发，每个请求1.5kb左右，场景支持并发多少，需要配置什么型号机器。

3、结论：4核8G机器，可以支持4万并发。

    如上所示，演绎法需要积累或学习很多大前提，以及大前提需要满足的各项指标。当遇到问题时，能框进大前提里，结论很容易得出，并且通常是正确的。 

1、日常我们需要对mysql、es、mangodb、redis、消息队列、tomcat、nigix、netty、java、go等中间件或语言有相关的认识；当然也需要对常见的系统架构有这种规律性认识。比如：广告架构、搜索架构、推荐架构、交易架构、秒杀架构、log架构、监控架构... ...有规律性认识。构建自己的大前提库。

2、当需要构建系统，比如秒杀功能场景时，能够快速确定当前小前提(应用场景)归属哪个或哪几个大前提

3、这样可以快速组合得到一些结论，做一些调整，作出响应。不能遇到新的业务需求，从头开始学习、实现。

l归因推理法：

    也叫溯因推理，是寻找最佳解释的过程。

    架构师在排查系统问题、性能瓶颈是常用，需要配合测试、日志等手段一起使用。也是俗称的解决问题能力。通过溯因方法解决系统的问题，是在丰富的知识矩阵基础上展开的。例如基于机器学习的广告点击率的预测、基于协同过滤的推荐系统，通过归因设计出更加有效率的反馈系统，不断地优化算法、调整特征数据。随着神经网络、深度学习的发展，很多不能解释的系统出现，只能通过事后数据验证来判别优劣，构成一个更大的溯因循环链（这也是现代产品必备的基本要素）。

    总之，从业者需要把自己的经历、见到的案例能够形成自己的知识体系，当遇到问题是，选择合适的方式解决问题。如果不能形成对“世界”的认知体系，穷尽终生也学不玩的知识，也会有学不完的困惑。

    注：把对架构过程中常见关键术语解释一下，便于我们面对新技术时，能够迅速掌握个大概。

1、设计模式：类似问题较为通用标准的解决方式，前人把遇到的细颗粒度问题分门别类阐述，形成的标准解决方案。

2、架构：跟设计模式有点类似，视角更高、解决的问题更宏观一些。

3、组件：组件作为构造软件的“零部件”。供应用开发人员在构造应用系统时选用。

4、框架：框架是为了解决特定问题而存在的，但只能解决通用部分，留些口子让使用者完成。诸如模板框架、缓存框架、MVC框架、ORMapping等，框架不能直接使用，需要二次开发。比如：spark、flink框架预留了很多接口或钩子，需要应用开发人员在算子基础上，定制自己的应用，而流计算、批计算归类为设计模式或架构。需要开发人员干的事情少而简单的框架就是优秀的框架，如springboot。

5、平台：平台的概念类似框架，但又结合的架构的考虑，它是更高层面上的“框架”，准确说是一种应用。这里跟技术本身关系不是太大，是应用级别。

6、中台：如果几百个字说不清楚这个概念，那么就不是技术圈的概念。个人觉得不应该由技术从业者解释，越解释越乱的感觉。

7、中间件：从更高的层次看，类似于组件。是解决某类问题，可独立运行的应用。如：解决各类存储问题的数据库中间件，解决消息传递问题的消息中渐渐，解决web服务的中间件框架（tomcat其实也算框架）。

8、工具：个人框架、架构、中间件都带有工具的属性。造成it从业者被工具困扰太久太久，以至于对一些底层逻辑理解偏差，太专注工具的使用，而对工具形成的初衷不了解。而工具、轮子也是从业者喜好之处，形成死循环。

---

— 5 —

锤子VS钉子---寻找大锤子VS制造大锤子

    孔子在论语中说到”君子不器”，我们不能把自己的身份、技能、做事方法等固化，甚至我们有必要刻意的摆脱自己头上固有的标签。假如我们把经历的眼见的现象案例称之为经验，归纳后变为规律，基于规律我们制造的、用顺手的工具称之为“器”。显而易见，“器”能解决的问题是规律能覆盖的现象，但是规律也可能有不适用的时候。

    我们不能像圣人一样留下永恒的“道”，只能不断的发明轮子、工具，期望留下一些痕迹。按照心理学来讲，人们总想证明自己的理论是正确的，说不服别人，就制作出一个工具来证实能够提升多少效率。这个事情没有任何问题，只是这类东西太多了，造成两个不好影响：第一、太多了，选择困难。第二、太好用，成了工具的奴隶。

    有人说过，如果你手里有一把锤子，所有东西看上去都像钉子。还有一位说过，如果你有一个钉子，就会满大街找锤子！这两个现象在我们工作中每天都会上演。

手里有锤心中无锤不要见人就锤，工具是死的人是活的，不要被工具禁锢。by 知乎。

1、使用工具要懂工具的魂，而不要做工具作恶的傀儡。

2、用好工具，学会甄别工具、创造工具。不过在我看了，能创造工具的人真的很少，基本工具都是提炼、孵化出来的。

    关于道、术、器网上论述很多，可以自行搜索。这里把工具概念放大一下，把这个问题泛化。从不同层面看，语言层面、中间件层面、存储层面、开发框架层面、行业层面等难道不都是一种工具吗？PC技术、web技术、移动技术、ai技术不是都是一种实现“平行世界”的工具吗？新的思维方式、能力不是提升效率的工具？面临新技术（工具）我们怎么处理？我们不用太强调道、术、器，而强调应该具备哪些能力。到底我们应该把时间花费到哪里？我引用三本书的内容，读者可以自己搜索学习。

l跟着高人“足迹”

    我们不一定能跟高人共事，但是跟着他的足迹应该是有可能的。如果能透过现象、发现规律、能感知到价值更好。

    李善友老师有本《第二曲线创新》很不错，里面提到“单一要素最大化”，聚焦第一曲线的一个要素，把它放大为第二曲线的全部。我们发现商业创新太难，但是我们可以跟着政策、高人或企业的发力点，布局自己的未来。新的商业创新背后一定会用到新的技术、工具、思路、能力。比如：移动互联网在10年左右随着智能手机普及，移动技术肯定会蓬勃发展，如果我们能10年左右学习智能手机相关技术、工具，肯定能个人利益最大化；入局这个产业生态，也会分得一杯羹。

    当然例如共享单车、p2p、区块链，入局后失败惨重。 如何甄别这些呢？作为个人，对新的技术、模式一定要投入时间学习。作为创业者我们一定要对成熟生态做储备工作。例如：2年前抖音号获得粉丝的难度比现在容易多了，竞争压力小多了。

    背后也可以用笨鸟先飞的思路来理解，如果平时可以训练写一手漂亮的文字或平时积极主动的分享，在这波知识付费势头下，肯定会有一番作为。

l该学什么，别贪多

    推荐我校友张萌美女《人生效率手册》中七个人物法。大致思路是写出自己想成为的或作为榜样的七个、层次不同的、职业目标人物；列出每个人在架构方面（当然其它也可以）的三项能力；按照聚合排序，选出三项能力或本领；然后死磕这些能力或本领。比如：我当初筛选技术方向时，明确未来几年，自己要向商业化广告、大数据、ai这几个方向学习。

    书中描述很详细，这里不累述。有明确目标了，不仅仅让自己有个灯塔，最重要的是你取舍拒绝将会很简单。时间管理将会很简单，抗诱惑能力也会加强。往往我们不是不知道做什么，而是不做什么决策不了。

l 新时代的学习方法

古典老师有本书《跃迁：成为高手的技术》也很不错，里面提到联机学习的方法。移动互联网创造的了太多的信息、概念，人与人之前连接更多、更复杂。作为从业者，如何利用呢？联机学习可以称得上互联网时代全新的学习方式，值得拥有。

   我们不是不愿意学习，而是学习后，投入产出比较低，会丧失学习的动力。学会功利式学习，多读书、多总结、多分享，倒逼有价值的输入。

    注：这三本书真心推荐。

---

— 6 —

非功能性需求--静态知识容易体系化

    对于架构师来说，静态知识体系是通用的。业务知识没个几年打磨，很难体系化。就算静态知识来说，很多思想、思路都是从其它行业、现实中抽象而来的。

    任何行业的领航者，源源不断的思考源泉来自哪里呢？除了领域内深厚功底外，在现实世界中的经历，对生活的感悟是灵感的源头！毕竟任何技术都是解决生活的遇到的问题，灵感也是来源于生活。近年来自己突然想通一个事情，世上很多钻牛角尖，有一种是见得太少。下面举例把架构中用到一些技术跟现实中对照梳理一下（例子有些牵强，只为回顾技术点。ps写了半天没点技术相关内容也不好）：

    弹性扩容、微服务、注册发现、微服务架构：

疫情期间，全国医疗团队支援湖北。北京派出136人（多名医生、多名护士），支援武汉协和医院。协和医院把136名医务人员注册备案后，安排到相关科室，由医院统一协调安排工作。提升医院医治病人的能力。这里医院相当于微服务体系。其它医院也接受援助，不同医院管理规则肯定有差别（微服务架构有多少实现方式），但整体效果差别不大。另外，如果把医院当成服务个体来看，火神山、雷神山也相当于快速扩容的案例。

    阻塞、熔断、限流、降级、涟漪：

全国各地排医疗队到武汉前，处理不过来的病人呢？  阻塞：排队在某处引起体系奔溃，人心惶惶！限流：有选择的接受病人！降级：简单处理一下或不接受非疫情病人，让病人回家隔离！熔断处理：接收到一定阶段后，不在接受新病人！涟漪处理：救护车在院前做一部分处理，防止带到医院上游造成压力！

    隔离、关键链路：

隔离：武汉封城，防止问题扩散！关键链路，无论如何食物链路必须通畅。

    API网关、路由：

外交部新闻发言官，发布官方信息后，各个媒体才能得到分发处理。

    鉴权\注册\权限：

全国统一的身份证号；信用出问题后，坐飞机被限制。

    分层：

早些年贷款买过房的人知道需要走多少流程就知道了，职责不同，层层审批，一排排红章。这里可以想想纵向横向分层的场景。

    负载均衡：

前段时间境外新冠输入严重，北京机场压力过大。统一协调后，按照规则不同航班分发到天津、太原等地，降低首都机场压力。

    削峰：

98年洪水，宜昌站的最大洪峰流量是6.36万m³/s。而10年7月三峡水库的入库流量也达到了将近7万m³/s，如果这个流量再次通过荆州河段，洪水的威力绝对不亚于98年的洪水，然而三峡工程凭借其巨大的拦洪能力，硬是将7万m³/s的洪峰（入库流量）削减到4万m³/s（下泄流量），几天之内将大约70亿立方米的洪水拦在水库（消息队列）之中。

    统一配置中心：

每个银行的存款利率都不一样，通常各大银行的存款利率都是在央行的基准利率上,进行浮动得出的。央行自己调整后，各大银行自行更新自己利率。

    框架：见上文。

    同步、异步，阻塞、非阻塞：

同步阻塞：小时候妈妈给宝宝喂饭，妈妈喂完后才去刷锅刷碗。同步非阻塞：宝宝长大点能自己吃了不用喂了，妈妈看着宝宝吃，确认吃完后才去刷锅刷碗（爱心泛滥&独立培养）。异步非阻塞回调：孩子更加懂事了，妈妈做好饭给儿子（立马干别的事），儿子边玩手机游戏边吃饭，妈妈去看电视，儿子吃饭后，告诉妈妈，我吃完了，妈妈再去刷锅刷碗。

远程调用、超时、重试、幂等、队列等：

高中同桌男女谈恋爱，自习时候小声相互表达爱意。高考考入不同城市大学，只能通过书信（远程调用）表达相思。本来约好一周一封来回信，某周末，男孩没有收到女孩回信（超时）。男孩又写了一封信邮寄（重试），由于邮局原因，积压好多信件（队列），女孩没有收到男孩来信也没法回信（突然故障），邮局恢复后后突然收到好几封信，回了一封信（类似幂等处理）。

    通知：

村口大喇叭播报，疫情期间所有人不得外出。成年人无法去劳作，学生无法上去，幼童无法出去游戏，不同角色人得到通知，表现及造成影响不同。

    选举：

英蒂利海上大帝国选举领袖，采用自荐提名式，最终获得票数大于一半获选，否则一直选下去。某次发生大风暴，隔离了领袖所在小岛，没办法，其它岛屿选择出了新的领袖。

    交易：

一手交钱一手交货；让村长当个担保人，先把钱给村长；

    广告竞价：

线下拍卖机制的参考和不断优化，最终形成的GSP广义第二价格拍卖这种易于操作、均衡各方利益的竞价方式。

    前后端分离：

各人自扫门前雪，莫管他家瓦上霜的流水线的工作方式。其实从纵向分层、微服务来看，核心问题是，中心避免不了？中心控制放到哪里？如何去中心化？

    日志、监控：

“飞机黑匣子”是俗名。它的真名很普通：“飞行数据记录仪(FDR)”。它是一种将飞机飞行的情况储存下来的仪器，当“不幸”发生以后需要了解飞行情况时，可以通过一些设备把它们播放出来。14年，马航出事后，对航空器实时位置跟踪提出事件触发和定时执行的思路。包括预警等设置。

    全链路跟踪：

举个业务系统例子，强调无侵入性、低成本、与业务（品类）无关的通用实现。“食品质量安全追溯系统”是一个能够连接生产、检验、监管和消费各个环节，让消费者了解符合卫生安全的生产和流通过程，提高消费者放心程度的信息管理系统。

    服务部署、docker、k8s：

集装箱、火车皮运力调度调度真是伟大的发明。把繁荣的车船码头变为历史，间接的促进了货品尺寸标准化。

    流计算：

了解一下自来水厂净水过程。如果某个节点出现问题，将出现“系统故障”。

    批处理计算：

小区凌晨垃圾调度车把垃圾桶中垃圾调度到郊区垃圾场，垃圾场定时启动相关流程，批量处理这些垃圾。（从时间间隔长短来看，批流、实时离线是个相对的概念）

    存储距离、存储格式：

老家山西产煤，小时候经常看到火车、汽车运煤出省，比如到天津港口；也有把煤加工成焦炭运输出省，到港口货船；也会本地发电运电到全国直接使用。如果从物质永恒不变角度来看，自然界（人类）需要哪种形式的物质，需要转化、存储、使用。

    数据不一致、cap：

疫情期间，政策一天一个样。工作需要拜访其它公司，进写字楼有的只要扫码、有的需要登记、有的直接不让进... ...。我们抛开政策理解的因素，各个执行点对政策的接收时差肯定有区别。

    冗余：

飞机通常会有多个发动机；汽车都会有备用轮胎；也有类汽车轮胎直接装到车上，当重量达到某个阈值时，可以直接接触地面承重。

    ... ...

    注：架构师的抽象是为了获得更好的实现方案；产品经理的抽象是为了更好的发现需求点，设计优秀的产品解决方案满足需求。

---

— 7 —

功能性需求的难点-多元化思维

    有很多产品经理方面的书籍对功能性需求的管理有详细的描述。需求管理不是我们讨论的范畴。试着思考，为什么系统要考虑可扩展性？为什么产品和技术要掐架？为什么要上各种中台？究其原因，是我们对需求的把控能力、或对需求变更的把控能力较差造成的。或者说，需求随着用户群体效应、时间变化会发生质变，在每个时空用户三维坐标系内都是不同的。

    我们不知道谁发现了水，但是肯定不是鱼。后验就是必须体验后才知道的，例如这杯水热不热。“需求”在一系列干系人面前，是个特殊的要素。可以明确的是，谁也无法真正的掌握它，只能通过事后的反应、数据等点点滴滴来验证当初的决策事是否正确。现代软件产品对这种后验的支持，必须很到位才能有竞争力。

    面对不确定问题时，最好的解决思路不是试图找到解决办法，而是提升对问题变化的敏感度。创业也好、研发新产品也好，都是如此，当然构建世界也是如此。多元化思维值得期望成功的人们拥有。

    成大事者，一定要有从全局观察、大处着眼的气度与能力，绝不能拘于小范围或局部；扩展多元化思维，是一个人走向成功的动力与方向。人的大脑是多元化的，多元化思维是多元化大脑的最佳思维方式。然而，过去我们所受的教育，使我们习惯于“直线式的思考”。其实这并不是一种好的思维方法，相比、较而发散性的多元化思维在处理各种问题时要迅速和有效得多。

    这里推荐《穷查理宝典》这本书。

注：我们一定要把架构提升到一定高度，而不是简单执行层面。我们的偶像应该是邓小平爷爷，中国社会主义改革开放和现代化建设的总设计师。

---

— 8 —

结语

    回到文章开头。复杂事情往简单了去想，是拆解，是切割。确定边界后，找到某个点突破，就像一剑破万法；而将简单事情往复杂了去想，是缝补，是搭建。形成面面俱到的规矩、规划、指导方案，规矩内任何组织都逃不出框架，就像是打造自成规则的小天地。

    你的答案是什么呢？欢迎留言！

名句摘抄

“授人以鱼，不如授人以渔；授人以渔，不如授人以欲。”　就是指没有直接给予物质，而是教以方法或某种信念。

如申请加入技术琐话读者2群，请在公众号回复关键词：读者群

作者介绍 ：

张凯江：专注IT行业15年+。曾任科技上市公司技术总监，多年政府toB行业经验，

2014年投身互联网行业创业。现从事工作为OTT\IPTV提供内容变现商业化产品、视频运营解决方案。爱读书、爱思考，喜欢打篮球、遛狗。公号：体制化思维。

 往期推荐：

— END —

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。

觉得有启发，点个“在看”，转给朋友们