共计15555个字符，预计需要花费39分钟才能阅读完成。
作者|楚衡
“架构制图”这词乍一听仿佛有些艰涩，但如果提起“工程制图”，置信绝大部分工科背景的程序员们都不会生疏，甚至还能独特感叹下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。
软件工程也是工程，因而传统工程制图的一些根本实践，在软件行业同样实用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需要和形式也天壤之别，无奈间接套用。作为软件行业的从业者，你能够齐全不懂工程制图，但你不得不懂架构制图——这是任何程序员职业生涯的的必修课。
IEEE给出的定义：架构是环境中该零碎的一组根底概念（concepts）和属性（properties），具体表现就是它的元素（elements）、关系（relationships），以及设计与演进的根本准则（principles）。
CMU软件工程研究院的定义：架构是用于推演出该零碎的一组构造（structures），具体是由软件元素（elements）、元素之间的关系（relationships），以及各自的属性（properties）独特组成。
综合上述各种权威定义，软件系统的架构通常须要蕴含如下四类外围因素：
最近有部很火的网剧叫《摩天大楼》，讲述了一段匪夷所思的悬疑故事。为什么扯这个呢？因为我想借用这个剧的题目来问个问题：摩天大楼是由谁建起来的？兴许你心里会默念：废话，不就是建筑工人们一砖一瓦堆起来的嘛。认真再想想？背地是不是还有一堆操碎了心的修建设计师（比方剧中帅气的林大森）和土木工程师们？他们尽管不搬砖也不扛水泥，但如果没有他们产出的那些繁琐谨严的设计图纸，摩天大楼是是不可能像农村自建房一样仅凭工人们各自的教训与想象力就能疾速安稳地竖立起来的。
正是靠着这些图纸所描绘出来的工程蓝图（blueprints），才让成千盈百工人们的分工合作和验收规范有了根据：大家只须要照着蓝图，循序渐进地把本人所负责的那些砖瓦添上去就行了；只有蓝图正确，且施工过程也没有偏差，最终顺利竣工只是个工夫问题。
与修建、汽车或者任何其余工程行业一样，软件在落地实现（编码）之前也须要先有蓝图；而其中最重要的一份蓝图，就是架构设计。没有架构，仅凭程序员本人脑子里的含糊构想，兴许你能够像传统手艺人一样单独发明出一些美妙有用的小东西（比方Linux0.01版本），但不太可能以工程的形式协同一个团队独特建造起一个与摩天大楼规模相似的简单软件系统（比方古代的Linux零碎）。一方面，人类的思维能力终归无限，必须依附架构这种高度形象和简化的蓝图，能力让简单零碎的发明、了解、剖析和治理变得可行；另一方面，量级达到肯定水平的大型零碎，也只能依附多人分工合作能力实现，而架构也正是多人沟通合作的重要根底。
软件我的项目的最终价值产出就是软件系统，而架构作为软件系统的灵魂和骨架，能够起到如下作用：
如何掂量一个软件产品的品质？上图是ISO/IEC25010规范定义的软件产品品质模型，包含以下8个大类：
上述品质模型中列出的所有点，都是架构设计须要着重思考的。其中除了性能适宜性以外，其余所有点都属于非性能需要的领域，这也是辨别架构好坏的真正分水岭——好的架构设计，不会停留在仅满足性能需要这一最根本的需要档次上（最坏的架构设计也同样能做到），更重要且更难以应答的是其余泛滥的非性能需要。
要不是篇幅所限，这一页PPT显然不够装：
了解了架构的概念和重要性后，真正的架构师修炼之路才刚刚开始。如何设计一个好的架构？这显然是一个十分博大精深的主题，但并不是本文的重点，因而这里只简略列举了一些根本思维（准则）和经典套路（模式）。当然，架构设计更靠近一门教训学科，仅停留在能脱口而出一些玄乎而高大上的实践概念必定是不够的，须要结合实际工作内容和业务场景多多实际和琢磨才行，否则只能算是彷徨在架构的门外，连入门都谈不。
SOLID准则是一套比拟经典且风行的架构准则（次要还是名字起得好）：
此外，咱们做架构设计时也会尽量遵循如下一些准则（与上述SOLID准则在实质上也是相通的）：
架构模式（architecturalpatterns）与咱们常探讨的设计模式（designpatterns）并不是一码事，但如果仅从“模式”这个角度去解读，两者的理念都是统一的：针对给定上下文中经常出现的问题的通用、可复用的解决方案。最次要的区别在于，架构模式会更高维形象和偏全局整体（毕竟是使用在架构设计层面）。
常见的架构模式，既包含一些传统模式（e.g.分层、C/S、MVC、事件驱动），也包含一些新兴玩法（e.g.云原生、微服务、Serverless）。不同模式有不同的实用场景，没有哪一种模式能通杀所有需要。成熟的架构师应该像一个沉着到冒得感情的杀手，永远只会主观地评估和抉择最适宜当下的解决伎俩，即便那么做会显得简略乏味；相同，不成熟的架构师，二心总想着搞事件（e.g.强行套用微服务架构），而不是真正搞定问题。
有了良好的架构设计，万里长征之路就曾经走了一大半。就像是青年导演第一次遇上好剧本，心潮澎湃两眼放光，好像曾经预感了电影上映后的票房盛况。当然，剩下的一小半路，并不会如设想中那么平坦——同样的剧本，不同导演拍进去会有质一样的区别。好的“最佳导演”，即便面对不是“最佳剧本”的剧本，也有能力拍出“最佳影片”。同样，好的架构师，也应该有能力形容好一个不错的架构设计；即便做不到为精彩的内容加分，也不应该因为模式上没形容好而丢分，否则就会像高考作文丢了卷面分一样憋屈和心酸。
为什么要形容架构？让它只存在我深深的脑海里不行吗？西方人有句谚语：好忘性不如烂笔头。任何没有长久化的货色都是易失的（volatile），就跟内存一样。另一方面，就如前文所述，架构是沟通合作的根底，不通过架构形容（ArchitectureDescription）积淀下来让所有我的项目干系人都能看到，那就失去了沟通和流传的惟一载体。
依据集体察看，大家对“架构须要形容”这一点都没异议，所以绝大部分我的项目都或多或少会产出一些有模有样的架构形容文档。但“有架构形容”和“有好的架构形容”，这之间的鸿沟是微小的，甚至比“没有”和“有”之间的差异还大。如果你也跟我一样，饱经沧桑阅尽有数架构文档，曾拍手叫好心怀感谢过，也曾拍着大腿愤恨不已过，应该也能感同身受。
对于同一件事物，作家会抉择用文字来叙述，而画家却会用图画。只管两者想要传播的信息是统一的，但形容形式的不同也会带来成果上的微小差别。架构形容也分文字（Text）和图（Diagram）两种模式，两者各有千秋：
聪慧的你冷笑了一声：哼，又不是小孩子非得做选择题，难道不能够文字与图都要吗？当然能够，现实的架构形容肯定是图文并茂的。但事实世界显然比现实残暴，理论软件我的项目中很难给你留足工夫先憋出一篇完满的架构文档。如果以成年人的思维去思考投入产出比（ROI），那么你肯定会优先选择画图。
麻利软件开发宣言中提到：相比详尽的文档，可运作的软件更加重要（Workingsoftwareovercomprehensivedocumentation）。这么说当然不代表就不必写文档了，只是提倡没必要写过于详尽的文档。为什么？因为详尽的文档须要消耗大量的编写和保护老本，不合乎麻利开发的小步迭代和疾速响应变动等准则。
那么，在现在这个全面麻利开发的时代，如何也顺应潮流更加敏捷地编写架构文档呢？ROIisyourfriend——不求多，但求精，尽量用起码的笔墨表白出最外围的内容。从内容上来说，ROI高的局部个别是偏顶层的整体架构或最外围的要害链路，这点在后文的C4模型理念中也有体现。而从模式上来说，图在文字背后具备无可比拟的表达力劣势，显然是ROI更高的抉择。
多画图是没错，但有必要专门学习吗？又不是素描彩笔水墨画，只是画一堆条条框框而已，略微有点工程常识的都能上。画的有点丑？那没关系，顶多再动用点与生俱来的艺术美感，把这几条线对对齐那几个框摆摆正，再整点五彩斑斓的背景色啥的，不就显得很业余了嘛？
所以，能画图并不代表能画好图；要想制得一手既丑陋又可读的好图，还是须要通过继续学习与刻意练习的，很难仅凭直觉和悟性就能把握其中的要害要领。此外，谬误的图往往比没有图还要蹩脚，即便你只是抱着“有图就行，差不多那个意思得了”的心态，也至多应该了解一些迷信制图的要害因素，防止给原本就曾经很简单难做的我的项目又蒙上一层含糊滤镜，甚至起到混同和误导的副作用。
探讨具体的制图办法和工具前，咱们须要先竖立清晰的制图指标。工具是人类进化的阶梯，但如果了解和利用不当，则很容易反过来被工具所限度甚至奴役，忘了最后创造和应用工具的初心。对于架构制图而言，曾经有那么多不拘一格的办法与工具，应用它们的初心是什么呢？我认为实质上都是想把制图这个过程从一门自在的手艺变成一项迷信的工程：零碎、谨严、残缺、标准化，同时能做到可反复、可继续和高效。
P.S：过后做PPT太赶，所以从这个章节开始的配图，只能被迫走极简路线了，还请见谅。。。
通过后面几个章节的“简短”铺垫，置信大家对架构制图的背景常识都曾经产生了足够的认知。本章节将会具体列举和形容一些典型的架构制图办法与工具，其中有常见的也有常见的，重点是心愿能通过各种办法的横向比照，加深大家对制图办法实质的了解。
UML应该是大部分人最相熟的制图办法了，最新的UML2.x版本由以下两大类图组成：
作为通用的“对立建模语言”，UML总共蕴含了14种不同类型的图，能够全面笼罩软件设计畛域各种制图需要，当然也包含了架构制图。同时，也正是因为UML把本人当成了一门语言，因而其各种记号（notion）和语义（sematics）都有十分谨严的定义，不会呈现含糊或者歧义问题。最初，UML通过几十年的倒退和推广，也早已成为世界范畴内宽泛应用的规范标准，其所带来的的隐性价值就是：在团队内应用UML进行沟通的老本是比拟低的，因为能够假设绝大部分技术人员都能了解UML的含意和用法。
然而，UML也非万能（尽管历史上曾一度把它当成软件设计的银弹），它最被人诟病的毛病就是过于简单。这也不能怪UML，毕竟它就是要被设计为足够通用、谨严和弱小的，这些指标都与“简略”南辕北辙，并让它一步步演变到了明天这个简单刻板的硕大无朋模样。尽管下面咱们自信地假设了技术人员大多都懂UML，但这个“懂”如果带上一个水平量词，我感觉均匀能到20%就不错了——绝大部分也就能意识几个常见的类图、时序图，预计都很难精确说出类图中各种箭头的含意。
无论怎么说，UML仍然应该是每个程序员的制图工具箱中最罕用和必备的工具之一。当然，也不应该是惟一，因为上面也还有些不能错过的好货色。
“4+1”是啥？不晓得没关系，听过“6+1”吗？对，就是那个小时候常看的“十分6+1”节目。它跟“4+1”之间的关系，就跟它们与邵佳一、张嘉译和沈佳宜之间的关系一样，除了赶巧共用了同一个后缀发音以外，八竿子打不着。
C4模型是一种“形象优先”（abstraction-first）的架构制图办法，它也是受后面的UML和“4+1”视图模型所启发，但相对而言要更加简略和轻量，只蕴含大量的一组形象和图表，很易于学习和应用。
C4模型通过容器、组件、代码以及人这几个形象来形容一个软件系统的动态构造，它的核心理念是心愿像GoogleMap一样，通过不同档次的细节，为代码建设一种能够放大和放大的导览图。它最要害的思维就是自顶向下对系统的动态构造进行逐级拆分，顺次形容各层次对象的职责、关系和内部依赖。除了外围的层次化动态构造视图，它还能够蕴含动静视图、部署视图等补充视图。
下面的左图展现了C4模型中各层次形象之间的映射关系：1个软件系统由1~N个容器组成，1个容器由1~N个组件组成，1个组件由1~N个代码构造组成。右图是以简略的SpringPetClinic我的项目为例，演示了一个实在软件系统在C4模型下的层次结构：最上层就是PetClinic软件系统，它能够拆分为数据库、Web利用等几个容器；Web利用又能够进一步拆分出ClinicService这个组件，而这个组件下又蕴含了ClinicService接口类、ClinicServiceImple实现类、Owner/Pet/Visit等畛域对象类。
应用C4模型进行架构制图，实质上就是对上述几种形象进行可视化。具体的做法是顺次建设如下几类从粗到细的结构图：Context、Container、Component和Code（可选），这也是C4模型名称的来历。
零碎上下文图作为第一级（L1），提供了一个展现零碎全貌的顶层大图（bigpicture）视角，包含最核心的软件系统、周边的用户以及其余有交互的零碎。其中最要害的两个概念别离是：
在绘制零碎上下文图时，不须要关怀诸如技术栈、协定等任何底层细节。这类图的受众是最广的，因为任何人都能够了解并从中获取到足够的信息，包含技术人员和非技术人员，也包含团队内成员和团队外成员。
通过L1的上下文图了解了零碎在整个IT环境中的定位后，下一步就是把零碎这个框框放大，具体看下其中蕴含了哪些“容器”（Container，留神不要跟Docker容器搞混了噢！）。C4模型中的容器是指单个利用或数据存储，通常能够独立部署和运行（有独立的过程空间，通过IPC机制相互通信），例如：SpringBoot微服务、ReactSPA、挪动App、数据库、Serverlss函数、Shell脚本。
L2的容器图不仅展现了零碎的进一步职责拆分，还包含了次要的技术选型、容器之间的通信形式等要害架构信息。这类图能够面向全副的技术人员，既包含架构师、开发者，也包含运维人员、技术支持等。
与容器图相似，L3的组件图也不只蕴含了容器的组件划分，还包含各个组件的职责定义、技术与实现细节等。随着档次的下沉和细节的增多，组件图的受众范畴进一步缩窄，个别只实用于软件架构师和开发者（其余角色没必要了解，个别也了解不了）。
再持续对组件进行放大，所能看到的最底层和细节的信息，就是L4的代码（Code）了。当然，这里所谓的“代码”还是以图的模式（e.g.UML类图、数据库E/R图）展现类或文件粒度的代码构造，并不是真正的代码自身。即便如此，代码图在99%的架构形容场景下也仍然过于详尽，一方面数量宏大，绘制老本很高；另一方面易于变动，保护老本也十分高。因而，个别只有十分重要和简单的组件才须要用到这一层级进行形容。如果的确须要绘制，也应该优先思考自动化的形式，比方很多IDE就反对主动生成UML类图。
除了上述各个档次的动态结构图，C4模型还提出了一系列的补充图（Supplementarydiagrams），包含：
联合了这些补充图后的C4模型，才是能够全面与平面地形容出软件架构方方面面的齐全体架构制图办法。
平凡的思维都是类似的，arc42也不例外。上方左图的右侧局部，概括了arc42模板中与制图相干的几个外围章节，别离是：
因而，实质上arc42中提倡的制图办法与C4模型是等价和兼容的，齐全能够配合应用：以arc42作为架构文档框架，其中的架构制图采纳更具体的C4模型。这也是目前咱们我的项目中理论采纳的办法。
除了上述几种办法以外，在软件行业蓬勃发展的数十年间也涌现出过很多其余的优良架构制图办法，其中既包含一些通用办法，如：SysML、AADL、ArchiMate，也包含一些畛域特定办法，比方在企业中后盾业务建模场景中很常见的BPMN。再具体地开展形容各个办法，显然会让本文又臭又长（尽管写到这里时仿佛就曾经注定了），有趣味的读者能够自行检索和摸索。
到这里为止，本章节介绍的都是架构制图的各种办法；而理论从办法到落地的过程中，还有一个绕不开的环节：选用什么样的工具去制图？总不能真的跟写工程制图作业一样用纸和笔吧？作为数字化改革的推动者，程序员们当然要全面拥抱数字化工具；大家日常工作中必然也曾经积攒了很多棘手的画图工具，因而这里我只举荐两个本人用得比拟多的：
古有云：授人以鱼，不如授人以渔。推而广之：授人以办法，也不如授人以方法论。什么是方法论？尽管这个词在公司里曾经用烂了，但的确有它的价值和意义：方法论（methodology）是对办法的更高维度形象，由它能够推导出解决问题的具体办法（method）。了解了方法论，能力死记硬背，把握解决问题的实质要点；你也不会再受限于繁多的具体方法，因为应用任何办法都能疾速上手和灵活运用，并失去差不多的等同成果。
因而，本文最初这一章节将对各种架构制图办法进行演绎总结，并尝试提炼出一个通用的架构制图方法论，冀望能帮忙大家更好地了解架构制图背地的原理和思维。即使当初所熟知的各种办法与工具终会过期，也仍然能风轻云淡地对待它们的新老交替：过来是UML，当初是C4，将来是什么呢？这并不要害，因为即便办法过期了，背地的方法论也不会过期。
所以，那些茫茫多的办法背地，到底是什么样的外围方法论在撑持着呢？通过作者醉生梦死左思右想了近15秒钟，终于总结出了如下这套经典方法论（p.s：就是凑数的，不要太当真~）。因为其中蕴含了5个环环相扣的要点，咱们权且称它为：五环实践。
架构制图的第一要点，是须要先深刻理解制图指标。正所谓“以始为终”，有了指标咱们能力清晰地前行；否则漫无目的地乱窜，往往会多走不少弯路，甚至背道而驰。架构制图的指标是什么？其实前文曾经提到过很多，这里再简略总结下：
架构制图的第三要点，是正当使用层次化（hierarchical）的套路，自顶向下逐层形容。无论是C4模型还是arc42模板，背地都粗浅使用并显著强调了这一点。为什么肯定要这么做？其中蕴含了两个普适的原理：
架构制图的第四要点，是在向传统的工程制图方法论致敬：应用多种架构视图来形容你的架构。在工程制图的世界里，任何平面的制品，大到机床小到整机，都至多须要通过三种视图（主视图、俯视图、左视图）来形容。作为事实世界的映射，软件系统也是多维和平面的，只用繁多视图不可能笼罩所有要害的架构信息；即便强行把这些信息都塞在一张图里，那也肯定会简单到让人无奈了解。
架构制图的第五要点，其实只是一句正确的废话：遵循标准和最佳实际。这一点曾经不限于架构制图，而是回升到了工程实际畛域的通用方法论层面。正如后面章节所说，“学习架构制图的指标，就是要把它从一门手艺变成一项工程”，因而架构制图的“施工”过程也理所应当合乎工程化思维：
国内上对架构形容其实建设了专门的规范（ISO/IEC/IEEE42010:2011），其中的很多概念词汇在本文中都有提到（e.g.Stakeholder、Concern、View、Viewpoint），有趣味的同学能够进一步钻研下。
如果你从头到尾耐着性子看到了这里，那么不必狐疑，你肯定就是咱们团队要找的那种能成大事儿的人：
关于linux:Linux服务器上防火墙firewall的配置
关于php:Hyperf-发布-v2013-版本企业级的-PHP-微服务云原生协程框架