架构即未来阅读笔记三

先利其器

适当使用数据库

• 关系型数据库
  • 适用 当需要ACID属性来保证数据之间的关系和一致性时
  • 优势 提供了高度的事务完整性，支持sql，可用于发杂查询
  • 缺点 难以扩展 成本高 海量数据效率低
• 非关系型数据库
  • 适用 不需要关联其他数据，也不需要事务完整性
  • 优势 无需sql层解析，读写性能快，存储格式多样
  • 缺点 无事务处理

马斯诺锤子：当你只有一个锤子时，任何东西看起来都像个钉子

前车之鉴

失败乃成功之母

抓住每个机会，尤其是失败的机会，学习经验并吸取教训，不断的从错误和成功中学习。
最好的经验来自于失败的错误，而不是成功。

之前订单搜索和订单详情都有两个经典设计失败案例，一直说要整理下，还没有整理出来，看到这段话时候很触动。两次设计失败都是为了追求通用性，复用性，所以将不同功能集于一身，成为一个万能接口，导致功能支持起来后期比较吃力。举个例子订单搜索支持通用搜索(非订单搜索)，而早期入参是按订单搜索维度设计，所以导致通用个搜索入参特别不友好。早期订单详情支持实时+非实时一起，而发现实时的可返回字段远远少于非实时字段，实时非实时对应支持的扩展组件也不尽相同，不得不重构抽离。

有备无患

用“泳道”隔离故障

• 隔离的好处 不赘述
• 隔离的原则
  • 泳道不共享
  • 泳道之间不进行同步调用
  • 异步调用设置超时和开关控制
  • 限制泳道间异步调用

避免系统串联

这个比较常见的雪崩源头都是系统串联，其中一环发生问题，不断导致上游出问题，而上游显得很被动，串联组件受多重失败乘法效应的影响。减少以串联形式连接的组件数量。

启用和禁用功能

限流降级的重要性，最大程度的保证应用不被其他应用拖垮。核心依赖的跑不了。

超然物外

力求无状态

有状态会限制可扩展性，降低可用性并增加成本

链接：https://www.jianshu.com/p/fe7eb8691b99

标签：串联,架构,泳道,笔记,订单,搜索,实时,阅读,失败
来源： https://www.cnblogs.com/muailiulan/p/13099868.html