前言
这将是一个系列的文章，整理和记录我对软件架构设计的感悟和理解，与大家一起分享经验和教训。
架构是什么
软件系统的设计由开发者的决策和意图构成。设计可以被划分为软件架构和详细设计，通常认为架构设计更关注于宏观的、整体的规划和决策，类似建筑行业的顶层设计，例如，我们通常不会在架构设计中考虑该用何种设计模式，这通常体现在针对某一具体业务组件进行的详细设计中。
那么，我们如何区分二者的区别呢？请参考Mary Shaw和David Garland：
随着软件系统规模与复杂度的增长，整个系统结构的设计与规格说明书变得更为重要，甚至超过对算法与运算数据结构的选择。系统的组织，如组件的组合方式；整体的控制结构；用于通信、同步及数据访问的各种协议；针对设计元素的功能分配；设计元素的组合方式；物理分布；伸缩能力及性能；演进的维度；在多个可选设计方案中作出选择。这些都是软件架构层面的事。
回到标题最初的问题，何谓软件架构？我个人比较推崇来自卡内基梅隆大学软件工程研究所(SEI)的定义：
计算机系统的软件架构是解释该系统所需的结合体的集合，其中包括：软件元素、元素之间的相互关系，以及二者各自的属性。
该定义罗列了软件架构中至关重要的要素：元素、关系及属性。就像有人讲计算架构本质上就是三件事情，我们所有的手机、电脑、PC、超算本质上都在处理三件事：计算、存储和通讯一样，我喜欢这样直指本质的简洁表述。
而架构设计呢？我的定义是，
设计者在各种
约束条件（时间、成本、利益相关者的关切、未来系统的扩展演进等等）下，针对特定领域，所做出的一系列合理的权衡和决策集合，充分体现了设计者的决策和意图
- 约束条件：任何一个设计都无法摆脱特定的约束，例如，客户暂时没有预算为新系统采购一批新的备份设备，而现有系统中已经在运行的刚好有一台这样的设备，但是能力有限，我们该如何开始设计？设计一套完备的备份方案付诸于PPT上，但是无法实现？还是利旧设备，错峰备份？
- 特定领域：架构设计离不开领域知识，再通用的设计也有不适合的领域，不同的领域有不同的关切，对质量属性的要求也不一样，例如，金融系统更注重安全性，电商To C类产品则更关注性能、并发处理能力及可用性等
- 合理的权衡和决策：正如CAP理论所讲的那样，C、A、P无法同时满足，架构设计也是一样，例如，为了提高安全性，我们使用HTTPS协议以及各种加密、解密手段，但是，这可能对性能有一定的影响；一种决策往往也会影响着另外的决策，因此，架构设计需要不断在各种各样的决策当中权衡，直到找到合适的那一种组合
何时开始&何时结束
架构设计伴随着投入，伴随着成本，那么，与之对应的就是收益和产出，可能是解决当下的问题，但更常见的是预见未来的风险；我个人比较推崇风险驱动的架构设计，过早、过细、超前的架构设计都不一定是合适的，按需的才是合理的，何为按需？权衡风险和收益。
从一个项目架构设计开始
此处想基于一个项目作为基础，阐述下当时的理解。之后的系列文章将会更深入的剖析各个板块的经验。
背景
因为涉密，不会涉及到过多的背景，项目特点：
- 规模很大、耗时很长，设立了专门的PMO团队
- 未来产品面向的用户群体都是内部员工，但是基数也非常大，我们预判会有操作尖峰时刻（虽然实践证明，尖峰时刻的并发还是没有预想的高）
- 集成难度高：同时在建的就有六个系统，还涉及到不同的业务前端系统的对接，预期使用总线模式
- 基础设施自建：为什么要单独把这条提出来？因为基础设施建设往往涉及机房建设、网络规划、安全规划、虚拟化等等，纷繁复杂，正常讲一般是独立于软件架构设计的
何时开始的？
项目之处就开始做的架构设计。有人讲，不是要先识别风险，排列优先级，然后才开始架构设计吗？架构设计的其中一个收益就是，降低复杂度，而复杂度正是我们最大的风险。当然，还有其他一些原因，例如，利益相关者的关切等等
做了什么事情
翻开我的技术管理-设计阶段的目录结构，我区分了如下几块：
首先，区分架构设计与详细设计：
- 架构设计：顶层设计，体现我们对系统整体的设计决策，为开发人员指明前行的路，安装好规划的导轨
- 详细设计：针对不同的功能模块，综合运用UML、设计模式等等手段，为开发人员明确工具和手段
架构设计我们规划了如下几方面内容：
- 总览&设计草图：通常设计不是一蹴而就的，将会产生很多中间产物，同时，也会伴随着各种各样的研讨和思维碰撞，此处主要归集相关的输出
- 基础架构设计：此项目从硬件采购到机房规划，再到网络规划等等均是从0开始，此处规划了软硬件采购清单、安装计划等等产出物
- 系统架构设计：此目录规划的是软件系统的设计，实际上包含了
- 业务需求分析：首先需要对系统建设的初衷加以解释和说明，业务的痛点是什么，产品的定位是什么，产品如何满足业务，优化流程？
- 建设原则与目标：建设原则通常是业务和技术双重保障，例如，业务可扩展、流程标准化、技术先进性、数据安全性等等；架构目标通常是技术类的非功能质量属性，例如，我们定义的高可用性、高可扩展性、高效低成本以及安全可靠性等等；同时，我们也会阐述如何保证我们的架构目标能够真正落地
- 集成架构：待建系统在整个企业信息化架构中所处的位置，以及与周边系统的联系，非常重要的一点就是连接器的选择，REST风格的网络调用？分发-订阅风格的交互？等等
- 功能架构：也即我认为的领域知识，系统功能的横切面；
集成架构讲的是全景概览图，而功能架构则是对在建系统内部领域知识的细化，是整体视图中的一个局部视图，可以为利益相关者提供系统内部的功能概览；例如，系统涵盖了哪些功能模块，层次是如何划分的 - 技术堆栈：相较功能架构而言，这是个技术视图。例如，可以展示我们的分层架构，技术堆栈组成，技术选型的权衡及抉择等等。面向开发人员则可以一眼看出他们所需具备的技术领域知识
- 部署架构：一般分为逻辑部署架构、物理部署架构以及网络拓扑三个方面，逻辑部署架构主要是对各个组件进行示意；物理部署架构则从实际的物理硬件方面入手描述组件的运行载体；网络拓扑一般展示组网方案等
- 典型场景方案说明：例如，不同的子系统处于不同的地理位置，那么，则需要考虑基础数据交互的问题，是本地冗余基础数据还是实时交互获取？用户操作尖峰时刻，如何应对高并发？缓存请求、异步处理？如何与外部系统交互？
- 关键质量属性方案说明：例如，如何在各个层次保证可用性及可扩展性（服务、缓存、队列、数据库、存储等等）？如何保证系统的安全性（应用安全-登录、审计、功能/操作/组件/数据权限、防SQL注入、防XSS攻击、防横向越权等等，网络完全-划分安全域、分层防护等等，主机安全-定期更新OS等等）？如何保证数据可靠性（容灾备份等等）？
- 网络、安全、备份、集成：实际上都会涵盖在上一节的系统架构设计输出中，只不过每一个架构视图关切点不一样，相关的目标用户也不一样
- 数据库架构设计：一般会从概念视图入手，识别领域对象及关系，然后进行设计。我们是从全局开始的，但未来一般是敏捷迭代式的
- UIUE设计：页面、交互设计，一般会有专门的设计师负责，此处只是为了完整性说明
- 架构设计评审：为了控制风险，大型项目一般都会设置专门的评审会对业务、技术架构进行评审，结合领域专家、技术专家、关键用户一起
- 历史版本：记录心路历程
- 参考资料：记录参考资料、数据、引用等等
教训是什么
- 一系列原因，决定了我们的架构设计与后续阶段的关系是瀑布式的，架构设计以期是完整的、一致的、大而全的，并不是风险驱动的、按需的设计
- 总体框架及蓝图是完整的，但是每个部分的细节仍然需要进一步补充完善，这也是接下来的系列文档需要分解和补充的
下一步
分解和细化每一类模块的意图、方案及具体实现。
