作为软件开发这个行业的从业者，或者说作为一个码农，对“架构”这个词肯定不陌生，而且能胜任“架构师”这个职责的人，无疑是行业的精英，尤其在国内，“架构师”更是受人追捧。然而要成为一名合格的架构师，要走的路很漫长，要掌握的知识不仅仅是coding。此文献给预要成为“架构师”，和正在向着这个目标拼搏的同行，或许对我们自身的硬能力无太多帮助，但一定是一盏指引我们的明灯，能 为我们指引正确的方向。
- 何为“架构”？
如果你要找它的官方概念，或者是定义，完全可以去百度，我这里不描述，也无法像百科那样专业，但我将之理解为，“架构”就是由结构和愿景组成。
软件架构可能包括哪些内容：
- 系统形态。即所谓的 CS、BS、原生移动端、分布式、同步异步等等。
- 软件系统结构。包含软件含有哪些组件？怎么分层？如何交互等等。
- 技术选择。如编程语言（java、C++、phython）、部署平台（Linux、windows）等等。
- 框架选择。Web MVC、ORM等等。
- 设计方法与模式。用来提升软件性能；保证可用性、伸缩性的技术手段。
软件架构解决什么问题？
- 为软件定义一个良好的结构，使其能有更好的伸缩性。
- 为软件定义一个统一的标准和规则，使其能更好的维护和扩展。
- 有一个清晰的愿景和路线图，使当前和后续的开发团队都能清晰明确地理解需求和目标。
- 有一个衡量和检测代码质量的手段，用来把控代码的质量。
- 根据团队技术的能力以及技术指导的资源，规划与之匹配的架构。
软件架构包含哪些角色？
- 架构驱动力：需求驱动架构。理解目标，抓住、提炼、挑战需求（功能需求和非功能需求）。不要简单地假设，需要切实地捕捉与提炼非功能需求，通过各种手段（后面介绍）和数据来证明你的架构能够满足哪些需求，又不能满足哪些需求。
- 软件设计：建立技术战略、愿景和线路图。
- 技术风险：发现、减轻和承担技术风险，保证架构的运转。不要盲目乐观，依然用数据证明你的架构能够工作。
- 架构演化：在整个交付过程中，持续技术指导和架构担当。不要画出一些框线图之后，就袖手旁观，要持续参与改进，不断微调，指导开发人员。
- 编写代码：架构原型、框架、基础代码编写，以及代码评审。不要总以为架构师就不用写代码，那是不可能的。
- 质量保证：引入标准，坚持原则。不要应付交付，要确保质量与标准。
软件设计的流程与步骤。
- 功能需求评定。
- 明确质量属性（非功能需求）。
- 挑战约束
- 坚持原则
- 评估影响
质量属性：
- 性能。响应时间、延迟、QPS
- 可伸缩性。高并发、每秒请求数 TPS
- 安全性。认证、授权。传输和存储机密
- 灾难恢复。发生灾难事件（如断网、断电），如何保持运行。
- 可用性。100% ？ 24/7/365 ？ 一般用几个9来衡量。
- 检测。性能检测，如java 的JMX；故障报警，如SNMP。
- 管理。必要地暴露一些管理运维接口，如修改拓扑图、修改配置项、刷新缓存等等。
- 审计。记录事件日志，包括数据的变化、CUD行为。
- 灵活性。提供多种不同的方式执行某个任务，使得非技术人员也可以通过接口选择和修改业务规则。
- 可扩展性。
- 可维护性。
- 国际化。
- 本地化。
- 法律法规。
注意：不要认为你的软件能满足以上的所有质量属性，需要划分优先级，哪些一定不能少，根据你的成本做一定不能少的，不要目盲地夸口。
约束：
- 时间和预算的约束。
- 技术约束。技术清单、与现有系统互操作性、部署平台、人员技术成熟度、内部知识产权等等。
- 人员约束。
- 组织约束。
注意：约束有好有坏，不要把约束全当成绊脚石。同时，我们挑战约束，也要划分优先级，交付过程中，时常倾听和收集约束，尝试挑战约束的同时，快速地调整约束优先级。
原则：
- 编码标准与规范、自动化单元测试、代码质量静态分析工具。
- 架构原则：分层策略、业务逻辑的位置、高内聚低耦合、无状态组件（可伸缩性的基本保障）、事物一致性（最终还是始终）
- 最佳实践。借鉴行业内最佳实践无疑是一条捷径，但是一定不要盲从，要从自身的约束来衡量最佳实践是否真的适用。
- 草图
- 语境图。用于交流的图，我暂时将之理解为不含深度技术细节的需求流程图。
- 容器图。框线图，表示架构中所用到的容器。
- 组件图。容器内的模块
- 类图。构成模块的类
注意：不要把简单随意的框线图当成草图，有效地草图包含标题、标签、形状、职责、线条、箭头、颜色、边框、布局、方向、要点等等。
- 文档
下一章开始进入正题，大型网站技术架构实践。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
