许式伟：毕业两年成为首席架构师，我的技术学习方法论

作者 | 许式伟

编辑 | 高嵩

今天想和大家聊聊架构，和架构以外的二三事。

在过去的工作经历里，我看到不少架构师都倾向于把架构看作一项纯技术性的行为。他们的工作流程是这样的：产品经理根据用户的需求做出产品设计，架构师再依据产品设计给出实现，也就是软件的架构设计方案。

在我看来，这恐怕是个误解。我们做架构，空有一身技术是远远不够的，知识的深度和广度，往往会对架构能力起着决定性的作用。 而这些知识，从你踏入 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 是否靠谱

• 如果我来做，会倾向于往哪个方向走

当你深入研究了新技术的思考方式，以及它要解决的问题，就会知道它和自己要解决的问题有多大的相关性，这要求你具备严谨的思维方式。或许在很多人眼里，严谨是古板的，会扼杀创新。

但在我看来，严谨不是创新的对立面，而是创新的基础。 奇思妙想再好，如果不经过严谨的推理过程，就无法变成行动力。用这样的方式去分析，可能会出现一些比较大胆的选择，但并不是随意为之。

做架构也是一样，需要做严谨的设计推演。这就要求我们建立完整的架构知识体系，看书学习当然是一个非常好的方式。但我发现，当我想推荐一本经典的架构书时，并不能快速想到推荐哪本。细数我接触过的那些与架构相关的图书，大概有以下几类：

• 架构思维类。 通常从一些著名的架构理论讲起，比如开闭原则、单一职责原则等等。其弊端在于过度理论化，而计算机科学归根到底属于工程技术类，应该实践第一。

• 设计模式类。 这类一般上来就进入架构的局部细节，每个模式的来龙去脉并不容易理解。就算理解了某个具体的模式，也很难真正做到活学活用。

• 分布式系统架构设计类。 通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起，阐述大型业务系统面临的挑战。这些知识虽然非常有价值，但无法延伸至通用业务架构，对大部分企业的架构实践不具备真正的指导意义。

• 重构类。 主要讲如何如何改进代码，其实是最实用的一类。但在我看来，一个模块最初的地基是最重要的，基本决定了这座大厦能够撑多久，而重构更多侧重于大厦建成之后，在服务于人的前提下怎么去修修补补，延长生命。

这些架构类的图书并没有达到我个人的期望，在我看来，它们都没有揭开架构设计的全貌。 所以一直以来，我就心存这样一个念头：“写一本不一样的架构书”。这个念想，正是《许式伟的架构课》这个专栏的由来，它和你现在能看得到的大部分架构书都不太一样。

在专栏中，我会通过理解软件架构的宏观视角，从零开始构建出整个信息世界，在这个过程中，阐述了架构思维范式，以及这些范式在日常工程实践中应用。

在内容设计上，我希望这是一个门槛最低的架构设计专栏，不仅帮助到想成为架构师的初学者，还可以让已经成为架构师的技术人规避一些错误的经验。在行文上，我会尽量避免深奥的术语，以通俗易懂的文字描述信息世界构建者们的所思所想。