人人都是架构师

Posted zzfx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了人人都是架构师相关的知识,希望对你有一定的参考价值。

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。

以上是关于人人都是架构师的主要内容,如果未能解决你的问题,请参考以下文章

人人都是架构师:面对风险

人人都是 Serverless 架构师 | 弹幕应用开发实战

人人都是 Serverless 架构师 | 弹幕应用开发实战

人人都是 Serverless 架构师 | 弹幕应用开发实战

人人都是 Serverless 架构师 | 现代化 Web 应用开发实战

飞算(SoFlu)软件机器人——人人都是全栈架构师