乐趣区

关于后端:应用架构总结

jiezi

架构指标

  1. 高可用性

整体零碎可用性最低 99.9%，指标 99.99%。全年故障工夫整个零碎不超过 500 分钟，单个系统故障不超过 50 分钟。

  1. 高可扩展性
    零碎架构简略清晰，利用零碎间耦合低，容易程度扩大，业务性能增改方便快捷。
  2. 低成本
    减少服务的重用性，进步开发效率，升高人力老本；
  3. 最终一致性

服务设计能满足数据最终一致性，能不便、快捷的满足三方、或者对方对账需要。

  1. 品质要求

咱们要求在零碎设计时候要兼顾上面的各个品质要求

架构总体准则

DID 准则解释

Design(D)设计 20 倍的容量；Implement(I)施行 3 倍的容量；Deploy（D）部署 1.5 倍的容量

起因：DID 为产品扩大提供了经济，无效，及时的办法

要点：在晚期思考可扩展性能够帮忙团队节省时间和金钱。在需要产生大概一个月前施行（写代码），在客户一拥而上的几天前部署。

例子 ：“什么时候该在可扩展性上投入”有些草率的答复是，最好在须要的前一天投入和部署。如果你可能多做达到须要改善可扩展性计划的前一天部署，那么 这笔投资的机会最佳，而且有助于实现公司财务和股东利益的最大化。
让咱们面对现实，及时投入和部署基本就不可能，即便可能，也无奈确定具体的工夫，而且会带来很多危险。

DID（设计 - 施行 - 部署）：思考问题和设计方案，为计划构建零碎和编写代码；理论装置或者部署计划。

设计（Design）:DID 办法的设计（D）阶段汇集在扩大到 20 倍和无限大之间，通过现在可扩展性大会，把领导者和工程师团队汇集在一起，独特探讨产品的扩大瓶颈，这是在 DID 设计阶段发现和确定须要扩大局部的一个好方法。

施行（I，Implement）: 咱们把规模需要的范畴放大到更靠近事实，例如以后规模的 3~20 倍。

部署（D，Deploy）: 在部署阶段资产的老本较高，如果是一家适度高增长的公司，兴许咱们能够把最大产能进步到 1.5 倍；如果是一家超高增长的公司，兴许咱们能够把最大产能进步到 5 倍。扩大具备弹性，它既能够扩张也能够膨胀，因而灵活性是要害，因为你须要响应客户的申请，随着规模的膨胀和扩张，在零碎之间调整容量

架构设计准则

  1. 业务平台化
  • 业务平台化，互相独立。如交易平台、仓储平台、物流平台、领取平台、广告平台等
  • 根底业务下沉，可复用。如用户、商品、类目、促销、订单等（参考目前外围零碎）。
  1. 外围业务、非核心业务拆散

外围业务与非核心业务拆散，外围业务精简（利于稳固），非核心业务多样化。

  1. 隔离不同类型的业务
  • 交易业务是签订买家和卖家之间的交易合同，须要优先保障高可用性，让用户能疾速下单
  • 闪购业务对高并发要求很高，应该跟一般业务隔离
  1. 辨别主流程、辅流程

分清哪些是电商的主流程。运行时，优先保障主流程的顺利完成，辅流程能够采纳后盾异步的形式。防止辅流程的失败导致主流程的回滚。

利用架构设计要点

  1. 稳定性准则
  • 所有以稳固为核心
  • 架构尽可能简略、清晰
  • 不适度设计
  • 解耦、拆分
  • 稳固局部与易变局部拆散
  • 外围业务与非核心业务拆散
  • 主业务与辅业务拆散
  • 利用与数据拆散
  • 服务与实现细节拆散
  • 抽象化
  • 利用抽象化：利用只依赖服务形象，不依赖服务实现细节、地位
  • 数据库抽象化：利用只依赖逻辑数据库，不须要关怀物理库的地位和分片
  • 服务器抽象化：利用虚拟化部署，不须要关怀实体机配置，动静调配资源
  1. 松耦合
  • 同步调用时，须要设置超时工夫、对调用异样时候的 failover 解决。
  • 非核心业务尽量异步化：外围、非核心业务之间，尽量异步解耦。
  • 跨业务线（比方分期乐、桔子、鼎盛间）调用须要采纳 HTTP 接口方式，防止底层业务逻辑耦合和依赖。
  1. 容错设计
  • 服务自治：服务能彼此独立批改、部署、公布和治理，防止一个服务产生灾祸引发连锁反应(肯定要对 mq、rpc、db、redis 的异样容错解决、异样包含超时、业务异样、零碎异样等)。
  • 集群容错：利用零碎集群，防止单点。
  • 多机房容灾：多机房部署，多活。

6 数据的一致性准则

  • 小规模散布或不散布的业务确保可用、数据牢靠、统一，即 A & C 兼顾；
  • 中型散布零碎须要思考【BASE- 最终一致性】，如果波及到订单、交易、清结算等数据敏感场景，保持数据最终一致性是最根本准则；
  • 大规模分布式系统在不波及订单、交易、清结算等数据敏感场景上能够思考【有损服务】；。

架构合成准则

架构依赖准则

  1. 依赖稳固局部
  • 稳固局部不依赖易变局部
  • 易变局部能够依赖稳固局部
  • 要求：防止循环依赖
  1. 跨域弱依赖

跨业务域调用时，尽可能异步弱依赖

  1. 根本服务依赖
  • 根本服务不能向上依赖流程服务
  • 组合服务、流程服务能够向下依赖根本服务
  • 条件：根本服务稳固
  1. 平台服务依赖
  • 平台服务不依赖下层利用
  • 下层利用可依赖平台服务
  • 条件：平台服务稳固
  1. 外围服务依赖
  • 外围服务不依赖非核心服务
  • 非核心服务可依赖外围服务
  • 条件：外围服务稳固

本文由 mdnice 多平台公布

退出移动版