1. 背景

Zebra 是一个基于 JDBC API 协定上开发出的高可用、高性能的 数据库拜访层 解决方案。相似阿里的 tddl，zebra 是一个 smart 客户端，提供了诸如动静配置、监控、读写拆散、分库分表等性能。zebra 是由基础架构团队开发和保护，定位是公司对立的数据库拜访层组件（Data Access Layer），是新美大 DBA 团队举荐的官网数据源组件，未来也会以 zebra 为外围进行数据拜访层的演进。

Zebra 最后是上海侧数据库拜访组件，目前上海侧全量利用应用该组件拜访数据库。2016 年 Q3 之后，北京侧逐渐放弃应用 atlas，外卖配送、酒旅、到餐、猫眼等事业部，都陆陆续续开启接入 zebra。截止 2018 年 6 月 27 日，公司已有 8000+ 利用接入了 zebra，整体覆盖率达到 94.66%。对于 java 利用，都倡议应用 zebra 去拜访数据库。

简化了读写拆散、分库分表的开发工作，使得业务方在分库分库、读写拆散的状况下，仍然能够像操作单个库那样去操作，屏蔽底层实现的复杂性，对业务通明。提供了从读写拆散到分库分表全生命周期的技术支持。

2. 组成

zebra 次要是以客户端的模式提供服务，客户端又细分为 3 个组件：zebra-api、zebra-dao、zebra-ds-monitor-client。

• zebra-api(外围)除了监控外，简直 zebra 所有外围性能，如 读写拆散、分库分表、全链路压测、Set 化反对、就近路由、流量管制、故障模拟 都是通过 zebra-api 来提供的。
• zebra-ds-monitor-client提供端到端的监控，将监控信息上报到 cat、falcon、mtrace。
• zebra-dao对 mybatis 的轻量级封装，所有 mybatis 原有的性能都具备，额定提供了异步化接口、分页插件、多数据源等性能。

2.1zebra-api（外围依赖）

2.1.1 读写拆散

作为一个拜访层组件，读写拆散是一个根本要求。

zebra 目前反对的如下能力：

• 反对程度扩大从库，灵便的调整各个从库的任意流量比例
• 反对优先就近抉择从库进行读取数据，防止跨机房拜访
• 灵便的强制走主库策略，反对单条 SQL 或者整个申请内所有 SQL 等维度
• ……

2.1.2 分库分表

目前分库分表反对能力如下：

• 同时反对分库和分表，路由策略能够通过 groovy 脚本进行灵便定制
• 分表键反对 =，in 等操作符
• 欠缺的 SQL 解析，反对聚合，分组，排序，Limit 等语句
• 反对多维度的分表策略
• 配置均集中式配置和存储，简化业务代码的配置文件
• ……

分库分表除了落地到客户端的能力上，zebra 还在运维能力上进行继续晋升。因次，zebra 能够说为分库分表打造了一站式的解决方案，具体包含以下的能力：

• 一键的建库建表和 DDL 变更操作
• 反对路由后果的可视化查问
• 反对多维度的数据自动化同步
• ……

2.1.3 高可用

高可用架构如下所示：

在整体架构图中能够看到，目前整个数据库的高可用应用到了两个组件，其中一个开源组件是 MHA，它来负责主库的检测和切换。另外一个是自研服务，它用来负责从库的可用性检测和故障时从库的摘除。

然而一旦业务的性能差的 SQL 打到数据库上时，DBA 就须要对这条 SQL 进行解决。目前反对 SQL 限流和 SQL 改写 两种策略。首先，DBA 能够把引发故障的慢 SQL 在治理端上配置流量进入的比例，这样一来该 SQL 就不会再打到数据库上从而引发数据库故障。而后，DBA 还能够在保障语义齐全一样的状况下，在治理端在线对这条 SQL 进行改写，这样一来客户端发往数据库的将是 DBA 优化过的 SQL 了。

2.1.4 全链路压测

可能反对对压测流量中的 SQL 的数据库表名进行动静改写，从而使得压测流量都落到新的数据库表中，而不影响失常业务的数据库表。这样做的益处是，不必再麻烦费劲去搭建一套性能环境进行压测，而是间接应用的线上的物理设施进行压测，因为这样能力更好的压测出性能瓶颈。

