我也曾对架构师的力量一无所知

是不是觉得这个标题似曾相识？

没错，就是致敬韩寒的那篇《我也曾对那种力量一无所知》。全文主旨就是业余玩家自嗨可以，但千万别狂妄到企图挑衅专业选手。否则，下场就和当初的 松江新区·奥沙利文·韩寒 一样，在潘晓婷面前只有开球的份儿。

虽说我和韩寒同年，但也算是“看着他长大”的。韩寒成名于新概念作文，而后不断开挂，在作家、赛车手、导演等多个角色上都游刃有余且扮演的相当成功，如此色彩斑斓的人生一直让我艳羡不已。而我，一介码农，初时随波逐流，醒时已亦步亦趋在架构之路上，艰苦非常。

因为，架构师的力量，我也曾一无所知。

代码执念

每个程序员对美的代码的认知不尽相同，但大多有个共识，那就是，架构师设定的各种条条框框简直是对美的亵渎！

其实，你可能对架构师的执念一无所知！

表面看到的：架构师成天没事找事，发布代码规范，设定评审标准。执着于代码的洁癖，分层的固化、API的标准化、中间件的抽象化...

实际发生的：光秃秃(没注释)的形似被混淆过(儿戏的命名|对不齐的段落...)的千行代码，事务的注解可能在每一层都出现过，逻辑代码散落在Business/Service/Dao各层，只是因为不喜欢Hibernate所以选择MyBatis，只是因为谷歌脑残粉所以选择Gson/Guava...

随心所欲的代码会带来维护的困难和各种技术债，不统一的技术框架会引入更多的学习切换成本和升级优化成本，评审口径不一致会导致团队聚焦散乱各自为战...架构师作为团队的一个高攻厚血型英雄，着实操碎了心。

架构师的执念，就是尽最大努力，在低位面减少技术熵增，高位面寻求技术突破。



通过规范指定的标准都是低位面，不需要你在低位面上浪费任何时间扯犊子。而高位面一定是无法给出规范标准的，任你创新和发挥。

”



同样是打印Hello World，就是有人会多渲染个ASCII字符画，让控制台输出不那么冷冰冰。







第一次看到架构师写出下面这种条件表达式的非常规写法时，

