⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/LBSer/p/6195309.html 「zhanlijun」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

1 为什么要拆分？

先看一段对话。

从上面对话可以看出拆分的理由：

1） 应用间耦合严重。系统内各个应用之间不通，同样一个功能在各个应用中都有实现，后果就是改一处功能，需要同时改系统中的所有应用。这种情况多存在于历史较长的系统，因各种原因，系统内的各个应用都形成了自己的业务小闭环；

2） 业务扩展性差。数据模型从设计之初就只支持某一类的业务，来了新类型的业务后又得重新写代码实现，结果就是项目延期，大大影响业务的接入速度；

3） 代码老旧，难以维护。各种随意的if else、写死逻辑散落在应用的各个角落，处处是坑，开发维护起来战战兢兢；

4） 系统扩展性差。系统支撑现有业务已是颤颤巍巍，不论是应用还是DB都已经无法承受业务快速发展带来的压力；

5） 新坑越挖越多，恶性循环。不改变的话，最终的结果就是把系统做死了。

2 拆前准备什么?

2.1 多维度把握业务复杂度

一个老生常谈的问题，系统与业务的关系？

我们最期望的理想情况是第一种关系（车辆与人），业务觉得不合适，可以马上换一辆新的。但现实的情况是更像心脏起搏器与人之间的关系，不是说换就能换。一个系统接的业务越多，耦合越紧密。如果在没有真正把握住业务复杂度之前贸然行动，最终的结局就是把心脏带飞。

如何把握住业务复杂度？需要多维度的思考、实践。

一个是技术层面，通过与pd以及开发的讨论，熟悉现有各个应用的领域模型，以及优缺点，这种讨论只能让人有个大概，更多的细节如代码、架构等需要通过做需求、改造、优化这些实践来掌握。

各个应用熟悉之后，需要从系统层面来构思，我们想打造平台型的产品，那么最重要也是最难的一点就是功能集中管控，打破各个应用的业务小闭环，统一收拢，这个决心更多的是开发、产品、业务方、各个团队之间达成的共识，可以参考《微服务（Microservice）那点事》一文，“按照业务或者客户需求组织资源”。

此外也要与业务方保持功能沟通、计划沟通，确保应用拆分出来后符合使用需求、扩展需求，获取他们的支持。

2.2 定义边界，原则：高内聚，低耦合，单一职责！

业务复杂度把握后，需要开始定义各个应用的服务边界。怎么才算是好的边界？像葫芦娃兄弟一样的应用就是好的！

举个例子，葫芦娃兄弟（应用）间的技能是相互独立的，遵循单一职责原则，比如水娃只能喷水，火娃只会喷火，隐形娃不会喷水喷火但能隐身。更为关键的是，葫芦娃兄弟最终可以合体为金刚葫芦娃，即这些应用虽然功能彼此独立，但又相互打通，最后合体在一起就成了我们的平台。

这里很多人会有疑惑，拆分粒度怎么控制？很难有一个明确的结论，只能说是结合业务场景、目标、进度的一个折中。但总体的原则是先从一个大的服务边界开始，不要太细，因为随着架构、业务的演进，应用自然而然会再次拆分，让正确的事情自然发生才最合理。

2.3 确定拆分后的应用目标

一旦系统的宏观应用拆分图出来后，就要落实到某一具体的应用拆分上了。

首先要确定的就是某一应用拆分后的目标。拆分优化是没有底的，可能越做越深，越做越没结果，继而又影响自己和团队的士气。比如说可以定这期的目标就是将db、应用分拆出去，数据模型的重新设计可以在第二期。

2.4 确定当前要拆分应用的架构状态、代码情况、依赖状况，并推演可能的各种异常。

动手前的思考成本远远低于动手后遇到问题的解决成本。应用拆分最怕的是中途说“他*的，这块不能动，原来当时这样设计是有原因的，得想别的路子！”这时的压力可想而知，整个节奏不符合预期后，很可能会接二连三遇到同样的问题，这时不仅同事们士气下降，自己也会丧失信心，继而可能导致拆分失败。

