架构方法、模型、范式、治理

从架构方法、模型、范式、治理等四个方面介绍架构的概念和方法论、典型业务场景下的架构范式、不同架构的治理特点这3个方面的内容

通过如上的层层架构拆分，就可将一个复杂结构的软件系统拆分成一堆模块或组件，这就是软件系统的原子构件。但是，如果拆分出来的这些原子构件相互耦合在一起，关系混淆不清，不仅不能降低复杂度，反而会升高复杂度，为后续的开发带来麻烦。因此，架构拆分也需要遵循一定的规范，通常是按照架构分层来进行。前面所讨论的一级子系统，二级子系统，服务等概念，本质上就是架构分层。只有在架构分层框架下，有序的进行架构拆分，才能够有效的降低系统的空间结构复杂度。
2. 时间演变复杂度
软件架构在时间维度上也同样存在一系列的复杂度挑战。主要源于业务不断演变所带来的可扩展性和可维护性的要求。业务不断迭代和进化，导致软件系统需要不断的添加或修改功能，必然要求软件架构具有一定的可扩展性，能够灵活、可靠、低成本地支持系统开发。软件系统要长期在线上运行，需要稳定可靠的进行迭代发布、容量管控、限流降级等运维操作，在架构上也必须具有可维护性。另外，大家通常会忽视软件系统的可观察性。“只有看得到，才能管得到”，软件系统的可观察性是保证系统可靠运行的重要因素，因此必须将业务、性能、异常指标的监控度量等能力纳入架构设计中。
不管是在应对空间结构复杂度的架构拆分和架构分层上，还是应对时间演变复杂度的可扩展性、可维护性、可观察性的设计上， 都要综合考虑功能、性能、安全及成本这四大因素。任何一个系统的设计都有一定的成本约束，人力资源是有限的，资金投入也是有限的，上线时间压力也是存在的，我们不能无限制的投入资源去设计一个十全十美的软件系统。因此在架构设计上要把握一个度，要在功能够用、性能达标、安全可靠和成本可控之间达成妥协。
综上所述，软件架构需要在空间结构复杂度和时间演变复杂度这两个维度上，综合考虑功能、性能、安全、成本这四个因素，平衡各方诉求进行体系化的设计。
以上，就是做软件架构的通用思考维度。