通过这几个月在架构实战营的学习自己收获了不少的架构方面的知识，感谢李老师、助教以及班班的辛勤付出，没有你们认真负责的态度，估计我也不会坚持学到最后。下面就学习到的一些重点做些总结：

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

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

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

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

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

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

• 架构设计三原则：

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

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

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

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

二、架构师能力的培养

1、架构的稳定

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

2、业务领域的知识

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

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

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

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

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

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

上述技术都需要架构师对其使用、内部原理、适用场景、优劣势有足够的了解。同时，架构师也需要不断地更新自己（哪怕是对同一个技术）的知识，以避免自己陷入选型时的误区。作为优秀的架构师，我们需要不断地学习、总结、更新自己对技术方案的认知以避免此类误区，从而更好地设计架构方案。

4、以架构师思维式的学习

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

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

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

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

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

三、结语与感谢

• 接纳自己的不足：架构师的成长需要时间与持续的努力，架构训练营是一个很好的开始，但也只能算作起点；

• 接纳不完美：通过各个模块作业的练习发现要做到完美是不可能的。自己不应该抱有”写不好就不写“这样的心态。把自己能做到的努力达成，接下来的时间去做查漏补缺，不断磨练自己。

• 方法论很重要，练习更重要。

• 持续很关键，要有自己的节奏。

在此衷心地感谢华仔老师、佳丽班班、依依班班、各位助教老师、客座老师的辛劳付出和帮助！祝愿所有老师们和同学们工作顺利、万事如意！祝愿极客时间越办越好！