1.1 什么是架构

判断题

1，系统能力等于多个个体能力之和

[GZ]: 错误。我认为应该等于多个个体的最差个体的能力，类似于木桶理论。比如一个消息生产消费的架构，消息队列的消息吞吐能力是很高的，但是如果消费端处理这些消息的能力不足，那么实际上这个系统的整体能力也还是不尽如人意。

2，从逻辑角度拆分系统可以得到模块

[GZ]: 对。模块是一套一致而互相有紧密关连的软件组织，正是由逻辑来区分的。

3，MySQL 可以是系统的一个模块，也可以是系统的一个组件

[GZ]: 错误。模块是逻辑划分的，比如学生管理系统，可以分为学生模块，课程模块等，而每个模块都应该包含 Mysql。而从组件的角度来说，Mysql 服务器是单独存在的一个服务器，可以作为一个独立的组件。

4，软件架构和建筑架构没什么区别

[GZ]: 错误。建筑架构是一个静态的架构，建筑建完了就完了。而软件架构则是一个动态的架构，随着软件的复杂度的增加，软件的架构也会随之变化。

思考题

对比 4R 架构定义和维基百科架构的定义，主要差别是什么？

[GZ]: 我认为维基百科的架构定义很简单，字面意义上的定义。而 4R 的架构定义则指出了架构的 4 个关键的方面，具有一定的指导性，可以通过这 4 个 R 更好的理解客户的需求，并做出更符合需求的架构。

1.2 如何画出优秀的架构图

判断题

1，4+1 视图是业界公认的规范，所以我们必须采用它来表示架构

[GZ] 错误。首先 4+1 视图是 95 年提出的，那个时候的系统和现在的系统已经大不相同，所以并不适合现在系统。其次 4+1 视图强绑定 UML，而 UML 图画架构图会存在一些问题。再次 4+1 视图太过复杂，视图间也容易混淆。

2，UML 可以用来画架构图

[GZ] 错误。太丑！

3，某些场景下，应用架构就是系统架构

[GZ]: 对。我认为在一些简单的系统里，应用和模块可以一致，因此应用架构和系统架构可以是相同的。

4，给高 P 汇报业务的时候优先推荐用系统架构

[GZ]: 错误。应该使用业务架构图。业务架构图是按业务来区分的，比如钱包业务、第三方业务等，主要说明系统能给客户提供什么业务。而系统架构图是后端的逻辑架构，用于整体架构设计和架构培训。

思考题

为什么不能用一种图来展现软件系统的架构？

软件系统的架构设计到方方面面，给不同的人看需要展示不同的架构。比如给领导或者客户的高层看，那么展示业务架构图，告诉领导或者客户的高层，我们的系统能提供什么服务。而给团队的开发人员看，则可以展示系统架构图，告诉开发人员我们的系统长啥样，模块之间的关系如何。给运维和交付人员看，则可以展示部署架构图，告诉他们我们的系统如何部署，哪些应用部署在哪些服务器上等。

面向复杂度架构设计

判断题

1，架构设计是为了满足高性能、高可用、可扩展的三高要求。

[GZ]: 错误。不一定，选择什么架构取决于系统的需要，比如一个学生管理系统，可能并不需要高可用，那么就不需要在架构里考虑高可用的需求。总之架构设计是为了更好的实现系统的需求，而不是三高的要求。

2，领域驱动设计是系统的架构方法论。

[GZ]: 对。但是 DDD 并不是唯一的系统架构方法论，系统架构方法论还包括面向风险的，和面向复杂度的架构设计等。

3，DDD 只适合可扩展的业务架构设计。

[GZ]：错误。只字有点太绝对。

4，软件架构也要解决数据结构和算法带来的复杂度。

[GZ]：错误。数据结构和算法的复杂度应该是在具体实施过程中应该考虑的。

思考题

为什么软件架构最先是在 Rational 和 Microsoft 这类大公司兴起的？

[GZ]：我觉得一，大厂有软件架构的需求，大厂的软件架构一般会比较复杂一些，因此他们有这方面的需求。二，大厂有软件架构的实力，大厂的工程师一般能力比较突出，善于总结，且有丰富的架构经验。因此软件架构最先是在这些大厂兴起的。

1.4 如何做好架构设计

思考题

1，如果团队具备足够的技术实力和人力，应该尽量追求架构先进性。

[GZ]: 错误。架构的制定需要遵循客户的实际需求和公司的战略。一味追求先进性，可能会造成浪费和增加系统的复杂性。

2，创业团队需求变化快，架构设计的时候目光需要放长远。

[GZ]: 错误。架构的制定需要遵循客户的实际需求和公司的战略。一味放长远，可能会造成浪费和增加系统的复杂性。

3，架构设计团队人数多一些比较好，可以集思广益。

[GZ]: 错误。可以集思广益，但并不意味着人越多越好，人越多反而不好协调。

4，小团队尽量采用简单的架构来实现。

[GZ]: 错误。架构还是取决于客户的需求，不能一味简单而满足不了客户的需求。

5，架构方案的质量取决于最差的质量属性。

[GZ]：对。我认为这句话是对的，系统的短板或者瓶颈就是取决于系统里最差质量的模块。

思考题

对于 2B 的系统，都是按照合同一次性交付，那么架构设计还会遵循“演进原则”么？

[GZ]：首先是要满足客户合同内的需求，比如支撑多少用户等。但在不太浪费的前提下可以遵循演化原则，因为一次性交付不代表未来没有机会，如果未来还有合同，那么这次的遵循的演化原则就会给下次的合同交付提供方便。

1.6 学生管理系统云平台实战

思考题

如果央行要做一个各个银行都需要接入的系统，请问你会如何考虑“演进原则”？

[GZ]：如果确定央行的这个系统各个银行都需要接入的话，那么首先需要了解这个接入系统的业务需求，然后和各大银行（或者至少和几个大银行）调研对接的需求，提炼出一些共同的需求，可以开发成一个通用的模块，同时尽量用可配置来应对不同的需求。

如果教育部要做一个学生管理云平台，请问你会如何考虑“演进原则”？

[GZ]：首先会调研一两所学校对于学生管理云平台的基本需求，尽量快速的推出一个满足基本需求的云平台，然后再根据更多其他需求，来扩展云平台。

课后作业

1，画出微信的业务架构图。

2，“学生管理系统”毕设架构设计