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