聊聊一个架构师的第一次架构经历

前些天收到了好友寄来的一份礼物——是一本他们 InfoQ 出版的技术书籍《聊聊架构》。正如书名所述聊聊架构，架构可以聊的东西实在是太多了。其中的两个问题：什么是架构，什么是架构师，似乎是聊架构永恒的问题。

这也让我想起多年前的一个往事：大概是七年前的一个夏天，那是我首次负责一个应用项目的架构。当时的我写代码很自信，不管多复杂的逻辑和多深入的技术点，不管是静态语言还是动态语言都能像打字员一样快速写出我的代码，但让我去负责一个项目的架构，这让我这个程序员心里无比紧张，因为从内心讲我真的不知道架构需要做什么，架构师应该负责什么。

在这样的紧张中我使用了每一个技术者都引以为豪的武器——交流。聊了很多，各执己见的朋友也并没有给到很多实际有用的帮助。说的最多的一句话就是：架构师技术好就行了。这时我自己也开始认为架构师就是一帮写代码的人中间最厉害的那一个人，做的事情就是写出项目中最复杂的那部分代码。

现在想想，当年如果能从最基础、最本源的概念上理解架构，可能会少走很多弯路。虽然技术社区里可供参考借鉴的架构图不在少数，但是实践起来却总是千难万难。就像我问了这么多的技术人朋友，却也并未得到有效的架构信息。

总之，在「架构师技术好就行了」这样一个错误的想法中，我开始了人生的第一次架构实践，这时的我对架构其实并没有自信，常挂在嘴边的一句话就是：我是一名山寨架构师，正在做一个山寨的架构。虽然内心忐忑，但是我依旧按照内心没有思路的方式做着我的架构，结果可想而知。

正如我担心的那样，这是一个山寨的架构。因为我一个人在写着最复杂的那部分代码，其他人都在等候，进入了一个瓶颈状态，我成了超级代码工程师，试图写所有的代码做所有的事。起初还觉得无比美好，但问题就像原子弹一样爆炸了。

炸出的问题有：我们这个系统的边界是什么？我们系统有哪几部分组成？各模块之间怎么通讯？选择什么样的基础技术？为什么要这样选择？技术方案未来会遭遇那些坑？从技术角度这个应用将来如何持续扩展功能？等等一系列的问题追随而来的确像是核弹引爆后的地狱一般让人感觉一切多完蛋了。此时的我心中一次次的出现：安安静静地写代码多好！！！但谁让我是个山寨架构师呢！所有的伙伴在眼巴巴得看着我去解决整个项目的方向问题。

于是静心思考，这一系列的问题归咎为规划，因为做所有事情都需要规划。尤其是一个复杂的软件系统更需要规划，如果没有规划可能连一行代码都难写出。把这个问题从一个程序员的角度再去思考一下，其实也是一样的：你在写一个上万行的代码时难道是想到哪里就写到哪里吗？

当然不是！你一定会做很多抽象设计、对象规划、接口规划等等准备动作。也就是“上一辈程序员”口中所说的：详细设计。做架构主要的事情也依旧如此，需要对整个系统进行系统的规划：模块、通讯、边界、扩展、技术下沉等等工作。这样的规划完成之后项目方能正常跑起来。

此时的我好像不太喜欢架构师这个工作了，因为这让我感觉就是一个吹牛皮的文档工作者，好空虚，就是规划来规划去。正当我如此无趣之时，新的问题再次爆发了。项目中技术简单的部分一一被实现了，但是复杂逻辑深入的基础层却是像陷入沼泽的水牛，整个系统还是一块块接不起来的碎片。此时我想到的是：难的我来写吧。

这时的我又回到了第一次问题大爆炸时期的超级工程师。当然不用说重蹈覆辙。用程序员的话来说，这是进入了一个死循环。如何跳出这个循环，就是架构师要做的另一件大事：技术识别。识别出系统中技术的难易区域，并分解复杂技术，使之成为一个个技术的黑盒子，在此之上再进行新的技术规划，使整个系统从技术角度来看是分层次的，从难到易，从大到小，但各层之间又是互相的黑盒。这也常说的让系统模块间达到“鸡犬相闻老死不相往来“的状态。

