资料来源666java站，极客大学郭东白、李运华主讲

第0课、开营沟通，架构及架构师行业了解

实战营内容核心，面向复杂度架构设计的方法论

指导思想（面向复杂度）
设计原则（三原则，合适、简单、演进）
成熟模式（高性能、高可用、可扩展架构）
实施流程（架构设计四步骤）

学习的目标：

什么是架构，为什么做架构
有哪些可选的架构，优缺点是什么
架构设计思路是什么？

0.1、聊聊架构师行业

主讲：郭东白

架构师是什么？

架构师是负责架构设计，面向多条产品线的架构设计，非单一领域专家，需要多视角，如果计划很明确，三个月一迭代，也很高效，那么不是很需要架构师。
但架构能力是很多人都需要的。架构师更多的是横线关注的，不一定能力最强、工资最高。

架构师的能力：为其他工种做合理补位。。。

研发能力，写代码，普通能力
横向问题，规模化、成本、质量、扩展性、维护性
长期思考，
技术衔接，前后端，技术和业务，开源和自建或购买等等
技术视野，领域拓展，规模跨度，时间跨度
项目管理
沟通交流

优秀的架构师的成长

顶层设计，复杂组织中当整体设计缺乏，团队合作低效、未来发展模糊的情况下，创作独特价值，让组织更流畅，整体设计更好

什么是优秀的架构

经得起时间考验的整体设计，且保障其交付。常规架构随着时间在衰减，维持架构迭代，持续注入能量，这是一个发现和学习过程。

架构师的工作是什么？

第一步，整体设计、跨度设计
第二步，在多个领域间为组织创作更高效率研发环境，如研发规范标准、安全规范、统一工具层、平台层、中台层。
第三步，在多业务领域中为企业布局，未来靠什么赚钱

简单地说，项目级，系统设计，组织设计从小到大。

优秀架构师的素质：

1、有眼光，深度业务理解看到好的业务机会，
2、擅思考，足够技术视野能找到正确的技术和组织设计，这两个都是独立思考
3、品质，有良知，为人正直，选择做正确的事，
4、能感召，引导组织做出正确的决策，他是决策建议者

架构师需要什么样的成长环境

需要友善的环境，信任、授权、时间、资源、正确的文化（包容、求真），宽松交流环境，愿意理性思考、愿意寻找先进模式、发言能被倾听，而不是只要找执行的人员。

架构师行业技巧：

通常一家没有整体设计过的公司，是架构师比较容易进去拿到大额薪水的机会。
大公司做深度、小公司做广度，不要逆向而为
架构师对软件、领域、业务都是一对多的关系，这是创造价值的地方。
敲门砖，如项目攻关，解决别人解决不了的问题，迎来信任、有跨度的工作。获取口碑、获取机会
深度和广度：至少具备一个极强深度是敲门砖，能获取额外机会就够了，可以做实战了，获取更多经验。

0.2、架构学习的正确姿势

主讲：李运华

对架构的误解：

1、数据结构和算法是架构设计的关键（不只是数据结构和算法）
2、源码面前无秘密，架构设计也不例外（架构设计阶段不涉及代码）
3、架构设计需要展现实力，不能太简单（不一定要高大上）
4、阿里腾讯怎么做，应该直接参考（大公司不一定就是好的）

架构的设计过程： 参考飞鸽消息队列

业务背景==》方案研究==》方案汇报==》力排众议==》架构讨论==》架构定稿

面向过程和面向对象的差异

面向过程：包含流程和数据，从输入数据到各环节处理产生中间数据，最后输出结果数据。

面向对象：包含对象和交互，从输入数据到各环节交互（消息）产生新对象，最后输出结果数据。

程序思维 VS 架构思维

程序思维：程序=翻译+逻辑+实现

架构思维：架构=判断+取舍+创新

小结

只有理论，那就是纸上谈兵，不会举一反三
架构设计的本质是【判断+取舍】，程序设计的本质是“逻辑+实现”

