【架构】2023架构师全景图

模块的职责定位要非常清晰

模块的数据模型和接口设计要保证通用

实现模块的高复用，还需要做好业务的层次划分

拆分：一般做业务架构时，我们先考虑垂直拆分，从大方向上，把不同业务给区分清楚，然后再针对具体业务，按照业务处理流程进行水平拆分

整合：
1、通用化整合：通用化指的是通过抽象设计，让一个模块具备通用的能力，能够替代多个类似功能的模块。
2、平台化整合：平台化是把定位相同的模块组织在一起，以组团的方式对外提供服务。对于外部系统来说，我们可以把这些模块看成是一个整体，一起对业务场景提供全面的支撑。

单体应用内部一般采用分层结构，从上到下，一般分为表示层、业务层、数据访问层、DB 层。

单体架构在水平方向上，通过层次化的划分，降低了业务的深度复杂性；
不过在垂直方向上，单体应用缺乏清晰的边界，上下层模块之间是多对多的网状依赖关系

在单体架构中，模块结构是否合理，很大程度上依赖于开发者的个人水平。

架构图

快速落地

项目初期，适应快速验证市场

业务系统的体量变大时，弊端就会暴露

1、多团队并行开发的话，需要额外的资源来协调不同团队之间的并行开发和上线。

2、代码合并和编译非常复杂

分布式架构，简单来说就是系统由多个独立的应用组成，它们互相协作，成为一个整体。

在分布式架构中，API 接口属于应用的一部分，它和表示层共享底层的业务逻辑

把一个大系统的业务复杂度，分割成多个小业务的复杂度，从而降低了整体的复杂度。

分布式架构适用于业务相关性低、耦合少的业务系统

架构图

通过拆分后，各个应用之间的耦合度低，就可以很好地支持多团队的并行开发。

作为应用的开发者，除了要满足自身业务的需求之外，同时还需要考虑外部业务的需求，这两部分经常会打架。

每个应用都是从头到尾，自搭一套完整的体系，导致业务之间重复造轮子，造成资源浪费。

目的

特点

目的

特点

然而 SOA 服务化的思想很好，但在系统实现上比较重，落地比较困难。

相对于SOA架构，思想是相似的，但是架构更轻，但两者不同的地方在于，微服务是去中心化的，不需要 SOA 架构中 ESB 的集中管理方式。这就需要不同的通讯方式

每个微服务，都是负责端到端的业务

微服务强调围绕业务，进行清晰的业务和数据边界划分，并通过良好定义的接口输出业务能力

微服务强调所谓的哑管道，通过 HTTP 等简单的技术手段就可以访问

微服务强调智能终端，所有的业务逻辑包含在微服务内部，不需要额外的中间层提供业务规则处理

架构图

实际而言侧重小服务

实践方法：弱化微服务的小应用定位，然后扩大化微服务小服务的定位

概念

冲突

解决方案

示意图

要求

优势

互联网企业

传统企业

架构图

移动团队将web端jar包物理组装，基于jar包业务逻辑向app前端提供接口

简单方便，只需要个移动团队就可以

可快速落地

移动端对jar包紧密依赖，但web端并没有职责去协同移动端接口情况，导致app端常出bug

移动团队需要理解web端所有团队的业务逻辑，进行二次开发，对移动端开发能力要求较高

移动团队依赖web团队，并行开发困难

架构图

web端业务团队直接对接app前端,移动端和web共享底层业务逻辑，有助于快速复制pc端功能

通过 V2.0 架构的升级，业务线团队的生产力就被完全释放了，App 的功能也就快速丰富起来了。

app和web相互影响，两者用户体验性不一样，共同开发会影响系统的功能

重复开发：每个模块的移动端接口都需要一些系统级功能：安全验证，日志记录，性能监控

由于是直连的方式，只要后端系统出问题，直接影响app可用性，使得app整体脆弱

架构图

对v2.0服务端进行拆分，物理独立；同时将app端共性系统级功能进行集中，个性化业务进行分散处理

