目录

背景

1 架构演变

2 如何实现高层的复用

2 中台产生案例

3 技术架构的核心要点

4 技术架构的高可用案例

---

背景

      业务架构、数据架构、应用架构和技术架构它们是相互关联和相互支持的，共同构成了企业的总体架构，业务架构是源头，然后才是其他架构。在软件工程中，产品经理定义了系统的外观，满足了用户，业务架构师在此基础上，进一步定义了系统的内部模块结构，满足了开发人员。架构目标实现业务的可复用和扩展，本文主要讲解了架构的演变历史和实战

1 架构演变

• 架构图

       

• 各个阶段的架构图

  名称	架构图	备注
  单体		单体：表示层，业务层，数据访问层，DB层
  分布式		通过网络连接的多个组件，通过交换信息协作而形成的系统
  传统 SOA		在分布式的基础上， 解决的是企业内部大量异构系统集成的问题。
  新的SOA		解决的是系统重复建设的问题
  微服务		小应用 + 小服务
  中台		简单地说，前台要快，后台要稳，中台因此诞生。 中台通过实现基础业务的平台化，实现了企业级业务能力的快速复用

2 如何实现高层的复用

首先服用可分为技术复用（代码复用，组件复用），业务复用（产品复用，业务实体复用，业务流程复用），其中产品复用 > 业务流程复用 > 业务实体复用 > 组件复用 > 代码复用

而实现高层的复用，必须做好 “基础服务边界的划分原则”

• 服务的完整性原则

     对外提供完整的业务语义，最大程度地简化服务的使用

• 服务的一致性原则

      比如订单的优惠计算过程，却不是由订单服务来负责，而是由独立的促销服务负责的

• 正交原则

     服务之间不会有任何的调用关系

     服务之间有数据的依赖关系，但没有接口的调用关系     

  

2 中台产生案例

下面以一个餐饮公司的例子，来讲解中台的产生，餐饮公司餐饮服务已聚合外卖服务，

支持在第三方外卖平台和门店下单。目前需新增自有小程序下单渠道。

• 妥协且务实方案，可快速落地的方案

• • 存在如下的问题
    • 存在两套订单系统（小程序订单和外卖订单）
    • 小程序订单处理链路过长（由于消息队列堵塞，外卖系统不能及时同步给小程序的订单服务，这样导致了小程序用户不能及时地看到取餐码）
    • 降低了系统整体的稳定性（使两套订单系统解耦，我们使用了消息队列在两个库之间同步订单数据）

             

• 统一订单服务中台方案

• • 变化

  • 原来外卖系统的两个模块“外卖同步接口”和“POS 接口”，升级为了两个独立的应用。

  • 原来外卖和小程序各自有一个订单库，现在合并为了一个订单库，由这个订单服务统一对外提供订单数据的访问和状态管理。

  • 明显的层次结构，自上而下分为三层（渠道端，渠道端对应的服务段，底层的订单服务）

3 技术架构的核心要点

上面讲述了中台的架构的演变，，业务架构的实现必须依懒技术架构的，下面我们继续解析技术架构的核心点

•  系统物理模型

     

       

• 系统故障点

       

• 解决原则

       

•          
  • 第一个设计原则是冗余无单点  
  • 第二个设计原则是水平扩展
  • 第三个原则是柔性事务
  • 第四个原则是系统可降级（限流，降级，熔断，功能禁用）
  • 第五个系统可监控

   

4 技术架构的高可用案例

餐饮公司司在全国有大量的门店，他们准备搞一个长期的大型线上促销活动，促销的力度很大：用户可以在小程序上先领取优惠券，然后凭券再支付 1 元，就可以购买价值数十元的套餐。预计每秒 10 万 QPS，首日的订单数量会超过 500 万。

现有体系架构图

现有体系的流程

1 小程序前端通过 Nginx 网关，访问小程序服务端

2 小程序服务端会调用一系列的基础服务，完成相应的请求处理，包括门店服务、会员服务、商品服务、订单服务、支付服务等，每个服务都有自己独立的数据库和 Redis 缓存；

3 订单服务接收到新订单后，先在本地数据库落地订单，然后通过 MQ 同步订单给 OMS 履单中心

4 门店的收银系统通过 HTTP 远程访问云端的 OMS 履单中心，拉取新订单，并返回取餐码给 OMS，OMS 再调用小程序订单服务同步取餐码

5 小程序前端刷新页面，访问服务端获得取餐码，然后用户可以根据取餐码到门店取餐或等待外卖。

实现高可用99.99%的性能的架构

 具体的实施

•  前端接入改造
  • 小程序端的 CDN 优化
  • Nginx 负载均衡
  • 应用和服务的水平扩展
  • 订单水平分库
  • 异步化处理
  • 主动通知，避免轮询
    • 在原来的架构中，前台小程序是通过轮询服务端的方式，来获取取餐码；同样，商户的收银系统也是通过轮询 OMS 系统拉取新订单
    • 新增消息推送中心
      • 收银系统通过 Socket 方式，和推送中心保持长连接
      • 当 OMS 系统接收到前台的新订单后，会发送消息到消息推送中心；然后，收银系统就可以实时地获取新订单的消息，再访问 OMS 系统拉取新订单
      • 为了避免因消息推送中心出问题（比如消息中心挂掉了），导致收银系统拿不到新订单，收银系统还保持对 OMS 系统的轮询，但频率降低到了 1 分钟一次。
      • 同理，小程序前端会通过 Web Socket 方式，和消息推送中心保持长连接。当 OMS 系统在接收到收银系统的取餐码后，会发送消息到消息推送中心。这样，小程序前端可以及时地获取取餐码信息。
  • 缓存的使用
    • 当收银系统向 OMS 拉取新订单时，OMS 不是到数据库里查询新订单，而是把新订单先保存在 Redis 队列里，OMS 通过直接查询 Redis，把新订单列表返回给收银系统
    • 在商品服务中，菜单和商品数据也是放在了 Redis 中，每天凌晨，我们通过定时任务，模仿前端小程序，遍历访问每个商品数据，实现对缓存的预刷新，进一步保证缓存数据的一致性，也避免了缓存数据的同时失效，导致缓存雪崩。
  • 一体化监控
    • Zabbix 做系统监控
    • CAT 做应用监控
    • 拉订单曲线做业务监控