共计 3102 个字符，预计需要花费 8 分钟才能阅读完成。
行业资讯
数据库
DB 分库分表中关于使用框架还是自主开发以及 sharding 实现层面的考量是怎样的
这篇文章将为大家详细讲解有关 DB 分库分表中关于使用框架还是自主开发以及 sharding 实现层面的考量是怎样的，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
当团队对系统业务和数据库进行了细致的梳理，确定了切分方案后，接下来的问题就是如何去实现切分方案了，目前在 sharding 方面有不少的开源框架和产品可供参考，同时很多团队也会选择自主开发实现，而不管是选择框架还是自主开发，都会面临一个在哪一层上实现 sharding 逻辑的问题，丸趣 TV 小编会对这一系列的问题逐一进行分析和考量。
一、sharding 逻辑的实现层面
从一个系统的程序架构层面来看，sharding 逻辑可以在 DAO 层、JDBC API 层、介于 DAO 与 JDBC 之间的 Spring 数据访问封装层 (各种 spring 的 template) 以及介于应用服务器与数据库之间的 sharding 代理服务器四个层面上实现。
图 1. Sharding 实现层面与相关框架 / 产品
在 DAO 层实现
当团队决定自行实现 sharding 的时候，DAO 层可能是嵌入 sharding 逻辑的 *** 位置，因为在这个层面上，每一个 DAO 的方法都明确地知道需要访问的数据表以及查询参数，借助这些信息可以直接定位到目标 shard 上，而不必像框架那样需要对 SQL 进行解析然后再依据配置的规则进行路由。另一个优势是不会受 ORM 框架的制约。由于现在的大多数应用在数据访问层上会依赖某种 ORM 框架，而多数的 shrading 框架往往无法支持或只能支持一种 orm 框架，这使得在选择和应用框架时受到了很大的制约，而自行实现 sharding 完全没有这方面的问题，甚至不同的 shard 使用不同的 orm 框架都可以在一起协调工作。比如现在的 java 应用大多使用 hibernate，但是当下还没有非常令人满意的基于 hibernate 的 sharding 框架，(关于 hibernate hards 会在下文介绍)，因此很多团队会选择自行实现 sharding。
简单总结一下，在 DAO 层自行实现 sharding 的优势在于：不受 ORM 框架的制约、实现起来较为简单、易于根据系统特点进行灵活的定制、无需 SQL 解析和路由规则匹配，性能上表现会稍好一些; 劣势在于：有一定的技术门槛，工作量比依靠框架实现要大(反过来看，框架会有学习成本)、不通用，只能在特定系统里工作。当然，在 DAO 层同样可以通过 XML 配置或是注解将 sharding 逻辑抽离到“外部”，形成一套通用的框架. 不过目前还没有出现此类的框架。
在 ORM 框架层实现
在 ORM 框架层实现 sharding 有两个方向，一个是在实现 O -R Mapping 的前提下同时提供 sharding 支持，从而定位为一种分布式的数据访问框架，这一类类型的框架代表就是 guzz 另一个方向是通过对既有 ORM 框架进行修改增强来加入 sharding 机制。此类型的代表产品是 hibernate shard. 应该说以 hibernate 这样主流的地位，行业对于一款面向 hibernate 的 sharding 框架的需求是非常迫切的，但是就目前的 hibernate shards 来看，表现还算不上令人满意，主要是它对使用 hibernate 的限制过多，比如它对 HQL 的支持就非常有限。在 mybatis 方面，目前还没有成熟的相关框架产生。有人提出利用 mybatis 的插件机制实现 sharding, 但是遗憾的是，mybatis 的插件机制控制不到多数据源的连接层面，另一方面，离开插件层又失去了对 sql 进行集中解析和路由的机会，因此在 mybatis 框架上，目前还没有可供借鉴的框架，团队可能要在 DAO 层或 Spring 模板类上下功夫了。
在 JDBC API 层实现
JDBC API 层是很多人都会想到的一个实现 sharding 的 *** 场所，如果我们能提供一个实现了 sharding 逻辑的 JDBC API 实现，那么 sharding 对于整个应用程序来说就是完全透明的，而这样的实现可以直接作为通用的 sharding 产品了。但是这种方案的技术门槛和工作量显然不是一般团队能做得来的，因此基本上没有团队会在这一层面上实现 sharding, 甚至也没有此类的开源产品。笔者知道的只有一款商业产品 dbShards 采用的是这一方案。
在介于 DAO 与 JDBC 之间的 Spring 数据访问封装层实现
在 springd 大行其道的今天，几乎没有哪个 java 平台上构建的应用不使用 spring，在 DAO 与 JDBC 之间，spring 提供了各种 template 来管理资源的创建与释放以及与事务的同步，大多数基于 spring 的应用都会使用 template 类做为数据访问的入口，这给了我们另一个嵌入 sharding 逻辑的机会，就是通过提供一个嵌入了 sharding 逻辑的 template 类来完成 sharding 工作. 这一方案在效果上与基于 JDBC API 实现的方案基本一致，同样是对上层代码透明，在进行 sharding 改造时可以平滑地过度，但它的实现却比基于 JDBC API 的方式简单，因此成为了不少框架的选择，阿里集团研究院开源的 Cobar Client 就是这类方案的一种实现。
在应用服务器与数据库之间通过代理实现
在应用服务器与数据库之间加入一个代理，应用程序向数据发出的数据请求会先通过代理，代理会根据配置的路由规则，对 SQL 进行解析后路由到目标 shard，因为这种方案对应用程序完全透明，通用性好，所以成为了很多 sharding 产品的选择。在这方面较为知名的产品是 mysql 官方的代理工具：Mysql Proxy 和一款国人开发的产品:amoeba。mysql proxy 本身并没有实现任何 sharding 逻辑，它只是作为一种面向 mysql 数据库的代理，给开发人员提供了一个嵌入 sharding 逻辑的场所，它使用 lua 作为编程语言，这对很多团队来说是需要考虑的一个问题。amoeba 则是专门实现读写分离与 sharding 的代理产品，它使用非常简单，不使用任何编程语言，只需要通过 xml 进行配置。不过 amoeba 不支持事务 (从应用程序发出的包含事务信息的请求到达 amoeba 时，事务信息会被抹去，因此，即使是单点数据访问也不会有事务存在) 一直是个硬伤。当然，这要看产品的定位和设计理念，我们只能说对于那些对事务要求非常高的系统，amoeba 是不适合的。
二、使用框架还是自主开发?
前面的讨论中已经罗列了很多开源框架与产品，这里再整理一下：基于代理方式的有 MySQL Proxy 和 Amoeba，基于 Hibernate 框架的是 Hibernate Shards，通过重写 spring 的 ibatis template 类是 Cobar Client，这些框架各有各的优势与短板，架构师可以在深入调研之后结合项目的实际情况进行选择，但是总的来说，我个人对于框架的选择是持谨慎态度的。一方面多数框架缺乏成功案例的验证，其成熟性与稳定性值得怀疑。另一方面，一些从成功商业产品开源出框架 (如阿里和淘宝的一些开源项目) 是否适合你的项目是需要架构师深入调研分析的。当然，最终的选择一定是基于项目特点、团队状况、技术门槛和学习成本等综合因素考量确定的。
关于 DB 分库分表中关于使用框架还是自主开发以及 sharding 实现层面的考量是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