通过移动网关访问服务端接口，主要处理系统级功能

app端和pc端彻底独立

核心业务功能复用

方便强化了系统级功能

                      复用层次举例

代码复用有自己打包的类库，第三方提供的 SDK，还有各种算法封装等

技术组件复用有我们自己封装的，更多的是大量开源的中间件，比如 Redis、MQ、Dubbo 等

代码级复用和技术组件复用都属于工具层面，它们的好处是在很多地方都可以用，但和业务场景隔得有点远，不直接对应业务功能，因此复用的价值相对比较低。

业务实体复用针对细分的业务领域，比如订单、商品、用户等领域

业务流程的复用针对的是业务场景，它可以把多个业务实体串起来，完成一个端到端的任务。如下单流程服务

最高层次的复用是对整个系统的复用，比如说一个 SaaS 系统（Software-as-a-Service），它在内部做了各种通用化设计，允许我们通过各种参数配置，得到我们想要的功能；

从技术复用到业务复用，越往上，复用程度越高，复用产生的价值也越大，但实现起来也越复杂，它能复用的场景就越有限

要尽可能在服务内部封装完整的业务规则，对外提供完整的业务语义，最大程度地简化服务的使用。不能仅仅是DAO

在划分服务边界时，要保证服务数据完整、功能全面，这样才能支撑一个完整的业务领域。

服务的数据和职责要一致，谁拥有信息，谁就负责提供相应的功能

基础服务处于调用链的底层，服务之间不会有任何的调用关系，也就是说基础服务相互之间是正交的。

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

                                           业务场景

主要服务

不包含服务

内部数据模型：订单状态通用化

外部接口

所有商品相关的表都存在产品库里面，数量超过了上百张；（表多）
商品是电商业务的核心，几乎所有的前后台系统都需要访问这个产品库；（压力大）
对这些表的访问是怎么方便怎么来，有些 SQL 语句会对大量的表做 Join 关联。（使用乱）

存在问题

首先是对这个大数据库按照业务维度进行垂直拆分，比如分成产品数据库、库存数据库、价格数据库等等

然后基于这些拆分后的库，构建微服务，以接口的方式来支持数据库表的访问

最后将各个业务系统统一接入微服务，最终完成整个商品体系的微服务化改造。

改造流程图

准备阶段

实施阶段

改造前后架构图对比

除了做好库存服务本身的设计开发工作，相关团队之间的配合也是非常重要的，需要团队之间沟通和确认

从项目推进的角度来看，这种核心服务的改造，很多时候都是技术一把手工程

基于现有系统进行改造和全新的服务设计是有所不同的，我们不能追求理想化和一步到位，而是要考虑到系统的平滑过渡，先实现微服务的顺利落地，后续再考虑各种优化

一个高复用和扩展平台架构图

公司作为供应商，为大型餐饮连锁企业打造 O2O 交易平台，包括三方聚合外卖、自有小程序、App 点餐，这些线上用户的订单最终会落到门店的收银系统，由门店进行履单。

聚合外卖订单架构

小程序下单架构

统一订单服务架构

中台架构

Scale Up：通过升级硬件来提升处理能力

Scale Out：通过增加机器数量来提升处理能力

我们在做技术架构设计时，就要充分考虑各种硬件故障的可能性，做好应对方案

首先是弥补了硬件的缺陷。比如 Redis 集群，通过数据分片，解决了单台服务器内存和带宽的瓶颈问题，实现服务器处理能力的水平扩展

封装让我们可以更高效地访问系统资源。比如说，数据库是对文件系统的加强，使数据的存取更高效

CAP 理论：C 代表系统内部的数据一致性，A 代码系统的可用性，P 代表节点之间的网络是否允许出问题，我们在这三者里面只能选择两个

软硬件本身有故障，比如机器断电，网络不通

高并发引起的系统处理能力的不足，软硬件系统经常在处理能力不足时，直接瘫痪掉

