架构实战营模块 1 第 1 课 - 学习总结

架构定义总结：

关于 4R 架构定义，是分析和管控复杂问题的通用办法，给我们提供了结构化、系统化看事物的工具，本质是拆分、化整为零，4R 适用分析所有架构视图，只不过不同架构视图、不同的层次关注的角色和粒度不一样。

Rank，架构层次，每个架构视图都有自己的层次，或者说自己聚焦的范围。分层也是拆分问题，管控复杂度的一种方式，越复杂的问题域，越需要划分多个层次，层次越高抽象程度越高，关注的细节越少，层次越低越具体，关注更多的细节。

Role，当聚焦到一个层次后，把复杂对象拆分成多个角色（组成元素），各角色职责单一，分工明确。

Relation，角色之间的关系，复杂问题拆分成不同角色后，他们并不是孤立的，拆分前有关系，拆分后对应的关系应该仍然保留，通过拆分和重新建立关联，可以进一步厘清角色之间的关系。

Rule，角色的运行规则，系统是有生命的，跟角色相互协作，确保数据流、业务流、控制流的有流程。前面 3R 关注的静态关系，Rule 关注的是动态关系。规则一般通过时序图描述。

组件粒度可大可小，组件是物理的，组件划分目的是为了复用，微服务只一种粗粒度的业务组件。

架构分类总结：

4+1 视图，是比较通用的描述架构工具，多聚焦于单体应用，使用最多的是时序图和部署视图，在需求分析阶段会使用到场景视图。

主流的架构视图分为两条线，

1.业务线：业务架构、系统架构、组件架构（服务架构）、应用架构、部署架构、数据架构。

2.技术线：传统后端技术栈、传统前端技术栈、大数据技术栈。

各种架构视图的绘制和细化，贯穿于软件全生命周期，不断补全和细化。

业务架构：为承接战略目标落地，而规划的业务模块，是纯业务描述，属于逻辑层面、不涉及技术解决方案，一般按照业务线、业务领域划分。

系统架构：为支撑业务架构落地，而规划的系统单元，对于复杂业务域，会规划多个中心，常见的架构模式：双中台架构设计，云体系 IaaS-PaaS-SaaS。

组件架构：也称为服务架构，建立双中台，中台化项目实施是现在主流的架构模式，要求采取服务化、组件化，厚平台、薄应用策略。需要识别出业务架构和系统架构中公共的技术组件和业务组件，并持续沉淀，逐渐形成能力中心。

应用架构：结合业务架构、系统架构、服务架构整理出独立应用，应用包括：中间件、微服务技术组件、微服务应用等。如果基于 DDD 进行业务划分，领域模型可以映射为微服务应用。

部署架构：描述各应用的网络部署关系。

面向复杂度架构设计总结：

当代软件业务规模大、高性能、高并发、高可用、高安全、可靠扩展要求已成为常态，为了应对这些要求，系统设计也越来越复杂，给系统的设计、开发、运维带来诸多挑战，为了管控复杂，降低系统的复杂度，面向复杂度的架构设计提供了一张套方法论，从业务和技术两个复杂度出发，通过识别和穷举给系统带去复杂的因素，如：扩展性诉求、高性能、高并发、高可用等，然后针对性的进行架构设计，每一种复杂因素（或者说质量属性）都有成套的备选解决方案，在选择方式时，遵循架构设计三原则：合适、简单、演化，选则最佳的架构方案。

常见的套路包括：分库分区分表、缓存、集群、分片、异步消息、微服务、DDD、异地多活等。

架构设计架构设计三原则总结：通过架构三原则指导我们做更好的设计。

1.合适原则（合适优于业界领先），适合自己的才是最合适的，考虑因素包括：资源约束（人、物），时间约束（工期），业务背景（比如公司性质分为：初创公司、外包项目、大厂，项目类型分为自营、普通外包、政治性系统），总的来说就是不要打脸充胖子。

设计出来的架构要满足当时的业务需要，符合团队和技术的能力水平（合适原则）

2.简单原则（简单优于复杂），简单的东西并不是差的东西，越是复杂的系统越不可靠，难扩展和运维。解决复杂问题以拆分为主，拆分时，要注意平衡，内部复杂度和外部复杂度，拆的越细，每个个体的复杂度下降了，个体之间关系变复杂了，整体复杂度提升了。按照三个火枪手原则，三个人负责一个微服务的规模来拆分系统。在拆分时，应遵循先大粒度，再小粒度原则。

先按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化（简单原则）。

3.演进原则（演化优于一步到位），防止过度设计，在满足合适、简单的基础上，支持未来 1-2 年的演变需求，不提前为 10 年厚，或者 10 倍规模做设计。演进原则也符合分步实施，是一种规避风险的手段。再牛逼的公司，在牛逼的解决方案，也是逐步演变过来了，比如各种开源软件，比如钉钉、微信，做任何事情都要考虑“时间、成本、资源”的约束。这给我们另外的启发时，系统赶工期时，可以采取演化原则，先上最核心的业务，然后在后续运维中逐步完善。