2.5 给自己留个锦囊，“有备无患”。

锦囊就四个字“有备无患”，可以贴在桌面或者手机上。在以后具体实施过程中，多思考下“方案是否有多种可以选择？复杂问题能否拆解？实际操作时是否有预案？”，应用拆分在具体实践过程中比拼得就是细致二字，多一份方案，多一份预案，不仅能提升成功概率，更给自己信心。

2.6 放松心情，缓解压力

收拾下心情，开干！

3 实践

3.1 db拆分实践

DB拆分在整个应用拆分环节里最复杂，分为垂直拆分和水平拆分两种场景，我们都遇到了。垂直拆分是将库里的各个表拆分到合适的数据库中。比如一个库中既有消息表，又有人员组织结构表，那么将这两个表拆分到独立的数据库中更合适。

水平拆分：以消息表为例好了，单表突破了千万行记录，查询效率较低，这时候就要将其分库分表。

3.1.1 主键id接入全局id发生器

DB拆分的第一件事情就是使用全局id发生器来生成各个表的主键id。为什么？

举个例子，假如我们有一张表，两个字段id和token，id是自增主键生成，要以token维度来分库分表，这时继续使用自增主键会出现问题。

正向迁移扩容中，通过自增的主键，到了新的分库分表里一定是唯一的，但是，我们要考虑迁移失败的场景，如下图所示，新的表里假设已经插入了一条新的记录，主键id也是2，这个时候假设开始回滚，需要将两张表的数据合并成一张表（逆向回流），就会产生主键冲突！

因此在迁移之前，先要用全局唯一id发生器生成的id来替代主键自增id。这里有几种全局唯一id生成方法可以选择。

1）snowflake：https://github.com/twitter/snowflake；（非全局递增）

2） mysql新建一张表用来专门生成全局唯一id（利用auto_increment功能）（全局递增）；

3）有人说只有一张表怎么保证高可用？那两张表好了（在两个不同db），一张表产生奇数，一张表产生偶数。或者是n张表，每张表的负责的步长区间不同（非全局递增）

4）……

我们使用的是阿里巴巴内部的tddl-sequence（mysql+内存），保证全局唯一但非递增，在使用上遇到一些坑：

1）对按主键id排序的sql要提前改造。因为id已经不保证递增，可能会出现乱序场景，这时候可以改造为按gmt_create排序；

2）报主键冲突问题。这里往往是代码改造不彻底或者改错造成的，比如忘记给某一insert sql的id添加#{}，导致继续使用自增，从而造成冲突；

3.1.2 建新表&迁移数据&binlog同步

1）新表字符集建议是utf8mb4，支持表情符。新表建好后索引不要漏掉，否则可能会导致慢sql！从经验来看索引被漏掉时有发生，建议事先列计划的时候将这些要点记下，后面逐条检查；

2）使用全量同步工具或者自己写job来进行全量迁移；全量数据迁移务必要在业务低峰期时操作，并根据系统情况调整并发数；

3）增量同步。全量迁移完成后可使用binlog增量同步工具来追数据，比如阿里内部使用精卫，其它企业可能有自己的增量系统，或者使用阿里开源的cannal/otter：https://github.com/alibaba/canal?spm=5176.100239.blogcont11356.10.5eNr98

https://github.com/alibaba/otter/wiki/QuickStart?spm=5176.100239.blogcont11356.21.UYMQ17

增量同步起始获取的binlog位点必须在全量迁移之前，否则会丢数据，比如我中午12点整开始全量同步，13点整全量迁移完毕，那么增量同步的binlog的位点一定要选在12点之前。

位点在前会不会导致重复记录？不会！线上的MySQL binlog是row 模式，如一个delete语句删除了100条记录，binlog记录的不是一条delete的逻辑sql，而是会有100条binlog记录。insert语句插入一条记录，如果主键冲突，插入不进去。

3.1.3 联表查询sql改造