常规的流量进来，但系统内部处理比较复杂，我们就需要运用技术手段进行优化

高并发的流量进来，系统仍旧需要在合理的时间内提供响应

冗余无单点

水平扩展

柔性事务

系统可降级

系统可监控

首先要解决网络的可用性问题：可以拉多条线路，比如在企业私有的 IDC 机房和公有云之间，同时拉移动和电信的线路

可以选择 Nginx、HAProxy、LVS 等负载均衡软件，它们都能很好地支持双节点 +Keepalived 部署

通过冗余和自动切换避免了单点的故障

Web 应用通常是无状态的，我们可以部署多个实例，很方便地通过水平扩展的方式，提升系统的处理能力

接入层的负载均衡设备，可以通过各种算法进行多个 Web 实例的路由，并且对它们进行健康检测，如果某个实例有问题，请求可以转发到另一个实例进行处理，从而实现故障的自动转移。

还可以在接入层做限流，比如，在 Nginx 中设置每秒多少个并发的限制，超过这个并发数，Nginx 就直接返回错误

同时支持了 Web 节点的水平扩展、自动故障转移以及系统的可降级（限流）

服务通常也是无状态的，我们也可以通过部署多个实例进行水平扩展

可以使用传统的代理服务器方式，进行请求分发

很多的微服务框架本身就支持服务的直接路由，比如在 Spring Cloud 中，我们就可以通过 Eureka 进行服务的自动注册和路由

我们可以为不同服务配置不同的线程池，实现资源隔离，避免因为一个服务响应慢，而占用所有的线程资源；如果某个服务调用失败，我们可以对它进行熔断操作，避免无谓的超时等待，影响调用方的整体性能。

针对具体的功能，我们还可以做一些功能开关。开关实际上是一个标志变量，它的值可以是 on/off， 我们在代码中可以根据它的值，来确定某一段逻辑是否要执行。开关的值可以在数据库或配置系统里定义，这样我们就能够通过外部的开关值，控制应用内部的行为，

同时支持了服务节点的水平扩展、自动故障转移以及系统的可降级（熔断和业务开关）。

关系数据库

缓存

消息系统

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

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

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

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

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

小程序端的CDN优化

Nginx 负载均衡

收银端的通信线路备份

小程序服务端的部署，我们把实例数从十几台提升到了 100 台，水平扩展它的处理能力

基础服务全部迁移到了容器环境，这样在提升资源利用率的同时，也更好地支持了基础服务的弹性扩容

小程序服务端依赖了 7 个基础服务，每个基础服务也做了相应的水平扩展

背景：下单高峰期，订单主库的写访问频率很高，一个订单会对应 6~7 次的写操作，包括了创建新订单和订单状态变更；订单的读操作，我们之前通过一主多从部署和读写分离，已经得到了支持，负责写入的主库只有一个实例

措施

通过消息系统对它们进行了解耦。 一方面，前台下单要求比较快，后台 OMS 的订单处理能力比较弱（OMS 库没有进行水平分库），通过消息的异步化处理，我们实现了对订单流量的削峰；另一方面，如果 OMS 有问题，以异步的方式进行数据同步，也不会影响前台用户下单。

在用户支付完成或者后台生成取餐码后，我们会以微信消息的方式通知用户，这个在代码中，也是通过异步方式实现的，如果微信消息发送不成功，用户还是可以在小程序上看到相关信息，不影响用户取餐。

当收银系统向 OMS 拉取新订单时，OMS 不是到数据库里查询新订单，而是把新订单先保存在 Redis 队列里，OMS 通过直接查询 Redis，把新订单列表返回给收银系统

商品服务中，菜单和商品数据也是放在了 Redis 中，每天凌晨，我们通过定时任务，模仿前端小程序，遍历访问每个商品数据，实现对缓存的预刷新，进一步保证缓存数据的一致性，也避免了缓存数据的同时失效，导致缓存雪崩。

