sharding sphere4.0 + mybatis-plus 集成

demo地址：https://gitee.com/luci-fast/mybatis-plus-sharding

最近进行技术重构，考虑到服务拆分与分表分库，首先想到了mycat，毕竟mycat是代理，对于代码方面来说，能做到零侵入。 但是了解了一下发现mycat社区活跃度，与一些数据分区难点的解决方案，个人觉得都不是很理想，就又看了sharding sphere.

sharding sphere首先是轻量级的，而且对于java来说，只是多集成jar包，对jdbc，jpa，mybatis都支持，社区活跃度还高，便沉下心来看了几天， 发现代码侵入性真的很低很低，因此把这次集成过程记录下来

组件版本：

springboot 2.1.1

mysql5.7

mybatis-plus 国人开发的mybatis增强工具,集成使用简单，一直关注着，很赞的组件。链接：https://mp.baomidou.com/

shardingsphere jdbc 4.0.4-RC1  4.x版本是加入apache组织后的发布版本，有很多改动。

shardingsphere proxy 最新版本 用于开发运维工具，分表分库以后，对于数据的查询我们很难像单库单表一样迅速定位，简单来说就是， 使用navicat连接 shardingsphere proxy服务，这样就可以很方便直观的操作数据库，因为官方也介绍proxy性能损耗大，适合做运维工具。

shardingsphere官方链接： https://shardingsphere.apache.org/

集成过程

• 1.分库分表依据

  因为架构是基于微服务的，所以每个服务有自己的数据库，根据每个服务的未来理想化的数据进行预估。每张表量在千万以下。
  比如：订单，预计一千亿数据，那么就分为32库，每个库72张表，最终一共两千多张表，一千亿数据平均下来，每张表只有几百亿。
  接下来 我们以订单相关的几张表为例，进行分表分库：订单表  订单明细表 订单字典表 订单子表（一些业务可能会有）
  

• 2.分片相关概念

  逻辑表- 业务逻辑表。  例如：订单表o_order 订单明细表o_order_item  因为量大 都需要分库
  真实表- 真实的数据分片表。 例如：o_order23
  数据节点- 数据分片的最小单元。由数据源名称和数据表组成。例如： odb1.o_order23
  绑定表- 具有数据关联的表，建立绑定关系，则在一个库下，可以进行join。 例如：订单数据与订单明细，如果在一个库下，则可以join查询。
  广播表- 一些静态信息表。 广播分发到每一个数据源，方便查询join。例如：订单字典表。
  不分片表- 不需要分片的表。 例如：订单子表，一些业务订单，可能拆分成子订单，但这种情况少之又少，数据很小，无需分表分库。
  分片键- 进行分表分库的字段。 例如：根据商户id进行分库，根据订单id进行分表。
  分片算法- 例如：商户id取模36得到数据源 订单id取模72得到表
  分片策略- sphere提供了几种策略，这里采用最简单的行表达式
  分布式id- 使用内置的雪花算法，但是workid没有想好在docker环境下如何处理
  分布式事务- 使用内置xa支持
  sql支持与不支持- 请查看官方文档
  路由原理- 请查看官方文档 尤其是带不带分片键的区别
  以上概念均可