人人都是架构师

Posted 2020-07-23 zzfx

http://www.devdiv.com/blog-1895-57919.html

架构是什么？业界并没有权威的说法。

架构作为名词与结构相关，将产品分解为一系列组件、模块和交互。作为动词，是关于交流愿景和引入技术领导力的，简而言之，架构就是结构和愿景。

关于架构

应用程序的架构着重于软件和代码的组织，每个工程师的代码都是有架构的，只是自发和自觉的区别；系统架构描述从组件和服务到子系统等更高层次的抽象含软硬件，从代码结构到生产环境，与软件系统重要元素相关的所有东西就是软件架构。
企业架构是一个截然不同的概念，指的是战略而非代码。

所有架构都是设计，但并非所有设计都是架构。架构反映了一个系统的重要设计决策，重要性通过改变的成本来衡量，包括系统的形态，结构，技术选择，框架选择，设计方法和模式的选择等。

敏捷与架构并不冲突，敏捷中的架构是在独特环境下量化所需的预先设计，架构提供了xDD敏捷方式的分界线。主要思想是集中主要的高层次关键需求，规避风险，然后迭代和增量。敏捷是相对的，好的架构能够带来敏捷，尤其是微服务架构。

非功能性需求

需求是最重要的事情，失去了功能，失去了客户的价值，软件将一无是处。
然而，功能的实现只是架构的开端。

架构首先来自需求，需求驱动架构，然后非功能性需求反映服务等级，面对客观环境的约束，自行引入的架构实现原则，是在高层次以上对需求、约束、和原则的理解和把握。

非功能性需求也可以称为质量属性，我所了解的非功能性需求主要有：

• 性能：响应时间或延迟
• 可伸缩性：更多用户，请求和数据的处理能力
• 可用性：99.9%意味着每天一分钟故障
• 安全性： 可以参考OWASP，open web application security project
• 灾难恢复：业务连续性过程
• 可访问性：www.w3.org/standards/webdesign/accessibility
• 监测：只读视图
• 管理：操作视图
• 审计：日志及虚拟货币的对账
• 灵活性：非技术人员修改业务规则的能力
• 可扩展性：可以做现在还不能做的事情
• 可维护性：可读性，可持续发展
• 法律规则：如隐私
• 国际化i18n
• 本地化i10n

约束

时间和预算是约束的基本条件。

技术约束

技术清单，现有系统的互操作性（兼容性），目标部署平台，技术成熟度（保守），开源技术，供应商关系（阿里云，还是AWS），过去的失败，内部知识产权

人员约束

团队规模，技能，团队扩展的速度，咨询和培训，运维团队的技能

组织约束

企业战略的影响，办公室政治的影响

约束条件也是有优先级的。

原则

开发原则

编码标准和规范，自动化单元测试，静态分析工具

架构原则

1. 分层策略，如UI组件里没有数据访问的逻辑
2. 业务逻辑的位置：
3. 高内聚、低耦合：解耦合可以推迟技术决策的时间
4. 无状态组件：可伸缩性的瓶颈
5. 存储过程：爱恨交加
6. 域模型：面向对象的丰富程度
7. http会话的使用程度：少用
8. 始终一致和最终一致： 一般趋向于数据的最终一致性
9. 不/使用ORM
10. 依赖注入

风险

架构包含技术的选择，更多分层等于更高的复杂度，但是轻量级协同设计可以提高质量。最佳实践也是有使用条件限制的，面对架构要用于质疑。

系统的最大风险

外部接口是系统风险最高的部分之一。

• 关键的外部接口有哪些？接口的技术定义是什么？
• 哪些队列是通信组件？消息的格式是什么？
• 同步还是异步？异步连接是否有保障？能否乱序传输？
• 接口是否幂等？接口的可用性、性能、可伸缩性、安全性？
• 接口的所有权属？版本的升级处理？服务级别？

系统的常见风险

除了外部接口之外，其他的常见风险如下：

• 组件运行过慢
• 组件无法伸缩
• 关键组件崩溃
• 单点故障
• 数据被破坏
• 基础设施故障
• 磁盘满
• 新技术过于复杂

文档

架构需要以文档的方式回答质疑。
代码不会讲述完整的故事，轻量级文档来描述代码之外的问题，如

• 这是关于什么的？希望能做什么？
• 质量属性？约束？原则？
• 软件架构？外部接口？
• 数据（数据比软件本身更重要。）？
• 基础设施架构？
• 部署？运营和支持？
• 决策日志
  ……

总而言之，架构不论你关注与否都在那里，每个人都是架构师，只是关注的层面和视角不同而已。

Without architect consideration，the software is a big mall of mud。