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 多数据源
反对配置多个数据源，通过注解的形式指应该应用哪个数据源。