目录
背景
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 做应用监控
- 拉订单曲线做业务监控