现在主键已经接入全局唯一id，新的库表、索引已经建立，且数据也在实时追平，现在可以开始切库了吗？no！

考虑以下非常简单的联表查询sql，如果将B表拆分到另一个库里的话，这个sql怎么办？毕竟跨库联表查询是不支持的！

因此，在切库之前，需要将系统中上百个联表查询的sql改造完毕。

如何改造呢？

1） 业务避免

业务上松耦合后技术才能松耦合，继而避免联表sql。但短期内不现实，需要时间沉淀；

2） 全局表

每个应用的库里都冗余一份表，缺点：等于没有拆分，而且很多场景不现实，表结构变更麻烦；

3） 冗余字段

就像订单表一样，冗余商品id字段，但是我们需要冗余的字段太多，而且要考虑字段变更后数据更新问题；

4） 内存拼接

4.1）通过RPC调用来获取另一张表的数据，然后再内存拼接。1）适合job类的sql，或改造后RPC查询量较少的sql；2）不适合大数据量的实时查询sql。假设10000个ID，分页RPC查询，每次查100个，需要5ms，共需要500ms，rt太高。

4.2）本地缓存另一张表的数据

适合数据变化不大、数据量查询大、接口性能稳定性要求高的sql。

3.1.4切库方案设计与实现（两种方案）

以上步骤准备完成后，就开始进入真正的切库环节，这里提供两种方案，我们在不同的场景下都有使用。

a）DB停写方案

优点：快，成本低；

缺点：

1）如果要回滚得联系DBA执行线上停写操作，风险高，因为有可能在业务高峰期回滚；

2）只有一处地方校验，出问题的概率高，回滚的概率高

举个例子，如果面对的是比较复杂的业务迁移，那么很可能发生如下情况导致回滚：

sql联表查询改造不完全；

sql联表查询改错&性能问题；

索引漏加导致性能问题；

字符集问题

此外，binlog逆向回流很可能发生字符集问题（utf8mb4到gbk），导致回流失败。这些binlog同步工具为了保证强最终一致性，一旦某条记录回流失败，就卡住不同步，继而导致新老表的数据不同步，继而无法回滚！

b）双写方案

第2步“打开双写开关，先写老表A再写新表B”，这时候确保写B表时try catch住，异常要用很明确的标识打出来，方便排查问题。第2步双写持续短暂时间后（比如半分钟后），可以关闭binlog同步任务。

优点：

1）将复杂任务分解为一系列可测小任务，步步为赢；

2）线上不停服，回滚容易；

3）字符集问题影响小

缺点：

1）流程步骤多，周期长；

2）双写造成RT增加

3.1.5 开关要写好

不管什么切库方案，开关少不了，这里开关的初始值一定要设置为null！

如果随便设置一个默认值，比如”读老表A“，假设我们已经进行到读新表B的环节了。这时重启了应用，在应用启动的一瞬间，最新的“读新表B”的开关推送等可能没有推送过来，这个时候就可能使用默认值，继而造成脏数据！

3.2 拆分后一致性怎么保证？

以前很多表都在一个数据库内，使用事务非常方便，现在拆分出去了，如何保证一致性？

1）分布式事务

性能较差，几乎不考虑。

2）消息机制补偿（如何用消息系统避免分布式事务？）

3）定时任务补偿

用得较多，实现最终一致，分为加数据补偿，删数据补偿两种。

3.3 应用拆分后稳定性怎么保证？

一句话：怀疑第三方，防备使用方，做好自己！

1 ）怀疑第三方**

a）防御式编程，制定好各种降级策略；

比如缓存主备、推拉结合、本地缓存……

b）遵循快速失败原则，一定要设置超时时间，并异常捕获；

c）强依赖转弱依赖，旁支逻辑异步化

我们对某一个核心应用的旁支逻辑异步化后，响应时间几乎缩短了1/3，且后面中间件、其它应用等都出现过抖动情况，而核心链路一切正常；

d）适当保护第三方，慎重选择重试机制

2 ）防备使用方

a）设计一个好的接口，避免误用

