作者：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开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！