共计 6251 个字符，预计需要花费 16 分钟才能阅读完成。
作者：zhanlijun\
起源：www.cnblogs.com/LBSer/p/6195309.html
1 为什么要拆分？
先看一段对话。
从下面对话能够看出拆分的理由：
1）利用间耦合重大。零碎内各个利用之间不通，同样一个性能在各个利用中都有实现，结果就是改一处性能，须要同时改零碎中的所有利用。这种状况多存在于历史较长的零碎，因各种起因，零碎内的各个利用都造成了本人的业务小闭环；
2）业务扩展性差。数据模型从设计之初就只反对某一类的业务，来了新类型的业务后又得从新写代码实现，后果就是我的项目延期，大大影响业务的接入速度；
3）代码老旧，难以保护。各种随便的 if else、写死逻辑散落在利用的各个角落，处处是坑，开发保护起来战战兢兢；
4）零碎扩展性差。零碎撑持现有业务已是颤颤巍巍，不论是利用还是 DB 都曾经无奈接受业务疾速倒退带来的压力；
5）新坑越挖越多，恶性循环。不扭转的话，最终的后果就是把零碎做死了。
2 拆前筹备什么?
2.1 多维度把握业务复杂度
一个陈词滥调的问题，零碎与业务的关系？
咱们最冀望的现实状况是第一种关系（车辆与人），业务感觉不适合，能够马上换一辆新的。但事实的状况是更像心脏起搏器与人之间的关系，不是说换就能换。一个零碎接的业务越多，耦合越严密。如果在没有真正把握住业务复杂度之前贸然口头，最终的终局就是把心脏带飞。
如何把握住业务复杂度？须要多维度的思考、实际。
一个是技术层面，通过与 pd 以及开发的探讨，相熟现有各个利用的畛域模型，以及优缺点，这种探讨只能让人有个大略，更多的细节如代码、架构等须要通过做需要、革新、优化这些实际来把握。
各个利用相熟之后，须要从零碎层面来构思，咱们想打造平台型的产品，那么最重要也是最难的一点就是性能集中管控，突破各个利用的业务小闭环，对立收拢，这个信心更多的是开发、产品、业务方、各个团队之间达成的共识，“依照业务或者客户需要组织资源”。
此外也要与业务方放弃性能沟通、打算沟通，确保利用拆分进去后合乎应用需要、扩大需要，获取他们的反对。
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/sn…
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/ca…
https://github.com/alibaba/ot…
增量同步起始获取的 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）借假修真
这个词看上去有点玄乎，顾名思义，就是在借者一些事件，来晋升另外一种能力，前者称为假，后者称为真。在任何一个单位，对外围零碎进行大规模拆分革新的机会很少，因而一旦你承当起责任，就毫不犹豫地全力以赴吧！不要被过程的波折所吓倒，心智的磨砺，才是本真。
另外，关注公众号 Java 技术栈，在后盾回复：面试，能够获取我整顿的 Java 系列面试题和答案，十分齐全。
近期热文举荐：
1.Java 15 正式公布，14 个新个性，刷新你的认知！！
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 我用 Java 8 写了一段逻辑，共事直呼看不懂，你试试看。。
4. 吊打 Tomcat，Undertow 性能很炸！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！