Home 架构设计原则
Post
Cancel

架构设计原则

摘录自《架构及未来》中的一小部分内容。

理想情况下,架构原则将基于高层次的目标决策,架构原则应该和公司的发展愿景和使命相符。

目标可能会随着时间的推移而改变,因为原则应该广泛支持未来和当前的目标。原则应该极可能体现 SMART 特性,不过原则一般不受时间限制,SMART 中的 T 缩写是 Test,原则应该可以用来测试设计,验证它是否符合要求。

  1. Specified: 具体的,原则不应该被混淆在它的措辞中。
  2. Measurable: 可度量的,原则不应包含“无限”这样的词汇。
  3. Attainable: 可达到的,原则应该是鼓舞人心的,但能够被设计和现实。
  4. Realizable: 现实的,团队应该有能力达成目标。
  5. Testable: 可测试的,原则应该可以用来测试设计。

另外架构原则需要得到团队的任何,应该考虑与团队一起来制定。原则的数量要控制好,确保容易记忆并增加利用率,建议不超过 15 个。

15 个架构原则

源自于 AKF 官方网站。

  1. N+1 设计。永远不少于两个,通常为 三个。
  2. 回滚设计。确保系统能回滚到之前发布的任何版本。
  3. 禁用设计。能够关闭任何发布的功能。
  4. 监控设计。在设计阶段必须考虑监控,而不是实施后补充。
  5. 多活数据中心。不要被一个数据中心限制住。
  6. 使用成熟技术。只用确实好用的技术。
  7. 异步设计。只有在绝对必要时进行同步调用。
  8. 无状态设计。只有业务确实需要时才使用状态。
  9. 水平扩展而非垂直升级。永远不要依赖更大更快的系统。
  10. 至少有两个步骤的前瞻性。在扩展性问题发生前考虑好下一步行动计划。
  11. 非核心则购买。如果不是你擅长的,也提供不了差异化竞争优势则直接购买。
  12. 使用商品化硬件。在大多数情况下,便宜的最好。
  13. 小构建,小发布,快试错。全部研发要小构建,不断迭代,快速成长。
  14. 隔离故障。通过断路避免故障传播和交叉影响。
  15. 自动化。如果机器可以做,就不要依赖于人。

image

image

更多细节可以查看这里

责任矩阵

最后,团队在制定和修改原则过程中应该遵循 RASCI 责任矩阵

  1. R - Responsible - 谁来执行这个任务?
  2. A - Accountable (also Approver) - 谁来审批或者说谁对最终结果负责?
  3. S - Support - 谁在这个任务中提供支持?
  4. C - Consulted - 谁可以提供有价值的建议或者帮助?
  5. I - Informed - 谁应该被通知到任务的进度和结果?

JAD & ARB

Joint Architecture Design 联合架构设计和 Architecture Review Board 架构审查委员会是积极推动架构设计的两个过程。JAD 是一个协同设计的过程,所有工程人员共同设计和开发一些符合架构原则的新功能。ARB 负责选择和决定每一个新功能或者业务领域的架构,在架构设计得到最终签署之前,要由该委员会确定其符合公司所有的架构原则和业界的最佳实践。

JAD 团队中应该包括一名未来负责开发的软件工程师,一位架构师,至少一位运维工程师,产品经理和质量保证工程师,每个人都会给团队带来独特的知识、观点、经验和目标,和团队里其他人可以互补。

ARB 的组成最重要的考虑因素是个人特质。首先,必须是组织里受到尊敬的人,他们的地位、任期或者在特定领域的技术业务知识受到人们的尊重。特定位置的人参与,可以确保 ARB 的决定受到广泛尊重。ARB 需要合适的人做出正确的决定,并赋予最终决定的权力。ARB 需要高管的参与,ARB 的参与者要展示自己的专长。

ARB 的活动应当被视为每个成员的额外工作。因为 ARB 的工作是自愿的,你可以修改永久或者临时会员的身份。

所有的 ARB 应该探讨 ARB 的目的,ARB 审查应只授予那些有充分准备的项目。

This post is licensed under CC BY 4.0 by the author.

折腾一下小米路由器

猫和狗的领导力