共计 3669 个字符，预计需要花费 10 分钟才能阅读完成。
分享七牛云 CEO「许式伟」对于这个话题的思考。
你好，我是许式伟。从今天起，我想和你一起来聊聊架构的话题。
开始之前，我先来和你简略介绍下我本人。
我是 2000 年开始工作的，已经做过 WPS 的首席架构师，也在隆重从事过技术钻研方面的工作，起初在 2011 年创建了七牛云，当初我是一名创业者、CEO。但不论角色怎么轮换，我感觉我的另一面始终是一名程序员、架构师
让咱们来设想一下，如果把信息世界看成一座大厦，把程序员看成这个世界的建筑师，那么，当初的你在负责什么样的工作呢？
当咱们把程序员类比成建筑师时，依照能力程度来分，我感觉大体能够分为三个档次：搬砖师、工程师、架构师。
软件搬砖师之名对应到建筑行业的建筑工人，他们的编程能力和业务基本上停留在重叠代码，依照要求去实现性能需要的层面。
只有能让程序跑起来，能正确地实现业务逻辑，就能够称为“会编程”的人。有时候，咱们也会看见程序员自称为“码农”“搬砖的”，尽管二者的工种不同，但从根底工作的类似度来说，的确有可类比的成分。
很多在行的人都会感觉程序员是一个很神秘的职业，但实际上程序员的根底门槛并不算高。我本人从 2016 年 2 月开始至今，始终在教几位 8~12 岁的小朋友学习编程。这个实践经验通知我：小学生齐全有能力学编程。而且，并不是只有局部小学生能够，而是任何一位小学生都能够学会。
然而，只让代码跑起来是不够的。这个世界是一直变动的，作为程序员，咱们更多的工夫是用来保护代码：减少新的需要，对已有的性能进行调整，批改之前代码遗留下来的问题，优化性能等等。
这是因为一个软件诞生之后，后续就是须要破费大量的代价去保护它，演进它。一个人是齐全保护不过去的，须要更多的人，很多的团队一起合作。如果面临了员工到职、岗位调整等状况，还会导致软件代码在不同人之间流转。
所以，一些有谋求的程序员会关注代码的品质。代码品质的评判能够有这样一些根本维度：可浏览性（不便代码流转）、可扩展性 / 可维护性（不便批改性能，增加新性能）、可测试性（品质治理）、可复用性（简化后续性能开发的难度）。
这一类致力于一直晋升软件代码的工程质量的程序员，咱们能够称他们为软件工程师。
工程师不会简略把写代码看作一门工作，把工作交代过来就完事。他们会有“洁癖”，代码在他们眼里是一种艺术，是本人生命的一部分。
他们会把写进去的代码改了又改，直到让本人称心为止。浏览和保护软件工程师写的代码会有一种赏心悦目的感觉。
然而，大部分商业软件都是一项极其简单的工程，它们远比很多传统的建筑工程简单得多，无论是波及的人力、工夫还是业务的变数都要多很多。
人力上，大部分大型的软件系统都有几千甚至几万人的规模，而这几千几万人中，却没有两个人的工作是反复的，他们都是在从事着前所未有的创造性工作。
工夫上，只有软件还在服务客户中，程序员们的发明过程便不会进行，软件系统依然继续迭代更新，以便造成更好的市场竞争力。
这些都与传统建筑工程的模式天壤之别。一幢修建自它实现之后，所有的变动便次要集中在一些软装的细节上，很少会再产生激烈的变动，更不会继续地产生变动。但软件却不是这样，它从诞生之初到其生命周期完结，从头至尾都在迭代变动，从未进行。
所以，光靠把控软件工程师的程度，依赖他们盲目保障的工程质量，是远远不够的。软件工程是一项非常复杂的系统工程，它须要依赖一个可能掌控整个工程全局的团队，来布局和疏导整个零碎的演变过程。这个团队就是架构师团队。
软件架构师的职责，并不单单是咱们通常了解的，对软件系统进行边界划分和模块规格的定义。
从基本指标来说，软件架构师要对软件工程的执行后果负责，这包含：按时按质进行软件的迭代和公布、敏捷地响应需要变更、防备软件品质危险（防止产生软件质量事故）、升高迭代保护老本。
那怎么能力成长为优良的软件架构师？软件架构师和软件工程师最基本的差异又在哪里？我认为关键在于四个字：掌控全局。
掌控全局，就是对系统的全貌了然于胸。从传统的建筑工程来说，修建架构师并不单单要会画修建图纸，而是要对地基构建、土质、资料、修建工艺等等所有有可能影响修建品质的因素都要了然于胸。
掌控全局，并不是无所不能，不是成为全栈。怎么做到掌控全局？外围在于对常识脉络的体系化梳理。这是架构能力构建和全面晋升的要害。这种办法不单单是在软件工程中实用。
比方学数学，我集体十分喜爱做的一件事件是本人去推导书上所有的公式。每一个公式我都亲自推导而来。
这样做的外围意义在于，我在尝试从 0 开始，去构建整个精彩纷呈的数学世界，整个数学发展史在本人的笔下从新演绎了一遍，前因后果清清楚楚。有时候你甚至会推导出还没有学到的公式，然而在前面学到了。这种体验十分乏味而又让人满足。
是的，掌控全局的前提是：在本人心中去从新构建出整个世界。在这个过程中，你不须要一上来沉迷在某个技术的实现细节（除非它影响了你对这个世界构建过程的了解），然而你晓得整个世界的脉络，晓得整个世界的骨架。
这个时候，你对这个世界的感觉是齐全不同的，因为，你曾经成为了这个世界的构建者。
而架构的实质，不也正是构建和发明么？
作为一个软件行业的从业人员，咱们可能接触各种各样的技术书籍。有讲编程语言的、讲数据结构与算法的、讲操作系统的、讲编译原理的、讲架构设计的，还有畛域技术类的（比方数据库、存储、大数据、人工智能之类）。
大部分类别的技术书，多多少少都可能找到几本经典著作。然而，架构设计很可能是个例外，当我想举荐一本经典的架构设计书时，我并不能十分疾速地想到应该举荐哪本。
从集体教训来说，我接触过的与架构相干的图书，大略有如下这些分类。
- 架构思维类。这类图书通常从一些驰名的架构实践讲起，比方开闭准则、繁多职责准则、依赖倒置准则、接口拆散准则，等等。这种图书的问题在于适度理论化。计算机科学归根到底属于工程技术类，实际第一。
- 设计模式类。这一类图书则一下子进入架构的部分细节，每个模式的前因后果并不容易了解。就算了解了某个具体的模式，然而也很难真正做到活学活用，不晓得还是不晓得。
- 分布式系统架构设计类。这类图书通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起，讲大型业务零碎面临的挑战。这些常识是十分有价值的，但无奈延长到通用业务架构，对大部分企业的架构实际并不具备真正的指导意义。
- 重构类。这类图书次要讲怎么把坏代码一步步改良到好代码。我认为这是最实用的一类。但在没有优良架构师主导的状况下，大部分公司的代码不可避免地越变越坏，直到不堪重负最初不得不重写。实际上，一个模块最后的地基是最重要的，根本决定了这座大厦可能撑多久，而重构更多侧重于大厦建成之后，在服务于人的前提下怎么去修修补补，缩短生命。
这些架构类的图书并没有达到我集体的冀望。因为它们都没有揭开架构设计的全貌。
我本人在职业生涯中前后大略做过十几次的架构类演讲，这也是我最为器重、反复次数最多的一类演讲。但同样地，这样零星的演讲对于传递架构设计思维来说，依然远远不够。
所以始终以来，我就心存着这样一个念头：“要写一本不一样的架构类图书”。这个念想，也正是明天这个专栏的由来。
这个专栏的内容组织算是我的一次尝试。它和明天你看失去的大部分架构书并不太一样。我基本上围绕着两个脉络主线来开展内容：
- 如何从零开始一步步构建出整个信息世界；
- 在整个信息世界的构建过程中，都用了哪些重要的架构思维范式，以及这些范式如何去使用于你平时的工程实际中。
这两大脉络相辅相成。首先，咱们通过还原信息世界的构建过程，剥离出了整个信息世界的外围骨架，这也是最实在、最巨大的架构实际案例。其次，咱们联合这个巨大的架构实际来谈架构思维，防止因对架构思维的论述过于理论化而让人难以了解。
我想，每个程序员都有一颗成为架构师的心。所以，从内容设计来说，我心愿这是一个门槛最低的架构设计专栏，也心愿它能够帮忙到想成为架构师的初学者，达成本人的指标。
在行文上，我会尽量避免深奥的术语，尽可能以通俗易懂的文字，来形容信息世界构建者们的所思所想。如果你在浏览的过程中遇到了了解上的阻碍，十分欢送你来给我留言，我将尽可能地依据你的反馈，做出必要的调整。
如果你曾经成为了架构师，我也心愿能够为你躲避一些谬误的教训。在过来的工作经验里，我看到不少架构师都会偏向于把架构看作一项纯技术性的行为。他们的工作流程是这样的：产品经理依据用户的需要做出产品设计，而后架构师再根据产品设计给出实现，也就是软件的架构设计计划。
在我看来，这其实是个误会。架构关乎的是整个简单的软件工程，它关乎实现它的人，它又因团队的能力而异。
同时，架构也关乎用户需要，作为架构师，咱们不只是要晓得以后的用户需要是什么，咱们还要预测需要将来可能的变动，预判什么会产生，而什么肯定不会产生。预测什么不会产生最为重要，只有做到这一点，能力真正避免架构的适度设计，把简略的事件复杂化。
谈了这么多，那么，应该怎么成长为优良的软件架构师？ 我想，一靠匠心，二靠悟心。 架构设计并无标准答案，但我依然心愿把我这些年的所思所想分享给你，更心愿这些内容能给你一些启发。
