架构学习总结

架构是什么？有一句名言说的好：One may know what something is by knowing what it is not. 意思是，要想知道一个东西是什么，首先要知道它不是什么。课程的开篇就用类似的方式回答了这个问题：要了解架构是什么，就要了解架构不是什么。架构是系统吗？是的，软件系统也是系统，自然符合一般系统论。架构是框架吗？并不是，框架是实际的产品。系统从逻辑角度拆分得到的是模块，而从物理角度拆分则得到组件。

从一般系统论的高度来看，软件架构，正如所有其他人类文化中以“系统”冠之的东西一样，都具有整体性、关联性、层次性、统一性的特征。实际上这也回答了软件架构的几个重要问题：软件架构是分层的、角色之间是有关联的、系统功能大于角色功能之和。

架构图的画法是比较实用的内容。国外的 4+1 在国内水土不服，注定被丢尽历史的垃圾堆；新兴的 C4 有待时间的检验（个人认为 C4 有过誉之嫌，前两 C 有点意义，后两 C 略显违和），而被国内业界广泛接受的架构图实际上只有如下几种：业务架构，用于汇报领导，产品规划；技术架构，架构的核心，提到架构默认即技术架构；应用架构；部署架构等。此外，前端和客户端领域也有他们各自的架构，然而这不属于我们重点关注的东西。

了解架构和架构的分类之后，便引出了架构设计的核心主题：面向复杂度。架构设计的本质即降低系统的复杂度，或者说管控复杂度。具体来讲，复杂度分为业务复杂度和技术复杂度。评估一个架构优劣的标准，或者说架构设计需要考虑指标有五项：高性能、高可用、可伸缩、可扩展、安全、可观测、可测试、可维护。其中，高性能实际上和可伸缩是紧密联系在一起的，可观测性通常体现为运维平台，而 DevOps 平台侧重于可测试性和可维护性。在具体设计时，通常还会从存储和计算两个维度，有侧重的进一步按几个要素设计。

对于分布式软件架构的高性能设计，最基本的套路有两个：任务分解和任务分配。任务分解可以看作业务拆分，职责分离；任务分配则关系到可伸缩性。单机高性能的实现则要考虑进程、网络、缓存和存储的优化和设计。

高可用设计的基本思想是冗余。相比计算高可用，存储高可用的设计实现更为复杂，因为存储是有状态的。

可扩展是系统适应变化的能力，包含可理解和可复用两个部分。在具体设计手段上体现为拆分和封装。关于封装，有一个著名的原则：一写二抄三封装。这也应了一句箴言：过早的优化是万恶之源。早期 DRY 是不利于架构演进的。

（未完待续。。。）