今天想和大家聊聊架构,和架构以外的二三事。
在过去的工作经历里,我看到不少架构师都倾向于把架构看作一项纯技术性的行为。他们的工作流程是这样的:产品经理根据用户的需求做出产品设计,架构师再依据产品设计给出实现,也就是软件的架构设计方案。
在我看来,这恐怕是个误解。我们做架构,空有一身技术是远远不够的,知识的深度和广度,往往会对架构能力起着决定性的作用。 而这些知识,从你踏入 IT 行业那一刻起,甚至更早就应该开始储备了。
关于如何学技术,怎样储备知识,我想聊聊我的个人经历,希望给你一些别样的启发。
大学时,我接触到《理论物理》这门课,发现拉普拉斯方程式可以解高中的所有物理问题,《现代数学》中的分形几何也让我颇为着迷,不仅将图书馆里所有关于分形和混沌的书都看了个遍,还专门写了程序,将接触过的分形模型都用计算机模拟了一遍。
这两门课 让我看到了许多事物之间的内在联系,并开始思考和探究背后的原因。
这种思维方式对我后来的工作有很大影响,举个例子,很多人认为,存储不就是把东西存到磁盘里吗,跟数学有什么关系呢?但我发现往高深去做,存储系统和数学有非常紧密的关联。
通常的存储服务要保证数据不丢,必须存多份,这样会增加存储成本,经典的 3 副本存储,冗余度是 3。想用更低的成本存储,就要用到域代数。域代数遵循自然代数的加减乘除规律,但数据值控制在有限区域,不管怎么算,结果都在 0 到 255 这个域里面,所以称作域代数。
存储文件可以认为是 0 到 255 的一个序列,举个例子,一个 100K 的文件拆成 10 份,每份是 10K,存在 10 个地方,但文件仍然是一份。这时用域代数里的加法(其实就是计算机中的异或操作),从这 10 份数据里取出一份校验数据,数据变成了 11 份,它的冗余度是 1.1。
这是一种基于校验码的存储方式,成本比较低,但效果和双副本差不多,其中任何一个数据丢了,都能恢复回去。利用域代数降低成本,是存储领域发展的必然方向,七牛的 [存储 2.0][3] 就已经采用了这种方式。
所以,任何一个方向的技术要做到顶峰,都必须横向地去理解,因为世界上一切事物都彼此关联。学技术是不能过于专精的,在专精的过程中遇到瓶颈,就要往广度方向去挖掘。
2000 年我加入金山,当时分配给我的任务是软件的读盘和存盘模块。这个模块当时的重要性并不高,看着也比较简单,但我发现了不少有意思的挑战,其中之一,是要求你理解软件的所有功能,以及每个功能的数据表达方式。
这让我无意中触及到软件系统最核心的东西——数据。顺着这条线索,我研究了微软 Office 各个功能模块的数据存储方式,并把一些有趣的实现方法分享给同事,他们吸收了其中有益的部分,并据此修改了原有的软件设计。
一年后金山开始研发 WPS 2002,新版本被称作“格式兼容之战”,为了实现对微软 Office 文件格式的兼容,I/O 成了战略层面的技术,存盘功能从边缘模块,一下变成了整个 WPS 研发的核心模块。
于是,在 2002 年底,我作为首席架构师,开始领导 WPS 的整体架构设计,用了 3 年的时间做出了 WPS Office 2005,完全重新架构开发,做三大兼容:文件格式兼容、二次开发接口兼容、用户操作习惯兼容,产品定位:先立后破,做 Office 的替代品。
我们在软件架构层面做出创新,引入一个数据层,抽象出所有数据的存储过程,改变了此前只能通过对命令的反操作来实现的传统“撤销 / 重做”功能,让所有数据可天然回滚,轻松支持多版本存盘、Undo/Redo(撤销 / 重做),以及各种异步操作。
这个创新并不是对微软的简单模仿,其灵感来源于对增量存盘的思考。Office 有个“快速存盘”概念,用户正在编辑的内容,如果已经存过了一次盘,修改过后再次存盘,只需在原基础上补加数据。
相当于对同一个文件,存了两个版本的数据。于是我想,既然可以做快速存盘,就不必关心用户到底做了几个操作,要实现撤销和重做功能,只需要基于数据状态做前进和回退即可。
数据层的架构大大降低了研发的复杂度,在当时的金山起到了非常重要的作用。乍看上去,我像是运气很好,做的东西从边缘模块变成了核心模块。但我相信之前很多人都接触过存盘,但有多少人深入思考过其中的原理呢?
我始终认为,任何一件事情,想要做到极致,就必须把它当成一个学科来研究,把它琢磨透。 假设这个东西很好玩,你要去思考,如果把它做到极致,最终应该是什么样子。如果仅仅当成一个简单的任务完成,能取得的成果会很有限。
2006 年是我职业发展的分界点,WPS 虽然累计了不少用户,但并没有取得商业上的成功。如果产品无法让用户买单,从某种意义上说,你的价值并没有被认证。
彼时,国内盗版软件盛行,金山开始探索办公软件的互联网化。办公软件不同于游戏,游戏能成功转身,很重要的原因在于每个游戏都有其生命周期,但办公软件是工具,必须沿袭用户的习惯,互联网化相对难很多。
如果仅仅把办公软件在 Web 上做一套,能够为用户提供什么新的价值呢?办公互联网化,最终必须颠覆原有形态,而不是做一个 Web 上的 WPS,但在当时,我们实在找不到更好的方式。
于是突然我意识到,光有技术远远不够,必须理解业务及其运作方式,思考产品和商业的关系。 为了拓宽眼界,我一方面广泛参加行业里的会议、沙龙,找不同朋友聊产品方向;另一方面,我做了一个技术社区 ECUG,探讨 Server 端相关技术演进。
这期间,我逐渐跳出办公,横向接触其它领域。在研究搜索引擎时,我发现分布式存储的技术门槛相对较高,并且可以发展出独立的商业模式。当时移动互联网正处于萌芽期,雷军已经开始投资这个领域的初创公司。
所以,我预想一旦手机开始流行,键盘就不会再是人与人交互的主要形式,图片、语音、视频等富媒体会成为潮流,这将导致未来存储的需求出现爆发式增长。
虽然确定了新的方向,但如果想以此创业,我感觉自己还是太技术化了一点,欠缺的东西很多,于是我从零开始组建团队,建立了金山实验室,自由探索新产品,重点放在分布式存储研发,并承接了金山一些内部项目,好让自己的存储产品落地。
在我刚刚成立七牛时,最初的产品方向是网盘,9 月中旬产品发布,10 月我就决定转向底层存储,期间只花了一个月时间思考。这个决定做得很艰难,但从公司的核心竞争力考虑,必须做调整。
原因有 2 点:其一是当时国内云计算环境还不够好,七牛如果做网盘,很难找到一个第三方存储供应商,同时做底层存储和网盘应用,精力上会比较分散;其二,团队的基因偏极客,对终端用户了解不够深入,而程序员是我们最熟悉的群体,所以,权衡之下,我选择了云存储这条路。
同时,七牛也是国内第一家选择 Go 语言做服务端主体语言的公司,尽管当时 Go 的语法特性还未完全稳定,这个决定看上去有点激进和冒险,但实际上是经过我严格论证的,并非随意为之。
我一直认为:选择和信息的对称程度有关。你越不了解一个东西,越会趋向选择保守性的方案,而当你对某个领域了解得足够透彻,你的决策过程会非常自然。
在做决策时,我的方法论是:
先试图了解整个背景,看别人一般会怎么做
有哪些新兴的 idea,这些 idea 是否靠谱
如果我来做,会倾向于往哪个方向走
当你深入研究了新技术的思考方式,以及它要解决的问题,就会知道它和自己要解决的问题有多大的相关性,这要求你具备严谨的思维方式。或许在很多人眼里,严谨是古板的,会扼杀创新。
但在我看来,严谨不是创新的对立面,而是创新的基础。 奇思妙想再好,如果不经过严谨的推理过程,就无法变成行动力。用这样的方式去分析,可能会出现一些比较大胆的选择,但并不是随意为之。
做架构也是一样,需要做严谨的设计推演。这就要求我们建立完整的架构知识体系,看书学习当然是一个非常好的方式。但我发现,当我想推荐一本经典的架构书时,并不能快速想到推荐哪本。细数我接触过的那些与架构相关的图书,大概有以下几类:
架构思维类。 通常从一些著名的架构理论讲起,比如开闭原则、单一职责原则等等。其弊端在于过度理论化,而计算机科学归根到底属于工程技术类,应该实践第一。
设计模式类。 这类一般上来就进入架构的局部细节,每个模式的来龙去脉并不容易理解。就算理解了某个具体的模式,也很难真正做到活学活用。
分布式系统架构设计类。 通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起,阐述大型业务系统面临的挑战。这些知识虽然非常有价值,但无法延伸至通用业务架构,对大部分企业的架构实践不具备真正的指导意义。
重构类。 主要讲如何如何改进代码,其实是最实用的一类。但在我看来,一个模块最初的地基是最重要的,基本决定了这座大厦能够撑多久,而重构更多侧重于大厦建成之后,在服务于人的前提下怎么去修修补补,延长生命。
这些架构类的图书并没有达到我个人的期望,在我看来,它们都没有揭开架构设计的全貌。 所以一直以来,我就心存这样一个念头:“写一本不一样的架构书”。这个念想,正是《许式伟的架构课》这个专栏的由来,它和你现在能看得到的大部分架构书都不太一样。
在专栏中,我会通过理解软件架构的宏观视角,从零开始构建出整个信息世界,在这个过程中,阐述了架构思维范式,以及这些范式在日常工程实践中应用。
在内容设计上,我希望这是一个门槛最低的架构设计专栏,不仅帮助到想成为架构师的初学者,还可以让已经成为架构师的技术人规避一些错误的经验。在行文上,我会尽量避免深奥的术语,以通俗易懂的文字描述信息世界构建者们的所思所想。
我是许式伟,七牛云 CEO,ECUG 社区发起人,一个开源爱好者。曾就职于金山、盛大,在搜索和分布式存储相关技术领域有十几年的研发经验。这个专栏,是我第一次完整、系统地分享自己的架构经验和思考,我会将近 20 年的经验毫无保留地分享给你,相信你一定能够学有所得。
1、头条易读遵循行业规范,任何转载的稿件都会明确标注作者和来源;
2、本文内容来自“InfoQ”微信公众号,文章版权归InfoQ公众号所有。