系统技术的识别完成之后还要对另一种技术进行识别，即人的技术。什么样的工程师适合写哪一层的代码，哪一层的技术对程序员技术的深入程度要求到哪个点上。做完这些事情整个项目又开始平稳进行。我这个山寨架构师又开始暗暗自喜了，原来架构就这么简单。当然此时我也有了一定的空余时间，也可以继续写着我那喜欢的代码，当然只是一点点（现在想来架构师写太多的代码应该不是件好事）。

这样舒爽的日子过了一段之后，架构的问题再次被打破。首先是测试工程师来询问对于整体系统架构而言这个应用该如何更好的被测试，我们需要用什么样的技术来更好地保证软件的质量？然后是运维工程师来询问该系统将跑在什么样的环境之上？我们应该提供什么样的服务器？服务器上我们会做哪些配置和安装哪些基础软件，我们需要提供一个什么样的网络环境？有什么样特殊的网络配置？我们需要做哪些安全策略？等等。

此时的我又像是一个掉入冰洞的猎人无比无助，头顶成群的苍蝇飞着，心里在想：我只是个程序员，真的只是个程序员，写代码的！！测试，懂点，但不专业。运维，听说过，没干过。网络，知道原理插过网线，但好像也仅限于此。这些棘手的事情其实是考验架构师的一个能力：技术的宽度。一个架构师需要足够的技术的宽度。从软件到硬件，从开发到测试，从运维到安全等等都需要面面俱到的了解。

当然你可能不是这单方面领域里面最深入的人，但是你需要知道他们是怎么做的（不仅仅是皮毛，要深入原理），并且是最知道他们组合起来是个什么样的东西的人。当我努力的完成了这些之后我想我的第一次架构之旅也看似成功的完成了。因为系统可以进入交付使用状态。

但是新的问题再次过来了。这次过来问我的事情更多了。问题集中在系统在未来的运行过程中运维需要做什么？系统在未来的功能迭代中如何更方便的扩展？系统应该怎么修改？系统应该被怎么样升级？这时我再次进入困惑中，感觉这个架构的世界好长啊，怎么像保姆一样什么都要管的。

但仔细想想这是应该的，因为一个系统初次开发并交付只是它生命周期中的一小部分而已。后面的维护、改造、升级才占了整个软件生命周期的绝大部分时间。你是它的架构设计者，是它灵魂之所在，你当然应该设计好它的未来。这也是架构师做好的最后一件事情：系统未来的设计。

在这一切的任务完成之后，我也完成了人生中第一次架构设计。带着艰辛，带着害怕，带着山寨，但总算完成了。现在回忆起来这七年前的往事感觉很可笑，当时的我太稚嫩了。

仔细回忆回忆，这样的架构糗事其实是架构师成长路上的必经之路。因为一个没有经历失败的架构师一定不是个好的架构师。只有经历各种苦难，越过各种坑和各种痛苦之后才能成为一个优秀的架构师。所以更加感觉到聊聊架构的重要性，因为知识需要交流，知识需要借鉴，新的架构师需要不断学习。

架构师也是一个很独特职业，不像现代教育里已经很成熟的人文和物理教育体系，勤奋的人大都能经过系统的阅读和教育能走向成功。架构更像一种艺术、一门哲学, 架构师们也仿佛经过多年积累后忽然间就像打通了任督二脉。那么走向架构师之路是否真的无迹可寻呢？想来不是。

《聊聊架构》独辟蹊径，举重若轻的把晦涩难懂的架构哲学融入实例娓娓道来。建议有志于架构师的技术人员都来读读这本书，带你从一个老练的架构师视角重新审阅软件架构之美，从另一个视角看架构与人的艺术。