实战营和从零开始学架构的共同和不同点，核心面向复杂项目的架构设计方法论，这里更偏实战

实战指的是：结合业务做架构设计，写文档、ppt，架构图、架构文档（优缺点、对比、选型）

软件架构设计需要熟悉各种软件工具和产品，如kafka、zookeeper、redis，不然只能做领域架构设计、业务架构设计，或解决方案架构设计，把业务模型模型画出来

代码能力不要很高，但还是要一直写代码；比如redis、kafka如何结合业务使用，但源码设计细节、api就不熟悉了

架构设计的深度、广度，中间件要求深，业务架构设计要很广。

第1课、什么是面向复杂度的架构设计

了解常见的架构设计方法论

理解面向复杂度架构设计

1.1、什么是架构，你理解对了么

方法论的意义

理想的编程领域	实际的编程领域
面向对象、面向过程	面向Github、面向SOF

理想的架构领域	实际的架构领域
面向模式、面向风险、面向复杂度	面向大厂、面向老板、面向新技术

常见架构设计方法论

面向模式
- 《面向模式的软件架构》POSA，5卷，5个作者
  - 核心思想是应用经过验证的成熟架构模式，如MVC，Reactor等。
  - 问题过于抽象、复杂、多个不同国家作者，前后风格差异大
面向风险
- 《恰如其分的软件架构》包含两部分，George Fairbanks
  - 风险驱动的架构设计方法论，核心思想是根据风险大小来设计软件架构，但风险是不好测量和预判的。
  - 业务架构建模方法，本质是面向对象设计的建模过程
DDD
- 《领域驱动设计》，Eric Vans，该领域之父，世界杰出软件建模专家
  - 核心思想：通过领域建模来完成架构设计和代码设计
  - 问题1：可扩展的架构设计技巧，不是方法论
  - 问题2：ddd兼顾架构设计和方案设计，容易搞混
  - 问题3：ddd、敏捷架构不关注存储和计算，只关注业务
- 整洁架构、简洁架构

面向复杂度（方法论）
- 本质：架构设计是为了降低软件系统的复杂度
- 思路：通过分析系统需求找到系统复杂的地方，然后设计方案
- 模式：复杂度来源：高性能、高可用、可扩展、安全、成本……
- 套路：分库分表、缓存、集群、分片、微服务、DDD、异地多活……

为什么做架构设计

因为架构重要，所以要做架构设计
为了提升开发效率，为了促进业务发展
公司流程要求系统开发过程必须要有架构设计
为了高性能、高扩展、高可用，所以要做架构设计

软件架构诞生的背景：

核心原因：软件系统规模增长

核心特点：数据结构和算法不再是主要问题，整个系统结构成为首要问题。

架构设计环

1.2、如何绘制架构图

常见架构图的分类

4+1架构视图

1995年，Philippe Kruchten在《IEEE Software》上发飙《The 4+1 View Model Architecture》，包括：

逻辑视图：系统提供给用户的功能，对应UML的class和state diagrams
处理视图：系统的处理过程，对应uml的sequence和activity diagrams
开发视图：程序员角度看系统的逻辑组成，对应uml的package diagrams
物理视图：系统工程师角度看系统的物理组成，对应uml的deployment diagrams
场景视图：中心位置，用户角度看系统需要实现的需求，对应uml的use case diagrams

使用很少主要在于逻辑视图、处理视图、开发视图比较容易混淆，还有就是比较丑，毕竟高度抽象。

大厂常见的架构图介绍和画法

系统
- 业务架构（按业务划分）
- 领域架构（按领域划分）
  - 手机客户端
    - 客户端架构（按模块划分）
  - PC前端
    - 200-后端架构（按模块划分）
  - 服务后端
    - 系统架构（按模块划分）
    - 应用架构（按应用划分）
    - 部署架构（按组件划分）