架构即未来阅读笔记三

先利其器

适当使用数据库

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

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

前车之鉴

失败乃成功之母

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

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

有备无患

用“泳道”隔离故障

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

避免系统串联

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

启用和禁用功能

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

超然物外

力求无状态

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



链接:https://www.jianshu.com/p/fe7eb8691b99
原文地址:https://www.cnblogs.com/muailiulan/p/13099868.html