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

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

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

镜头后的导演韩寒

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

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

代码执念

每个程序员对美的代码的认知不尽相同,但大多有个共识,那就是,架构师设定的各种条条框框简直是对美的亵渎
其实,你可能对架构师的执念一无所知!

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

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

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

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

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

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

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

1
2
3
if ( 1 == iCount ) {}

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

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

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

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

张曼玉版金镶玉

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

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

Python之禅 收个尾:
The Zen Of 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度左右的倾斜,进一步防止蜂蜜流出。

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

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

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

架构之路越走越无知,一如人生路。
尊重架构师的力量,一如尊重未来的你。