「架构实战营」课程结束了。回顾整个学习过程，有前半学期的新奇与充满斗志，也有后半学期因为个人原因而导致的跟课的艰辛。然而正因如此，才能侧面证明「架构实战营」的内容之详实、知识结构难度之大、知识面涵盖之广。华仔老师毫无保留地把他数十年的从业经验以结构化、梯度化、实践化的形式毫无保留地教授给所有的同学，作为学员我个人感觉受益匪浅、获益良多。学习期间，授课视频的观看为第一要务，常常因为内容太过丰富，经常性的需要多次回看和整理。与老师、同学的交流也是学习中不可或缺的环节。完成的每一次作业表面上看着是几页报告、若干页 PPT，然而其背后的整个架构思维模式、方法论、实现方式，甚至过程中的挣扎都无不体现了课程的难度以及自身在从一个资深工程师向软件架构师转型过程中的困难。个人从事软件开发已经有六年时间了，我很幸运地认为自己赶上了一个好时代：人工智能、容器技术、分布式计算与存储。如此多的优秀技术以前所未有、无法想象的方式，通过各个云计算平台以非常直观、简易的方式提供给开发者使用。然而这个时代同样给我们带来了困惑：面对如此多的技术，自己真正喜欢的方向在哪里？如何在有限的精力和时间下提升和管理自己？「架构实战营」给了我答案。

一、架构师扎实的技术基础

「架构实战营」绝对不是一个面向新人的课程，它对于学员的基本技术基础要求很高。课程中出现的各种术语、行业知识点都是需要我们默认了解的。很庆幸自己的合适的时间发现了这门课程。同时华仔老师多次强调，过硬的技术基础是必要的，否则未来对架构的设计是很难准确到点、直击问题的。

• 对于自己熟悉的系统一定要更加理解透彻，把自己的经验积累起来作为未来做架构时的参考。

• 对于自己不熟悉的系统，去学习和了解它的方式也非常重要，后面会详细总结。对它们的了解不能只浮于表面，否则未来做架构的时候何来的自信去把这些系统应用在一个整体架构之中。

二、面向复杂度的架构设计方法论

架构设计的本质是降低软件系统的复杂度，增加系统的性能、可维护性、可观测性。架构师需要负责整个架构设计的前中后期：

• 前期：澄清不确定性（利益干系人分析+诉求优先级排序）、复杂度分析。

• 中期：可选技术选型、备选方案的设计与环评、确定最终架构。

• 后期：总体架构设计与详细架构设计、架构质量设计与演进规则。

在上述的每一个时期，架构设计三原则 与 架构方案 4R 都贯穿始终。

• 架构设计三原则：

• 合适原则 - 合适优于业界领先，防止过度设计。

• 简单原则 - 简单优于复杂，过度复杂导致系统可靠性降低。Simplicity is complicated.

• 演化原则 - 演化优于一步到位，世界上唯一不变的是变化本身。

• 架构方案 4R：Rank、Role、Rule、Relation 在架构设计的过程中需要随时存在于心，才能下笔有神。

三、架构师能力的培养 - 持续成长为优秀的架构师

典型技术方案的学习、总结、更新

对业界的主流、典型技术方案要有持续的热情去学习和更新自己的知识。

• 典型系统：负载均衡、分布式缓存、消息队列、NoSQL 数据库、单机式与分布式 SQL 数据库。

• 数据系统：大数据引擎 Hadoop、Spark、Flink 等。OLAP 系统 Doris、ClickHouse 等。

• 云服务：不同的云服务商提供服务的对比与优劣势。

上述技术都需要架构师对其使用、内部原理、适用场景、优劣势有足够的了解。同时，架构师也需要不断地更新自己（哪怕是对同一个技术）的知识，以避免自己陷入选型时的误区。例如很多人提到 MongoDB 的第一反应是它是一款 NoSQL，它不能做 JOIN 操作，也不支持事务。然而实际上 "不能做 JOIN 操作" 就是一个典型的误区，MongoDB 在之前的版本就支持了 $lookup 操作，其作用等同于一个 LEFT OUTER JOIN。同样的，MongoDB 也在其 4.0 版本开始支持了 Replica Set 级别的事务，并在 4.2 版本开始支持了 Sharded Cluster 级别的事务。并且从 MongoDB 的发展来看，它实际上是功能最接近 SQL 的 NoSQL 数据库，只是它的确不兼容 SQL 协议而已。作为优秀的架构师，我们需要不断地学习、总结、更新自己对技术方案的认知以避免此类误区，从而更好地设计架构方案。

持续学习

上文有提到，在架构设计中我们总是会遇到自己相对不熟悉的系统。我们应该持续地运用架构师思维去对此类系统进行学习，以达到我们能够利用这些知识来做出合理的架构决定。例如在分布式 SQL 数据库的选型中，我们因为一些因素需要考虑 OceanBase 但是我们对它并不熟悉。相比起直接去它的上百万行源码中畅游，我们应该调整思维模式，积极地寻找资源去学习和探索 OceanBase 的整体架构、性能基准测试的数据等。并在此基础上决定要不要对其进行 Prove-of-Concept 概念验证，以及后续可能的应用到自己的架构设计当中。如此以来我们能避免架构设计中对于可选技术认知的两个极端：

• 避免对可选技术的肤浅了解、避免数据都源自道听途说。

• 在有限的时间、精力、项目时间线的压力下，避免对可选技术底层细节的过度深究。

（如果今后长期使用此项技术，则必须在合适的时机继续深入下去。）

这样我们既能满足对长期使用的技术的深度，也能保证未来架构设计中对其他系统知识面的广度。

业务领域的知识

架构师需要对业务有深刻的认知以此来做出合理的架构设计。例如我们在第一次作业中需要设计一个支持千人的学生管理系统。在这种情况下我们分析实际的流量、业务需求，同时结合对利益干系人以及成本的分析来避免典型的过度设计、复杂设计，并依然留有演进空间。同样的，假设我们需要设计支付宝级别的系统，它肯定远远复杂于千人学生管理系统。但我们的 面向复杂度的架构设计 + 典型技术选型 + 业务领域 等综合起来的方法论、知识、实践，都能够帮助我们以统一、完整的体系去从容应对这样的设计要求。

架构的稳定

在团队中不是每一个人都会对架构有非常清晰和全面的认知，我们需要许多成员对具体细节的把控和负责。即便对架构有非常清晰和全面的认知，我们也需要保证架构的整体稳定性、可观测性、可维护性、可测试性，以及安全性。通过收集内外部用户、运维团队的反馈，不断对系统性能、用户体验进行持续优化，保证系统稳定、高效、安全地运行。

架构师的责任心

一个合格的软件架构设计师必须具备长期一线工程实践经验的积累。我们要抓住每一个项目实战机会，在其中实践并检验每次架构设计的效果并及时复盘。架构师有责任和义务全程参与架构设计的前中后期三个阶段，成为业务和技术之间坚实的桥梁。时时刻刻用确定性思维去判断，用创造性思维去拆解，用系统性思维去取舍。

四、结语与感谢

通过「架构实战营」的学习，我自认为自己已经走在了从资深软件工程师向软件架构师转型的路上。在今后的工作中一定能有更多的机会，同时也会有更多的收获。

在此衷心地感谢华仔老师、依依班班、佳丽班班、各位助教老师、客座老师的辛劳付出和帮助！祝愿所有老师和同学工作顺利、万事如意！祝愿极客时间越办越好，给我们中国以及全世界的技术社区带来越来越多的与「架构实战营」一样优秀的精品课程！

「架构实战营」第 0 期学员 - 晖