背景：原来的架构中，前台小程序是通过轮询服务端的方式，来获取取餐码；同样，商户的收银系统也是通过轮询 OMS 系统拉取新订单，这样的收银系统有上万个，每隔 10s 就会拉取一次。这种盲目轮询的方式，不但效率低，而且会对服务端造成很大的压力

落地了消息推送中心，收银系统通过 Socket 方式，和推送中心保持长连接。当 OMS 系统接收到前台的新订单后，会发送消息到消息推送中心；然后，收银系统就可以实时地获取新订单的消息，再访问 OMS 系统拉取新订单。为了避免因消息推送中心出问题（比如消息中心挂掉了），导致收银系统拿不到新订单，收银系统还保持对 OMS 系统的轮询，但频率降低到了 1 分钟一次。

小程序前端会通过 Web Socket 方式，和消息推送中心保持长连接。当 OMS 系统在接收到收银系统的取餐码后，会发送消息到消息推送中心。这样，小程序前端可以及时地获取取餐码信息。

Zabbix 做系统监控、CAT（Central Application Tracking） 做应用监控、拉订单曲线做业务监控

所有的节点都在一个页面里显示，包括 Web 应用、Redis、MQ 和数据库，页面也会体现节点之间的上下游关系。我们通过采集节点的状态数据，实时监测每个节点的健康程度，并且用红黄绿三种颜色，表示每个节点的健康状况

按照 10 万 QPS 和 99.99% 的可用指标要求，通过大量的压测来确定的。

首先，我们对每个节点进行接口压测，做各种性能优化，确定好需要的机器数量

我们利用 JMeter，模拟小程序前端发起混合场景的调用，以此检验系统的抗压能力，以及在压力下，系统的可用性是否达到了预定的要求

我们在生产环境中根据压测环境，按照服务器 1:1 的数量进行部署，保证性能不打折，最终这个小程序下单平台总的机器规模，也达到了数百台的量级

正面保障的角度来看，我们首先在各个环节都避免了单点，包括远程通信线路，这样能保证任意一个节点出了问题，都有其他实例可以顶上去

我们通过节点的垂直扩展和水平扩展，大幅度提升了系统的处理能力，包括应用、服务和数据库的扩展

有效地利用了 Redis 缓存，对高频的订单和菜单数据的读取进行了优化。

在柔性处理方面，我们通过异步处理，来优化系统的性能和避免大流量的直接冲击，包括使用消息系统解耦前台下单系统和后台 OMS 系统，以及通过及时的消息推送，避免前端盲目轮询服务端。

在系统接入层，通过 Nginx 进行限流，为系统的可用性进行兜底，这样在流量超过预估时，能够有效地避免后端系统被冲垮

强有力的监控手段，可以实时全面地了解系统运行状况，随时为异常情况做好准备。

系统能够自动地判断每个节点是否正常，并直观地给出结果，不需要经过专业人员的分析。

系统能够自动把各个节点的监控信息有机地串起来，从整体的角度对系统进行监控，不需要很多人反复地进行沟通。

交通监控

系统监控

方案架构图

每个被监控的节点，均有对应的 Agent 负责采集健康数据，不同的节点类型，数据采集的方式也不一样：Web 节点通过 HTTP 接口调用，Redis 通过 Jredis，MQ 也通过对应的 API 接口，DB 则采用 JDBC

Agent 每隔 3s 采集节点数据，然后上报数据给 Monitor Service；Monitor Service 负责确定节点当前的状态并保存到数据库，这样就完成了节点健康状态的检测；

前端 Dashboard 每隔 3s，拉取所有节点的状态，以红黄绿三种颜色在同一页面展示，同时还会显示具体的出错信息。

如何判断节点监控状态

架构图

Agent 负责采集节点的健康数据，每隔 3s，主动访问一次

Agent 会根据这些数据，结合相应的规则，来判断节点的健康状态

健康状态有三种，分别是错误、警告和正常，这三种状态也对应了 Dashboard 中节点的红黄绿三种颜色。

