浅谈架构实战

[1 架构演变](#1 架构演变)

[2 如何实现高层的复用](#2 如何实现高层的复用)

[2 中台产生案例](#2 中台产生案例)

[3 技术架构的核心要点](#3 技术架构的核心要点)

[4 技术架构的高可用案例](#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 做应用监控
  - 拉订单曲线做业务监控