架构师的30条基础架构原则
2022-03-11 13:14:28 3 举报AI智能生成
架构师的30条基础架构原则
作者其他创作
大纲/内容
架构师角色
应该是
一个引导者
讨论发起者
花草修建者
而不是
定义者
构建者
目的
解决团队内部的架构纷争和抉择
基本原则
1、KISS(Keep it simple, stupid)
用简单的解决方案来解决问题
花更多的时间去思考简单且容易理解的方案
2、YAGNI(You aren't gonna need it)
不要去搞一些不需要多的东西
需要的时候在搞
3、爬走跑
先保证跑通，再优化变得更好，然后继续优化让其变大伟大
迭代做事情，敏捷开发的思路
4、创建稳定、高质量的产品的唯一方法就是自动化测试
5、时刻要想投入产出比ROI
划得来不
6、基于用户需求来平衡需要做哪些事情
7、设计及测试功能时，尽可能的独立
8、不要搞花哨的
简单点
功能选择
9、不可能预测用户将会如何来使用我们的产品
拥抱 MVP，最小可运行版本
基于体验和用户反馈再决定下一步要做什么
10、尽可能做较少的功能
有疑问的时候就不要去做
最多留个扩展点就 OK
11、等待有人提出再说
除非是核心流程
12、有勇气和用户说不
找到一个更好的解决方案来解决
引导和领导用户去做正确的事情，而不是流行的事情
服务端设计和并发
13、要知道一个 server 是如何运行的，从硬件到操作系统，直到编程语言
优化I/O调用最好架构的首选之路
14、要了解 Amdhal 同步定律
在线程之间共享可变数据会让程序变慢
只在必要的时候才去使用并发的数据结构
只在必须要同步的时候才去使用同步
如果要用锁，也要确保尽可能少的时间去 hold 锁
如果要在加锁后做一些事情，要确保自己在锁内会做哪些事情
15、如果涉及是一个无阻塞且事件驱动的架构，千万不要阻塞线程或者在这些线程中做一些I/O操作
分布式系统
16、无状态的系统是可扩展和直接的
任何时候都要考虑这一点
17、保证消息只被传递一次
大部分的承诺 exactly-once-delivery 都是精简后的
18、实现一个操作尽可能的幂等
比较方便恢复
至少还有一次传递(at least once delivery)的状态
19、知道 CAP 理论
可扩展的事务(分布式事务)是很难的
如果可能，尽可能的使用补偿机制
RDBMS 是无法扩展的
20、分布式一致性无法扩展，也无法进行组通信，也无法进行集群范围内的可靠通信
理想情况下最大节点限制为 8 个
21、在分布式系统中，永远无法避免延迟和失败
用户体验
22、要了解你的用户和清楚他们的目标
是新手、专家还是偶然用户？
对计算机科学了解的程度
23、最好的产品是不需要产品手册的
24、当无法在两个选择中做决定的时候，不要直接将这个问题通过提供类似配置选项的方式提供给用户
最好：每次均找到一个可行的选项
次好：自动的给出选项
第三：增加一个配置参数，设置合理默认值
25、总是要为配置提供一个合理的默认值
26、设计不良的配置会造成一些困扰
应该总是要为配置提供一些示例值
27、如果输入了未知的配置要抛出错误
艰难的问题
29、不要轻易去换编程语言
真正掌握很难
30、复杂的拖拉拽的的界面是艰难的
总结
准备一个能够被广泛接收的人们讨论问题的锚点的原则列表
收藏
收藏
职业：本科
0 条评论
下一页