Agent 在获取了这 4 类节点的健康状态后，会调用 Monitor Service 进行数据上报，如果节点有问题，上报内容还包括具体的错误消息。

注意事项

redis

MQ

数据库

web应用

改造点

为了方便 Web 应用的接入，监控系统开发团队提供了 SDK，它内置了接口调用信息的统计和健康计算规则。应用程序借助 SDK，就可以给 Agent 提供最终的健康结果，也就是说 SDK 帮助应用完成了最复杂的第二步工作。

SDK 的内部，实际上是一个 HashMap 结构，它的 key 就是 Web 应用的各个接口名字，它的 value 是一个简单的对象，包含这个接口最近 3s 总的调用数量、总的出错次数和总的耗时等。

健康规则

前端展示界面

红色圈里的是各个分组，蓝色圈里是各个应用。我们可以很清晰地看到，“应用层”分组里的会员应用，会调用“依赖服务”分组里的四个服务。

布局是在后台定义的，保存在数据库里。我们为每个系统预先设定好布局，类似 HTML 里的 Table 布局语法，行用 TR 表示，列用 TD 表示。我们根据页面显示要求，提前确定好分组和应用会占用多少行，多少列

前端通过 Monitor Service 的接口获取页面的布局信息，然后根据布局信息进行动态展示，如果系统的部署有变化，我们在管理后台调整布局就可以了，非常灵活。

我们通过类似 Table 方式的布局，前端通过一套代码，就可以满足所有系统的节点展示需求，并且能够比较好地体现应用之间的上下游依赖关系，当系统有问题时，我们就可以很直观地判断出问题的根源在哪里。

前端页面展示

首先，前端页面读取所有节点的健康状态，按照节点分类展示有问题的节点，并标识出相应的颜色；

然后，节点的具体出错信息也可以在大盘中展示；

最后，我们根据每个系统内部节点的健康状况，按照一定的规则，算出各个系统的总体健康状态，在页面展示系统的健康状态。

对于一个实际的业务系统来说，情况就会复杂很多。一个外部请求进来，需要经过内部很多的软硬件节点处理，用户请求的处理时间就等于所有节点的处理时间相加。只要某个节点性能有问题（比如数据库），或者某项资源不足（比如网络带宽），系统整体的 TPS 就上不去。这也是在实践中，很多系统 TPS 只有个位数的原因。

加快单个请求处理

同时处理多个请求

请求处理异步化

首先，我们要加快单个请求的处理。单节点性能提升是系统整体处理能力提升的基础，这也是我们作为技术人员的基本功。但这里的问题是，节点的性能提升是有瓶颈的，我们不能超越前面说的基础操作的性能。至于把请求分解为多个小请求进行并行处理，这个在很多情况下并不可行，

对多个请求进行同时处理是应对海量请求的强有力手段，如果我们能够水平扩展每一个处理节点，这样在理论上，系统处理请求的能力无限的。而这里的问题是，对于无状态的计算节点，我们很容易扩展，比如说 Web 应用和服务；但对于有状态的存储节点，比如说数据库，要想水平扩展它的处理能力，我们往往要对系统做很大的改造。

异步化处理，在某些场景下是很好的提升系统性能的方式，我们不用增加机器，系统就能够完成请求的处理。但问题是，同步调用变成异步的方式，往往会导致处理结果不能实时返回，有时候会影响到用户体验，而且对程序的改造也会比较大。

我们经常说，业务是可运营的，而实际上，系统也是可运营的。我们可以动态地调整系统软硬件部署，在业务高峰期增加软硬件节点，在业务低谷期减少软硬件节点，这就是系统的可伸缩能力。

节点级别的可伸缩

系统级别的可伸缩

如果我们把单元扩大到系统的所有节点，这就是一个虚拟机房的概念。我们可以在一个物理机房部署多个虚拟机房，也可以在不同的物理机房部署多个虚拟机房，这样，部署系统就像部署一个应用一样，系统的可伸缩性自然就更好。