2.1.5 就近路由

为了满足高可用的需要,mysql 集群和业务服务器集群个别须要进行多机房 / 多核心部署, 为此会产生跨机房 / 核心拜访的问题。为了均衡跨机房 / 核心拜访带来的提早问题，须要利用机器可能优先拜访部署在同一机房 / 核心的 DB。

2.1.6 故障模拟

业务方有时须要模仿在数据库宕机的状况下服务的可用性。zebra 反对模仿主库 / 从库宕机，以及模仿单个 SQL 执行失败。

2.1.7 SET 化反对

我司外卖业务体量宏大，业务已冲破 1600W/ 天。以后，咱们通过一个大型分布式集群来反对业务，集群外部进行了大量的拆分（数据库、MQ、缓存等），具备了肯定的可扩展性。然而，随着业务量的进一步增长，局部组件的可扩展性遇到了肯定问题。同时，随着集群规模的扩充，须要计算资源越来越多，单 IDC 已不能满足需要，以后架构在 IDC 扩大时，会遇到肯定问题。SET 化性能次要是为了在存储层反对单元化架构。

2.1.8 流量管制

在零碎访问量较大时，某些库的负载可能十分高，或者因为长期故障或零碎 bug 导致大量异样 SQL 打到某个库上。为了避免数据库被这些异样流量打垮，须要在数据库拜访层上对 MySQL 进行爱护，因而 zebra 须要提供对某些特定 SQL 或某个库进行限流的性能。（SQL 限流只是用于长期解决问题，预先还需业务方进行优化或扩容）

2.2 zebra-ds-monitor-client

2.2.1 端到端监控

端到端的监控，一端指的是应用服务器，另一端指的是数据库服务器，一次端到端过程，就是一次残缺的申请响应过程，两头经验两次来回网络的开销。端到端监控之所以重要，因为它最可能主观的反映 SQL 的性能。比起 MySQL 服务端的监控指标，端到端监控还把来回的两次网络开销算了进去。过往的历史教训来看，会经常出现在端到端监控上看到慢查问，但这条慢查问却不可能在 MySQL 服务器上查出，这是因为有可能这条 SQL 在网络上多花了开销，或者在 MySQL 的队列中多期待了一段时间。

因而，端到端的监控是如此的重要！

zebra 应用的是 cat 来进行端到端的监控，也反对把监控指标打到 mtrace 上。在这些监控平台上，能够明确的看到具体的某条 SQL 的性能指标，包含均匀响应工夫、99 线、999 线等。在 CAT 上还可能抓取出慢查问报表通知开发，而后开发对这些慢查问进行优化。

举例来说，上图是 CAT 上 SQL 打点的一个截图，从中能够看到以下信息：

• 从连接池拿到连贯花了 0.01ms(SQL.Conn)
• 整个 SQL(UserProfile.loadUserProfile)的执行开始工夫（15:13:23.010）和 完结工夫（15:13:23.011）
• 这条 SQL 查问的后果为 0 (SQL.Rows)
• 在 dpuser-n1-read 数据库上进行了查问 Select
• 这条 SQL 具体的 SQL 是：SELECT UserID,……，和这条 PreparedStatement 须要的参数是：115522257
• 这条 SQL 总共执行了 1.48ms
• 整个调用链路上 SQL 的地位

2.3 zebra-dao

对 mybatis 的轻量级封装，所有 mybatis 原有的性能都具备，额定提供了异步化接口、分页插件、多数据源等性能。用法实质上就是 mybatis 的用法。

2.3.1 异步化接口

一个服务可能包含 RPC 调用申请、MemCached 申请、KV 存储申请以及 MySQL 数据库调用，目前我司其它三种申请的组件都有异步化的接口，然而数据库调用并没有。所以，在这个状况下，开发了这个异步化的 DAO。目前，公司外部已有多个业务接入应用，曾经承受了线上环境的验证和考验。

2.3.2 分页插件

反对逻辑分页和物理分页

2.3.3 多数据源

反对配置多个数据源，通过注解的形式指应该应用哪个数据源。