共计 5299 个字符，预计需要花费 14 分钟才能阅读完成。
翟扬，中商惠民平台组架构师，参加中台建设 0 到 1 的过程，次要负责交易中台、商品中台、搜寻平台的建设和研发工作。
快消品⾏业传统的经营模式，曾经不能适应新时代的倒退要求，单⼀推动供应链末端的降级，⽆法实现社区商业的⾼品质倒退。中商惠民持续以百万家社区超市订货服务为业务核⼼，从服务批发终端门店转型降级，向推动快消品全产业链数字化转变，构建 B2B2C 数据闭环经营体系，为品牌商、经销商、社区超市提供采、销、营、配全产业链转型降级解决⽅案，继续推动业务摸索和翻新。这⼀切，强⼤的中台零碎功不可没。
交易中台介绍
中商惠民历经⼏次技术迭代，2016 到 2017 年开始 PHP 技术栈转到 Java 技术栈并进⾏微服务化，2018 年开始打造中台。
2021 年年初实现的交易中台⼀期上线，2022 年 3 ⽉实现⼆期上线。
随同着业务成长和多样性的变动，要及时响应新需要，同时要防止对现有业务产⽣影响，本着提⾼⼈效，降低成本的准则，中商惠民推出了强中台倒退策略。对系统⽽⾔，要升高零碎之间的耦合度，减少可扩展性，提取业务共性的同时要保障低提早。在 2021 年之初实现了对之前订单管理系统（OMS）的重构，推出了以订单的交易过程为核⼼的交易中台项⽬，分为以下四个核⼼模块：订单状态流转零碎，订单管理系统，订单履约零碎，订单费⽤计算零碎。同时，基于业务分层，又拆分为订单查问零碎，报表零碎，订单治理后盾等。
在零碎的重构过程中防止技术需要对业务需要产⽣妨碍，上线过程分为两个阶段：应⽤零碎拆分和数据拆分。
零碎拆分
作为业务“重灾区”的订单管理系统，在业务疾速成长的过程中，频繁地对系统作出调整还须要适配多个业务线，会把研发同学搞的焦头烂额，疲惫不堪……基于这些问题，制订以下准则对系统进⾏拆分重构：
- 防止不同业务线解决逻辑耦合，相互牵制和影响，升高逻辑复杂度。
- 依据订单⽣命周期中职责进⾏划分，保障每个零碎畛域独⽴职责单⼀。
- 进⾏读写拆散，保障核⼼性能的稳定性，防止频繁迭代影响核⼼性能。
- 引⼊ ElasticSearch，解决外置索引问题，升高数据库索引压⼒。
数据拆分
数据拆分的⽬的是升高单表保护压⼒，数据量达到千万级别时，数据库表的索引和字段保护都会对线上环境产⽣不⼩的影响。决定对数据表做拆分时，须要⾯临以下⼏个问题：
- 制订拆分准则：什么样的表属于数据密集型？拆分的数量怎么定？
- 数据读写问题：如何解决表拆分后的读写问题？
- 上线⽅案：如何做到平滑上线？
拆分准则
以 3 年作为⼀个迭代周期，拆分数量 =（（每⽉新增的数据量 * 36）+ 历史数据量）/ 单表数据量下限
依据咱们保护阿⾥云 RDS MySQL 的教训来看，基于在使⽤ Innodb 引擎下，进⾏ DDL 操作时，⼩于 500 万数据量，执⾏工夫⼤概⼏⼗秒；⼤于 500 万，⼩于 1000 万数据量，执⾏工夫⼤概 500 秒左右；⼤于 1000 万数据量，⼩于 5000 万左右，执⾏工夫⼤概 1000 多秒；⼤于 5000 万以上数据量，执⾏工夫在 2000 秒以上。
单表调配下限能够取决于单表操作对业务带来的影响，当然也有⼀些⽅案能够解决 DDL 操作锁表的问题，例如双表同步，切换表名的⽅式能够将影响升高为秒级。
库表的拆分数量最好是 2 的 N 次⽅，有利于前期做⽔平扩容。
技术选型
数据表拆分之后，须要解决数据散列和查问问题。作为⼀家中⼩型企业，⾃研⼀套分库分表的中间件老本过⾼，初期还会⾯临各种踩坑的危险，正当的⽅案是采⽤⼀套开源的数据库分库分表的中间件。
Apache ShardingSphere
Apache ShardingSphere 是⼀套开源的分布式数据库解决⽅案组成的⽣态圈，由 JDBC、Proxy 和 Sidecar（布局中）这 3 款既可能独⽴部署，又⽀持混合部署配合使⽤的产品组成，均提供标准化的数据⽔平扩大、分布式事务和分布式治理等性能，可适⽤于如 Java 同构、异构语⾔、云原⽣等各种多样化的应⽤场景。
Apache ShardingSphere 5.x 版本提出 Database Plus 概念。Database Plus 是一种分布式数据库系统的设计理念，通过在碎片化的同构或异构数据库之上搭建应用和交互的规范层和生态层，并叠加扩大更多计算能力，例如数据分片、数据加解密等，使得所有利用和数据库之间的交互面向 Database Plus 构建的规范层，从而屏蔽数据库碎片化对下层业务带来的差异化影响。
新版本开始致⼒于可插拔架构，项⽬的性能组件可能灵便的以可插拔的⽅式进⾏扩大。⽬前，数据分⽚、读写拆散、数据加密、影⼦库压测等性能，以及 MySQL、PostgreSQL、SQL Server、Oracle 等 SQL 与协定的⽀持，均通过插件的⽅式织⼊项⽬，开发者可能像使⽤积⽊⼀样定制属于⾃⼰的独特零碎。Apache ShardingSphere ⽬前已提供数⼗个 SPI 作为零碎的扩大点，仍在一直减少中。
抉择 Apache ShardingSphere 有以下⼏点理由：
- Apache ShardingSphere 性能合乎预期，能够解决⽬前的问题并且有丰盛的扩展性。
- Apache ShardingSphere 社区活跃度⾼，遇到问题会有专⼈及时响应。
- 公司采⽤ SpringCloud 技术栈，集成⽅便，成本低。
- 性能体现参考官⽅⽂档合乎预期，齐全能够⽀撑现有业务。
ShardingSphere ⽀持以下 3 种模式：
公司⽬前服务端技术栈只波及 Java 语⾔，临时不须要思考异构的场景，出于对灵活性、代码侵⼊性和部署老本⽅⾯的综合思考，最终选⽤ ShardingSphere-JDBC 的实现⽅案。
技术实现
过程中最简单的局部其实不是插件集成局部，⽽是上线环节。
上线过程防止被业务团队“投诉”，须要尽可能躲避对终端⽤户产⽣的影响，做到⽆感知并且可回滚，最终咱们将上线过程拆解为以下⼏步，如图所示：
下⾯来解释⼀下这⼏步过程：
第⼀步：解决全量数据的过程，须要保障新⽼库的数据放弃⼀致。因为波及到数据分⽚策略，⽬前市⾯上没有⽀持数据分⽚策略的同步⼯具，这块咱们⾃研了⼀个数据同步⼯具，⽀持配置分⽚策略。
第⼆步：解决增量数据，放弃新旧库的数据⼀致性。此处咱们的实现⽅案是采⽤开源组件 canal 来监听数据库的 binlog，将数据库批改同步到音讯队列，再由数据同步⼯具监听音讯写⼊新库。架构⽅案并不简单，然而这个环节要留神的是数据⼀致性问题，增量数据不能丢数据，同时要管制单⾏数据的程序写⼊，防⽌呈现 ABA 的问题。
第三步：解决读流量灰度上线。依据公司业务的敏感度，进⾏灰度上线，测试读流量是否失常，直⾄实现所有的读流量切换到新库的过程。此时咱们服务的状态对于数据库来讲就是⼀个写⽼库，读新库的状态。此环节要留神的是业务对数据⼀致性的敏感度问题，因为⽼库到新库⼤概是秒级的提早，在局部对⼀致性要求较⾼的敏感场景须要思考读⽼库。
第四步：将应⽤的所有读流量切到新库上，放弃写⽼库读新库的状态。
第五步：解决写流量的过程，为了思考升高程序的复杂度，没有思考灰度公布的场景，当然灰度的⽅案也是能够做到的，此处不过多开展。咱们的做法是将新库数据回写到⽼库，来⽀持回滚策略，而后⼀次公布将所有流量统⼀切到新库。（此⽅案危险较⾼，可能会对⼤⾯积⽤户产⽣影响，尽量在测试环境进⾏充沛评估，须要关注代码覆盖率和性能测试是否达标。）
⾄此就实现了整个公布上线的过程，因为借助了 ShardingSphere-JDBC 中间件对 SQL 改写和后果归并的能⼒实现整个革新的老本不⾼，对代码⼏乎没有侵⼊性，上线过程也⽐较平滑。
另外还有⼀些在接⼊ ShardingSphere-JDBC ⽅案⾥可能须要留神的问题。
- ShardingSphere-JDBC 对于数据插⼊逻辑⾥有个默认解决，在 SQL 内不存在分⽚列进⾏数据插⼊操作时，会导致每个分⽚表都插⼀条雷同的数据。
- ShardingSphere-JDBC 对于批量的 SQL 语义剖析时，只会解析第⼀条 SQL 的逻辑表，会导致执⾏报错。这个问题曾经反馈给官⽅，近期应该会修复此问题。另外官⽅也提供了具体的 SQL 示例，具体列举了哪些在⽀持的范畴内，开发之前须要具体的浏览⽂档。
- ShardingSphere-JDBC 连贯模式的抉择。
从资源管制的角度看，业务⽅拜访数据库的连贯数量该当有所限度。它可能无效地防⽌某⼀业务操作过多的占⽤资源，从⽽将数据库连贯的资源耗尽，以至于影响其余业务的失常拜访。特地是在⼀个数据库实例中存在较多分表的状况下，⼀条不蕴含分⽚键的逻辑 SQL 将产⽣落在同库不同表的⼤量实在 SQL，如果每条实在 SQL 都占⽤⼀个独⽴的连贯，那么⼀次查问⽆疑将会占⽤过多的资源。
从执⾏效率的角度看，为每个分⽚查问维持⼀个独⽴的数据库连贯，能够更加无效的利⽤多线程来晋升执⾏效率。为每个数据库连贯开启独⽴的线程，能够将 I/O 所产⽣的耗费并⾏解决，为每个分⽚维持⼀个独⽴的数据库连贯，还可能防止过早的将查问后果数据加载⾄内存。独⽴的数据库连贯，可能持有查问后果集游标位置的引⽤，在须要获取相应数据时挪动游标即可。
以后果集游标下移进⾏后果归并的⽅式，称之为流式归并，它⽆需将后果数据全数加载⾄内存，能够无效的节俭内存资源，进⽽缩小垃圾回收的频次。当⽆法保障每个分⽚查问持有⼀个独⽴数据库连贯时，则须要在复⽤该数据库连贯获取下⼀张分表的查问后果集之前，将以后的查问后果集全数加载⾄内存。因而，即便能够采⽤流式归并，在此场景下也将进化为内存归并。
⼀⽅⾯是对数据库连贯资源的管制爱护，⼀⽅⾯是采⽤更优的归并模式达到对中间件内存资源的节俭，如何解决好两者之间的关系，是 ShardingSphere 执⾏引擎须要解决的问题。具体来说，如果⼀条 SQL 在通过 ShardingSphere 的分⽚后，须要操作某数据库实例下的 200 张表。那么，是抉择创立 200 个连贯并⾏执⾏，还是抉择创立⼀个连贯串⾏执⾏呢？效率与资源管制又应该如何抉择呢？
针对上述场景，ShardingSphere 提供了⼀种解决思路。它提出了连贯模式（Connection Mode）的概念，将其划分为内存限度模式（MEMORY_STRICTLY）和连贯限度模式（CONNECTION_STRICTLY）这两种类型。
内存限度模式
使⽤此模式的前提是，ShardingSphere 对⼀次操作所消耗的数据库连贯数量不做限度。如果理论执⾏的 SQL 须要对某数据库实例中的 200 张表做操作，则对每张表创立⼀个新的数据库连贯，并通过多线程的⽅式并发解决，以达成执⾏效率最⼤化。并且在 SQL 满⾜条件状况下，优先选择流式归并，以防⽌呈现内存溢出或防止频繁垃圾回收状况。
连贯限度模式
使⽤此模式的前提是，ShardingSphere 严格控制对⼀次操作所消耗的数据库连贯数量。如果理论执⾏的 SQL 须要对某数据库实例中的 200 张表做操作，那么只会创立唯⼀的数据库连贯，并对其 200 张表串⾏解决。如果⼀次操作中的分⽚散落在不同的数据库，依然采⽤多线程解决对不同库的操作，但每个库的每次操作依然只创立⼀个唯⼀的数据库连贯。这样即可以防⽌对⼀次申请对数据库连贯占⽤过多所带来的问题。该模式始终抉择内存归并。
内存限度模式适⽤于 OLAP 操作，能够通过放宽对数据库连贯的限度晋升零碎吞吐量；连贯限度模式适⽤于 OLTP 操作，OLTP 通常带有分⽚键，会路由到单⼀的分⽚，因而严格控制数据库连贯，以保障在线零碎数据库资源可能被更多的应⽤所使⽤，是理智的抉择。
咱们发现在内存限度模式下，过程中会因为 MySQL 的 innodb 引擎的 cache buffer 加载策略导致操作变为 io 密集型，导致 SQL ⼤量超时，解决此问题的方法就是在不变更数据库资源的状况下咱们程序多⼀层解决，如果发现没有分⽚键的时候，先在外置索引中确认⼀下分⽚键，再通过分⽚键来进⾏数据库检索。
价值收益
- 性能晋升
通过架构重构，无效管制单表数据量，⼤幅缩减慢 SQL，降落将近 50%。
- 节俭研发资源，降低成本
引⼊成熟的 Apache ShardingSphere ⽆需从新开发分表组件，升高了研发和踩坑的老本，研发同学只须要集中精⼒解决业务问题。
- 丰盛的扩展性
Apache ShardingSphere 对于数据加密，分布式事务，影⼦库等⽅⾯都具备良好的扩展性。
写到最初
在纽曼（Sam Newman）的《微服务设计》⼀书中已经写到：“与建造建筑物相⽐，在软件中咱们会⾯临⼤量的需要变更，使⽤的⼯具和技术也具备多样性。咱们发明的货色并不是在某个工夫点之后就不再变动了，甚⾄在公布到⽣产环境之后，软件还能持续演变。对于咱们发明的⼤少数产品来说，交付到客户⼿⾥之后，还是要响应客户的变更需要，⽽不是简略地交给客户⼀个⼀成不变的软件包。因而架构师必须扭转那种从⼀开始就要设计出完满产品的想法，相同咱们应该设计出⼀个正当的框架，在这个框架下能够缓缓演化出正确的零碎，并且⼀旦咱们学到了更多常识，应该能够很容易地应⽤到零碎中。”Apache ShardingSphere 正是这样⼀款极具潜⼒的产品，将来⼀定可期。
欢送增加社区经理微信（ss_assistant_1）退出交换群，与泛滥 ShardingSphere 爱好者一起交换。