这意味着节点支持多实例部署，我们可以通过水平扩展，线性地提升节点的处理能力，保证良好的伸缩性以及低成本。

短事务意味着资源锁定的时间短，系统能够更好地支持并发处理

柔性事务意味着系统只需要保证状态的最终一致，这样我们就有更多的灵活手段来支持系统的高性能，比如说通过异步消息等等。

缓存是系统性能优化的利器，如果数据能够缓存，我们就可以在内存里拿到数据，而不是通过磁盘 IO，这样可以大大减少数据库的压力，相对于数据库的成本，缓存的成本显然也更低。

如果计算可并行，我们就可以通过增加机器节点，加快单次请求的速度，提高性能。

异步处理给系统的处理增加了弹性空间，我们可以利用更多的处理时间，来降低系统对资源的实时需求，在保证系统处理能力的同时，降低系统的成本。

虚拟化和容器化是指对基础资源进行了抽象，这意味着我们不需要再依赖具体的硬件，对节点的移植和扩容也就更加方便。

虚拟化和容器化对系统的资源切分得更细，也就说明对资源的利用率更高，系统的成本也就更低

我们对峰值流量的预估以及要加多少机器都是拍脑袋的，和实际出入往往很大，一旦估计少了，系统同样会面临过载的风险；

为了短暂的几分钟促销，我们需要增加大量的机器，事先要做很多的运维准备工作，不但浪费资源，而且效率很低；

最为关键的是，有些处理节点，系统不是通过加机器就能扩展处理能力的，比如商品库存数据库，下单时，我们需要扣库存，而为了防止库存更新冲突，我们需要锁定库存记录，导致系统的并发处理能力有限，这个问题单靠加机器是解决不了的。

短期 只有1-2分钟

短期无法处理大量订单，可以延长处理订单时长

用户还是愿意为买到等待一会

得出结论：可以利用异步处理的思路来应对秒杀活动

用户在商品详情页提交订单后，这个订单会作为预订单进入排队区，同时排队系统会返回用户一个排队编号，这个编号用于跟踪后续的订单处理进度；

用户被引导到一个等待页，这个页面会根据排队号，定时地查询排队系统，排队系统会返回预订单在队列中的位置信息，包括它前面还有多少未处理的预订单，以及后台系统大概还要多久会处理这个预订单，这样用户就不会焦虑；

在排队系统的处理区，有很多消费者，它们依次从排队区的队列里获取预订单，然后调用后台下单系统生成实际的订单；

随着预订单变成正式的订单，队列里的预订单会逐渐变少，如果当前的预订单已经从队列里被移除了，用户的等待页就会检测到这个情况，页面自动跳转到订单完成页，这就和常规的购物流程一样了，用户进行最后的支付，最终完成整个前台下单过程。

这种方式比较适合瞬时有高并发流量的场景，单高峰会持续一段较长的时间，而用户对订单处理又有比较高的时间要求，那就不适合采用这种异步削峰的方式。

针对队列的技术选型，排队系统使用的是 Redis，而不是 MQ。因为相对于 MQ 来说，Redis 更轻量级，性能更好，它内置了队列数据结构，除了和 MQ 一样支持消息的先进先出以外，我们还可以获取队列的长度，以及通过排队号获取消息在队列中的位置，这样我们就可以给前端反馈预订单的处理进度。

关于队列的调度问题，也就是消费者优先从哪个队列里拿预订单，排队系统会结合下单时间和队列的长度来确定，以保证用户合理的时间体验。

关于队列长度，为了保证用户能够买到商品，我们并不是把所有前台的下单请求都会放到队列里，而是根据参与活动的秒杀商品数量，按照 1:1 的比例，设置队列初始长度，这样就保证了进入队列的请求最终都能生成订单。

这里我们为每个秒杀商品提供一个单独的队列，这样就可以分散数据在 Redis 中的存取，多个队列可以提供更好的性能。

垂直分库就是数据库里的表太多，我们把它们分散到多个数据库，一般是根据业务进行划分，把关系密切的表放在同一个数据库里

