软件架构基础

        作为软件开发这个行业的从业者，或者说作为一个码农，对“架构”这个词肯定不陌生，而且能胜任“架构师”这个职责的人，无疑是行业的精英，尤其在国内，“架构师”更是受人追捧。然而要成为一名合格的架构师，要走的路很漫长，要掌握的知识不仅仅是coding。此文献给预要成为“架构师”，和正在向着这个目标拼搏的同行，或许对我们自身的硬能力无太多帮助，但一定是一盏指引我们的明灯，能 为我们指引正确的方向。

• 何为“架构”？

如果你要找它的官方概念，或者是定义，完全可以去百度，我这里不描述，也无法像百科那样专业，但我将之理解为，“架构”就是由结构和愿景组成。

软件架构可能包括哪些内容：

1. 系统形态。即所谓的 CS、BS、原生移动端、分布式、同步异步等等。
2. 软件系统结构。包含软件含有哪些组件？怎么分层？如何交互等等。
3. 技术选择。如编程语言（java、C++、phython）、部署平台（Linux、windows）等等。
4. 框架选择。Web MVC、ORM等等。
5. 设计方法与模式。用来提升软件性能；保证可用性、伸缩性的技术手段。

软件架构解决什么问题？

1. 为软件定义一个良好的结构，使其能有更好的伸缩性。
2. 为软件定义一个统一的标准和规则，使其能更好的维护和扩展。
3. 有一个清晰的愿景和路线图，使当前和后续的开发团队都能清晰明确地理解需求和目标。
4. 有一个衡量和检测代码质量的手段，用来把控代码的质量。
5. 根据团队技术的能力以及技术指导的资源，规划与之匹配的架构。

软件架构包含哪些角色？

1. 架构驱动力：需求驱动架构。理解目标，抓住、提炼、挑战需求（功能需求和非功能需求）。不要简单地假设，需要切实地捕捉与提炼非功能需求，通过各种手段（后面介绍）和数据来证明你的架构能够满足哪些需求，又不能满足哪些需求。
2. 软件设计：建立技术战略、愿景和线路图。
3. 技术风险：发现、减轻和承担技术风险，保证架构的运转。不要盲目乐观，依然用数据证明你的架构能够工作。
4. 架构演化：在整个交付过程中，持续技术指导和架构担当。不要画出一些框线图之后，就袖手旁观，要持续参与改进，不断微调，指导开发人员。
5. 编写代码：架构原型、框架、基础代码编写，以及代码评审。不要总以为架构师就不用写代码，那是不可能的。
6. 质量保证：引入标准，坚持原则。不要应付交付，要确保质量与标准。

软件设计的流程与步骤。

1. 功能需求评定。
2. 明确质量属性（非功能需求）。
3. 挑战约束
4. 坚持原则
5. 评估影响

质量属性：

1. 性能。响应时间、延迟、QPS
2. 可伸缩性。高并发、每秒请求数 TPS
3. 安全性。认证、授权。传输和存储机密
4. 灾难恢复。发生灾难事件（如断网、断电），如何保持运行。
5. 可用性。100% ？ 24/7/365 ？ 一般用几个9来衡量。
6. 检测。性能检测，如java 的JMX；故障报警，如SNMP。
7. 管理。必要地暴露一些管理运维接口，如修改拓扑图、修改配置项、刷新缓存等等。
8. 审计。记录事件日志，包括数据的变化、CUD行为。
9. 灵活性。提供多种不同的方式执行某个任务，使得非技术人员也可以通过接口选择和修改业务规则。
10. 可扩展性。
11. 可维护性。
12. 国际化。
13. 本地化。
14. 法律法规。

注意：不要认为你的软件能满足以上的所有质量属性，需要划分优先级，哪些一定不能少，根据你的成本做一定不能少的，不要目盲地夸口。

约束：

1. 时间和预算的约束。
2. 技术约束。技术清单、与现有系统互操作性、部署平台、人员技术成熟度、内部知识产权等等。
3. 人员约束。
4. 组织约束。

注意：约束有好有坏，不要把约束全当成绊脚石。同时，我们挑战约束，也要划分优先级，交付过程中，时常倾听和收集约束，尝试挑战约束的同时，快速地调整约束优先级。

原则：

1. 编码标准与规范、自动化单元测试、代码质量静态分析工具。
2. 架构原则：分层策略、业务逻辑的位置、高内聚低耦合、无状态组件（可伸缩性的基本保障）、事物一致性（最终还是始终）
3. 最佳实践。借鉴行业内最佳实践无疑是一条捷径，但是一定不要盲从，要从自身的约束来衡量最佳实践是否真的适用。

 

• 草图

1. 语境图。用于交流的图，我暂时将之理解为不含深度技术细节的需求流程图。
2. 容器图。框线图，表示架构中所用到的容器。
3. 组件图。容器内的模块
4. 类图。构成模块的类

注意：不要把简单随意的框线图当成草图，有效地草图包含标题、标签、形状、职责、线条、箭头、颜色、边框、布局、方向、要点等等。

• 文档

下一章开始进入正题，大型网站技术架构实践。