if ( 1 == iCount ) {}
if ( null != response && "SUCC".equals(response.getCode()) {}

年幼无知的我曾经“嗤”出了声：“写个等式都要颠三倒四，整噱头博眼球么？” 直到我写出了如下错误，

if ( iCount = 1 ) {}   //漏了等号，永远为真
if ( response != null && response.getCode().equals("SUCC")) {} //少写判空导致的空指针异常

这种代码的反差犹如龙门客栈的老板娘金镶玉，看似风骚泼辣杀人越货，实则纯粹坦荡至情至性。

张曼玉版金镶玉

当你傻傻的写乘/除2的N次方时可还记得骚气的位运算...骚气的try-with-resource...骚气的Lambda...骚气的动态字节码...比比皆是。

这么些年我总结下来，架构师对代码的执念就是八个字：稳中带骚，骚中求稳。

用 Python之禅 收个尾：



造物主思维

只活在IDE里写代码，是成不了架构师的。

某个风和日丽的下午，公司里一个小伙伴到我面前说：他申请在一个月内重写消息网关系统(承载短信、微信、邮件、App推送四大渠道)，原因是目前的系统太难用了。我的第一反应是 “WOC，我一直盼望的那个救世主终于出现了么?!” 其实吧，那个消息网关系统曾经是我和架构组兄弟花不少力气设计的，本身并没有什么大问题，最多就是随着消息数量的指数级上升，需要做一些性能优化，比如 分库分表 和 数据归档 就能解决大部分问题，而这些升级所需的扩展性在设计初期就考虑过。我生怕表现出对这位“救世主”的质疑而显得不礼貌，就小心翼翼的试探了两个问题：



“如何平衡上游业务的洪峰和下游消息通道的最大承载，最大化单位时间内的吞吐量？”

——微服务体系的流量控制

“个人交易消息和全局活动消息，如何存储和查询？”

——时间和空间的抉择



结果我得到的回复只是线程池、异步化和缓存的泛泛之谈，离真正的落地还差的很远。除了上面2个问题，还有同步异步、时效、延迟、通道隔离、信息补偿、环境开关等的实现同样很重要。

造物思维就是从0到1需要的思维，这个1可不简单，它必须包含进化到100所需要的一切基础铺垫。女娲抟tuán土造人只存在于神话中， 而架构师就是可以从0到1创造系统的“上帝”，只是翻船事故时有发生而已。不要轻视任何从0到1的创造性活动，这里所包含的知识或技能体量远超你的想象。

为了解释这个过程，请你单从数学的角度，告诉我 (0, 1) 这个开区间之中到底有多少个数？

• 如果是无穷，那么二进制的计算机如何运算这无穷的数字呢？有同学回答，计算机是使用离散的浮点数来表示这些小数的。是没错，而本质上，浮点数在坐标轴上也就只是很密集的点而已，根本就不是连续的线。

• 既然全是点，更加疑惑了，计算机怎么画线呢？到这里就可以结束了，因为显示器的像素本就是人肉眼无法识别的小格子，足够密集的点足以呈现出线的效果。

• 继续刨根问底，那得了解下什么是定点数了，才可以让密集的那些点更加的密集。



希望你能静下心来读读这篇浮点数，

读完你至少可以了解“取值范围”和“可表示的个数”之间、浮点数和定点数之间的区别等等。

 《格物致知-Floating Point》



我想我应该从一个理科男的角度，说明白了创造需要的是什么：足够密集的知识点和它们之间的连接。也有人把它包装成了“知识体系”，说到底，一个意思。

创造本身已然不容易，如何创造更加五花八门。架构选型其实就是选择如何创造。

同样是索引化的数据存储，Kafka是索引文件和数据文件分离，MySQL InnoDB却是索引和数据在同一个ibd文件里。都说多线程吞吐量高响应快，Redis却选择了单线程模型(Redis6已经加入了多线程实现，主要用于处理网络IO上。命令的执行依然是主线程串行执行)。孰对孰错？

所以创造从来都不是千篇一律，也不是一成不变，而是量体裁衣。

高明的架构师心里藏有无数的架构设计方案，但对于不同的场景，他会选择最合适的那个来实现。因为架构更像一种艺术而不是科学。你只看结论的话，或许最终方案并不怎么出色，甚至很普通。但是它是经过N个方案PK胜出的The One，对其他你以为更好的方案所面临的未知，你可能一无所知。

面对未知的勇气

我有深海恐惧症，许多人都有。因为面对黑不见底的海水，我们充满了对未知的恐惧。

百度有时也挺人性的

IT行业的未知每天都在发生着，经常让我们手忙脚乱。何谓"未知"？它可以是诡异的生产故障，可以是全新的技术，也可以是模糊的未来业务形态， 而架构师的核心职责之一就是从容的解决未知。

就，对大家来说一样都是未知，凭啥架构师就有勇气从容应对？傻孩子，架构师的身后哪里还有人？不得死撑哇！当然我是在开玩笑。许多诡异的生产问题有重启大法，但让习惯了SSH编程的你，使用Reactive来实现一套响应式服务端系统，这种未知领域你会如何应对？连产品经理都看不清的未来业务形态，你又会如何设计系统的扩展性呢？

草木皆兵

问：你这一生碰到过的最严重的生产事故是什么？

答：抱歉，从未碰到过。

你会如何评价此人？架构师生而从容，不仅是做到泰山崩于前而色不变，更是因为严重的事故甚至细微的事故苗头都早已被扼杀在摇篮之中。海恩法则指出：每一起严重事故的背后，必然有 29 起轻微事故和 300 起未遂先兆以及 1000 起事故隐患。

几年前有段时间我开车总觉得方向盘有点松动，一直没当回事，觉得可能车老了或者自己平时方向打太紧了。某天预约做保养，车店老板小马哥把我车开走没10分钟，就给我来一电话：



“你的转向柱可能出问题了，方向盘有点松，你之前有发现么？”

“我知道的，可能车老了吧，也没当回事。”

“你小子，转向问题很吓人的，我都不敢开了，到店里马上帮你检查看看。”

后来结果你们也想得到，真的是转向柱断裂！幸好在事态严重之前，小马哥凭借专业素养发觉了这个隐患。所以这到底是是我的无知无畏还是小马哥的小题大做？开车的同学都知道车的制动、转向是性命攸关的大事，但是你自问对 车跑偏、刹车异响、刹车发抖、转向沉重 都足够警觉么？其实，架构师在评审会上表现出的“草木皆兵”亦是一种执念，他所看到的“尸横遍野”，你可能一无所知。

知道自己不知道

给你100W让你实现一个数据库，这活敢接么？就说这活本身，先别忙嫌钱多钱少。把你所有的与数据库相关的知识拿出来，你看看能凑出下面哪些模块出来？



先搞清楚“知道自己不知道”的是什么，才有办法将未知变已知。解决未知就是不断的转化已知的过程。这也是为什么竞品软件都在造轮子，但是侧重点迥然不同，就是已知不同。这个“已知”可以是商业产品、开源产品，也可以是论文报告，还可以是业务、技术痛点，不一而足。RocketMQ当初参照了Kafka，在牺牲了部分性能的情况下优化了投递时效、消息顺序、消息轨迹等；TiDB 是基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库；开源调用链如Skywalking、Pinpoint都是基于 Google Dapper  论文实现的；界面简洁、容量大、搜索强的 Gmail 横空出世，面对众多传统邮箱的狙击，依然成为人们最爱的邮箱品牌，顺便激活了半死不活的 javascript ...

未知? 不过尔尔。

架构师的天赋

只有天才的程序员，没有天才的架构师。

架构师靠的不是天赋，而是勤勉，要靠大量时间进行实战操练和经验积累。身边水货架构师这么多，也是因为国内的技术氛围略显浮躁，留给架构师成长的那点可怜的时间和空间，时刻被公司项目挤压着，拔苗助长，不得不水。热门吵架题目“架构师要不要写代码”，理性点的人会把架构师做个分类，摘出个比如 业务架构师，说可以不用写代码。但是他不可能从石头缝里蹦出来，若没有对业务浸淫多年的历练(编码只是一个历练维度)，如何能设计出合理的业务架构来？所以别再问这种傻X问题了，何苦给自己的偷懒找借口还如此冠冕堂皇？宁愿换个题目讨论，“架构师的门槛是写多少行代码”。

技术密度

程序员起步阶段的技术能力，通常是“蜂窝”状的，也就是存在大量的技术空洞，而这些空洞需要通过勤劳的采蜜，累积一点一滴的“蜂蜜”来填满。科学爱好者都知道中子星的密度堪比黑洞，类比将地球压缩成中子星，直径只有22米，普通的原子都没办法在中子星附近停留，会被撕碎、经过引力坍塌后进一步压缩。架构师就擅长这种吸收并压缩知识的套路。硬要我给架构师的天赋定一个指标的话，那就是技术密度的高低。初二物理都学过 密度 = 质量 / 体积。对应到代码，同样质量的一个功能，你写一页，架构师寥寥几行，这就是高技术密度的直观体现。

有效练习

再来，假如已经部分交付如上图的一个“蜂巢”系统，现在需要你实现更多的“六角蜂室”以扩充这个蜂巢。



这个工作乍看起来像不像重复劳动？

其实不然。首先为什么选择六边形？ 不是圆形不是三角形不是正方形？经测量，六边形蜂室的所有钝角都是109°28′，所有锐角都是70°32′。曾有法国数学家研究过，如果要消耗最少的蜂蜡，制成更少间隙、更大容积和更坚固的容器，就只有这个角度的六边形。

其次蜂巢是倒挂的，为何液态的蜂蜜不会流出？ 因为蜂蜜本身含水量不到18%，流动性比水要低得多，但低流动性不代表不流动。所以蜂巢要保持9~14度左右的倾斜，进一步防止蜂蜜流出。

实际结果是，你的“蜂室”交付了，但是你对角度，一无所知。

我生来觉得自己是个愚人，即使学习成绩一直算优秀，也会全归于自己的勤勉。因为身边的天才好像真的不需要努力。我能成为架构师，也是走上程序员这条不归路的不得已之选。架构师之路漫长且艰难，而今我也只是摸到些许门路，大多时候对于自己的“不知道”依然惶惶不可终日。

你是否也曾对架构师的力量不屑一顾过？不管是立志成为架构师或已然成为架构师，都请谦虚并努力起来。谁也不敢妄言自己掌握了架构的终极力量，因为



架构之路越走越无知，一如人生路。

尊重架构师的力量，一如尊重未来的你。