一线架构师实践指南——阅读笔记3

一线架构师: 6个经典困惑

一线架构师经常面对的实践困惑。其中，涉及了“4个实际问题的困惑”，以及“两个职业发展的困惑”。

①将系统划分模块，如何更合理？

②大系统架构设计，如何起步？

③总觉需求很糟糕，影响了架构设计1

④非功能需求重要，但如何设计？

⑤架构新手：缺乏指导，架构设计不知所措！

⑥架构老手：缺乏总结，仍“怕”下个项目。

4个核心主张

总结一下本书的4个核心主张:

①方法体系是大趋势。

②质疑驱动的架构设计。

③多阶段方法。

④内置最佳实践的方法。

ADMEMS 方法体系: 3个阶段， 1个贯穿环节

作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。

预备架构 (Pre-architecture) 阶段(简称PA阶段)。

1. 最大误区: 架构师是技术人员不必懂需求。
2. 实践要点:摒弃“需求列表”方式，建立二维需求观。
3. 思维工具: ADMEMS矩阵等。

概念架构 (Conceptual Architecture)阶段(简称CA阶段)。

1. 最大误区:概念架构=理想设计。
2. 实践要点:重大需求塑造概念架构。
3. 思维工具:鲁棒图、目标-场景决策表等。

细化架构(Refined Architecture)阶段(简称RA阶段)。

1. 最大误区:架构=模块+接口。
2. 实践要点:贴近实践的5视图法。
3. 思维工具:包图、包-接口图、灰盒包图、序列图、目标-场景决策表等。

值得强调的是，上述3个阶段之间的先后顺序有极大的实际意义，否则就不能称其为“阶段”了:

1. 试想，在Pre-architecture阶段对需求理解不全面( 例如遗漏了需求)、不深入(例如没有发现“高性能"和“可扩展”是两个存在矛盾的质量属性),后续设计怎会合理?
2. 试想，Conceptual Architecture 阶段的概念架构设计成果没有反映系统的特点就“冲”去做Refined Architecture设计，是不是必然造成更多的设计返工?

“1个贯穿环节”，指的是对非功能目标的考虑。

概念架构的故事

架构新手和有经验架构师的区别之一，在于是否懂得，并能有效地进行概念架构设计。作为架构新手，尤其害怕碰上自己没做过的系统;系统较大时，一旦祭出“架构=模块+接口”的法宝却不太奏效，架构新手就往往乱了阵脚。相反，有经验的架构师不会一上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求，据此来设计概念架构。

另外，概念架构还是投标及售前工作的有力武器。金牌售前和普通售前的一一个重要区别是,能否清晰地讲解概念架构，并借此说明“客户关心的价值如何实现、担心的问题如何解决”。

探究:“方案”与“架构”的关系

究其原因，这是因为概念架构难以支持并行开发。要支持开发组相对独立地进行工作，须要提供指导和限制作用更明确的“规约”一级的设计。

具体而言，细化架构和概念架构之间存在如下典型差异:

1. 接口。在细化架构中，接口占据非常核心的地位，而概念架构并不关心明确的接口定义(只有抽象的组件和抽象的交互机制)。
2. 子系统。细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口;而概念架构中只有抽象的组件，这些组件没有接口，只有职责一般是处理组件、数据组件或连接组件中的-种。当然，概念架构中也有“大组件分解成小组件”的设计决策，但并非子系统的含义。
3. 交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等;而概念架构中的交互机制是“概念化”的，例如“A层使用B层的服务”。这里的“使用”到了细化架构中可能基于接口编程、消息机制或远程方法调用等其中的一种。

当然，概念架构和细化架构都满足软件架构的定义，无论是“架构=组件+交互”,还是“架构=重要决策集”。

方案的制定，为什么需要项目负责人、需求人员、架构师等共同参与呢?

因为方案涉及的工作内容不仅仅是架构，还涉及项目管理和需求工作。

“方案” 和“架构”的联系与区别如下:

1. 方案包含一定的架构内容。
2. 方案涉及的架构基本在概念架构一级。
3. 架构设计的工作还远未完成。

方案制定需要项目负责人、需求人员、架构师等角色的共同参与。

所以，架构师应记住:

方案=“项目+需求+架构”的总览

方案≠架构的全部

逻辑架构

划分子系统、定义接.....这些典型工作都属于逻辑架构设计的范畴。

本章阐释ADMEMS的5视图方法中逻辑架构视图的设计:

1. 先从划分子系统的3种必用手段讲起；
2. 随后，纠正“我的接口我做主”这种错误认识，代之以“协作决定接口”的正确理解；
3. 而且，本章将解析逻辑架构设计的整体思维套路，解决一线架构师郁闷已久的“多视图方法只讲做什么、不讲怎么做”的问题；
4. 最后，总结逻辑架构设计的10条经验要点。

相对于逻辑架构设计而言，物理架构视图的设计是不是就乏善可陈呢?不。一线架构师最缺的是物理架构的设计思维。

从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。

但是，思维当中经历了哪些思考、判断和权衡呢?

从最终目标层面，决策要兼顾多方涉众的不同利益，可从“攻”与“守”两个方面理解:

1. 高性能(攻)。
2. 持续可用性(攻)。
3. 可伸缩性(攻)。
4. 经济性(守)。
5. 技术可行性(守)。
6. 易维护性(守)。

从思维要点层面，“开销”和“争用”是核心。架构师正是通过“降低开销”、“避免争用”来实现高性能、高可伸缩性等最终目标的:

1. 如何降低物理节点“内”的计算开销?
2. 如何降低物理节点“间”的通信开销?
3. 如何避免物理节点“内”CPU、内存、硬盘等资源的争用?
4. 如何避免物理节点“间”网络的带宽资源冲突?