遵循接口最少暴露原则；很多同学搭建完新应用后会随手暴露很多接口，而这些接口由于没人使用而缺乏维护，很容易给以后挖坑。听到过不只一次对话，”你怎么用我这个接口啊，当时随便写的，性能很差的“；
不要让使用方做接口可以做的事情；比如你只暴露一个getMsgById接口，别人如果想批量调用的话，可能就直接for循环rpc调用，如果提供getMsgListByIdList接口就不会出现这种情况了。
避免长时间执行的接口；特别是一些老系统，一个接口背后对应的可能是for循环select DB的场景。
…

b）容量限制

按应用优先级进行流控；不仅有总流量限流，还要区分应用，比如核心应用的配额肯定比非核心应用配额高；
业务容量控制。有些时候不仅仅是系统层面的限制，业务层面也需要限制。举个例子，对saas化的一些系统来说，”你这个租户最多1w人使用“。

3**）做好自己**

a）单一职责

b）及时清理历史坑

例：例如我们改造时候发现一年前留下的坑，去掉后整个集群cpu使用率下降1/3

c） 运维SOP化

说实话，线上出现问题，如果没有预案，再怎么处理都会超时。曾经遇到过一次DB故障导致脏数据问题，最终只能硬着头皮写代码来清理脏数据，但是时间很长，只能眼睁睁看着故障不断升级。经历过这个事情后，我们马上设想出现脏数据的各种场景，然后上线了三个清理脏数据的job，以防其它不可预知的产生脏数据的故障场景，以后只要遇到出现脏数据的故障，直接触发这三个清理job，先恢复再排查。

d）资源使用可预测

应用的cpu、内存、网络、磁盘心中有数
- 正则匹配耗cpu
- 耗性能的job优化、降级、下线（循环调用rpc或sql）
- 慢sql优化、降级、限流
- tair/redis、db调用量要可预测
- 例：tair、db

举个例子: 某一个接口类似于秒杀功能，qps非常高（如下图所示），请求先到tair，如果找不到会回源到DB，当请求突增时候，甚至会触发tair/redis这层缓存的限流，此外由于缓存在一开始是没数据的，请求会穿透到db，从而击垮db。

这里的核心问题就是tair/redis这层资源的使用不可预测，因为依赖于接口的qps，怎么让请求变得可预测呢？

如果我们再增加一层本地缓存（guava，比如超时时间设置为1秒），保证单机对一个key只有一个请求回源，那样对tair/redis这层资源的使用就可以预知了。假设有500台client，对一个key来说，一瞬间最多500个请求穿透到Tair/redis，以此类推到db。

再举个例子：

比如client有500台，对某key一瞬间最多有500个请求穿透到db，如果key有10个，那么请求最多可能有5000个到db，恰好这些sql的RT有些高，怎么保护DB的资源？

可以通过一个定时程序不断将数据从db刷到缓存。这里就将不可控的5000个qps的db访问变为可控的个位数qps的db访问。

4 总结

1 ）做好准备面对压力！

2 ）复杂问题要拆解为多步骤，每一步可测试可回滚！

这是应用拆分过程中的最有价值的实践经验！

3 ）墨菲定律：你所担心的事情一定会发生，而且会很快发生，所以准备好你的SOP**（标准化解决方案）！**

某个周五和组里同事吃饭时讨论到某一个功能存在风险，约定在下周解决，结果周一刚上班该功能就出现故障了。以前讲小概率不可能发生，但是概率再小也是有值的，比如p=0.00001%，互联网环境下，请求量足够大，小概率事件就真发生了。

4 ）借假修真

这个词看上去有点玄乎，顾名思义，就是在借者一些事情，来提升另外一种能力，前者称为假，后者称为真。在任何一个单位，对核心系统进行大规模拆分改造的机会很少，因此一旦你承担起责任，就毫不犹豫地全力以赴吧！不要被过程的曲折所吓倒，心智的磨砺，才是本真。

芋道源码 —— 纯源码解析博客

一个复杂系统的拆分改造实践