某些表太大，单个数据库存储不下，或者数据库的读写性能有压力。通过水平分库，我们把一张表拆成多张表，每张表存放部分记录，分别保存在不同的数据库里

原则

方法

基本方法

两种方法优劣

和单库能处理的记录数有关。一般来说，MySQL 单库超过了 5000 万条记录，Oracle 单库超过了 1 亿条记录，DB 的压力就很大

如果分库的数量太少，我们达不到分散存储和减轻 DB 性能压力的目的；如果分库的数量太多，好处是单库访问性能好，但对于跨多个库的访问，应用程序需要同时访问多个库，如果我们并发地访问所有数据库，就意味着要消耗更多的线程资源；如果是串行的访问模式，执行的时间会大大地增加

分库数量还直接影响了硬件的投入

对于单库访问，比如查询条件已经指定了用户 ID，那么该 SQL 只需访问特定库即可。此时应该由 DAL 层自动路由到特定库，当库二次分裂时，我们也只需要修改取模因子就可以了，应用代码不会受到影响。

对于简单的多库查询，DAL 层负责汇总各个分库返回的记录，此时它仍对上层应用透明。

对于带聚合运算的多库查询，比如说带 groupby、orderby、min、max、avg 等关键字，建议可以让 DAL 层汇总单个库返回的结果，然后由上层应用做进一步的处理。这样做有两方面的原因，一方面是因为让 DAL 层支持所有可能的聚合场景，实现逻辑会很复杂；另一方面，从 1 号店的实践来看，这样的聚合场景并不多，在上层应用做针对性处理，会更加灵活。

在分库情况下，对于每个数据库，我们要取更多的记录，并且汇总后，还要在应用里做二次排序，越是靠后的分页，系统要耗费更多的内存和执行时间

解决方案

分库字段只有一个，比如这里，我们用的是用户 ID，如果给定用户 ID，这个查询会落到具体的某个库。但我们知道，在订单服务里，根据订单 ID 查询的场景也很多见，不过由于订单 ID 不是分库字段，如果不对它做特殊处理，系统会盲目查询所有分库，

解决方案

上层应用通过订单服务访问数据库；

分库代理实现了分库相关的功能，包括聚合运算、订单 ID 到用户 ID 的映射，做到分库逻辑对订单服务透明

Lookup 表用于订单 ID 和用户 ID 的映射，保证订单服务按订单 ID 访问时，可以直接落到单个库，Cache 是 Lookup 表数据的缓存；

DDAL 提供库的路由，可以根据用户 ID 定位到某个库，对于多库访问，DDAL 支持可选的多线程并发访问模式，并支持简单的记录汇总；

Lookup 表初始化数据来自于现有的分库数据，当新增订单记录时，由分库代理异步写入

首先，实现 Oracle 和 MySQL 两套库并行，所有数据读写指向 Oracle 库，我们通过数据同步程序，把数据从 Oracle 拆分到多个 MySQL 库，比如说 3 分钟增量同步一次

其次，我们选择几个对数据实时性要求不高的访问场景（比如访问历史订单），把订单服务转向访问 MySQL 数据库，以检验整套方案的可行性。

最后，经过大量测试，如果性能和功能都没有问题，我们再一次性把所有实时读写访问转向 MySQL，废弃 Oracle。

第一阶段，把部分非实时的功能切换到 MySQL，这个阶段主要是为了验证技术，它包括了分库代理、DDAL、Lookup 表等基础设施的改造

第二阶段，主要是验证业务功能，我们把所有订单场景全面接入 MySQL

增加 6 个 MySQL 实例，把现有 6 个库的数据同步到新的库，比如说，0 号库同步到 6 号库，1 号库同步到 7 号库等等；

在配置文件里把分库的取模从 6 变成 12

通过数据库脚本，每个库删掉一半数据，比如对于 0 号库，删掉用户 ID%12=6 的记录，对于 6 号库，删掉用户 ID%12=0 的记录