先利其器
适当使用数据库
- 关系型数据库
- 适用 当需要ACID属性来保证数据之间的关系和一致性时
- 优势 提供了高度的事务完整性，支持sql，可用于发杂查询
- 缺点 难以扩展 成本高 海量数据效率低
- 非关系型数据库
- 适用 不需要关联其他数据，也不需要事务完整性
- 优势 无需sql层解析，读写性能快，存储格式多样
- 缺点 无事务处理
马斯诺锤子：当你只有一个锤子时，任何东西看起来都像个钉子
前车之鉴
失败乃成功之母
抓住每个机会，尤其是失败的机会，学习经验并吸取教训，不断的从错误和成功中学习。
最好的经验来自于失败的错误，而不是成功。
之前订单搜索和订单详情都有两个经典设计失败案例，一直说要整理下，还没有整理出来，看到这段话时候很触动。两次设计失败都是为了追求通用性，复用性，所以将不同功能集于一身，成为一个万能接口，导致功能支持起来后期比较吃力。举个例子订单搜索支持通用搜索(非订单搜索)，而早期入参是按订单搜索维度设计，所以导致通用个搜索入参特别不友好。早期订单详情支持实时+非实时一起，而发现实时的可返回字段远远少于非实时字段，实时非实时对应支持的扩展组件也不尽相同，不得不重构抽离。
有备无患
用“泳道”隔离故障
- 隔离的好处 不赘述
- 隔离的原则
- 泳道不共享
- 泳道之间不进行同步调用
- 异步调用设置超时和开关控制
- 限制泳道间异步调用
避免系统串联
这个比较常见的雪崩源头都是系统串联，其中一环发生问题，不断导致上游出问题，而上游显得很被动，串联组件受多重失败乘法效应的影响。减少以串联形式连接的组件数量。
启用和禁用功能
限流降级的重要性，最大程度的保证应用不被其他应用拖垮。核心依赖的跑不了。
超然物外
力求无状态
有状态会限制可扩展性，降低可用性并增加成本
链接：https://www.jianshu.com/p/fe7eb8691b99
标签：串联,架构,泳道,笔记,订单,搜索,实时,阅读,失败 来源： https://www.cnblogs.com/muailiulan/p/13099868.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。