云集电商：如何通过 OceanBase 实现降本 87.5%｜OceanBase案例

云集电商，一家聚焦于社交电商的电商公司，专注于‘精选’理念，致力于为会员提供超高性价比的全品类精选商品，以“批发价”让亿万消费者买到质量可靠的商品。面对近年来外部环境的变化，公司对成本控制提出了更高要求，尤其是服务器与人力成本两大领域。当前，服务器成本已占据公司总成本的85%以上，因此，优化成本结构，实现高效降本，已成为我们当前工作的重中之重。

作为 DBA，以更低的成本支撑公司的运营是一项重要的成就；对个人而言，可以学到很多知识和方法论，包括成本分析和评估方法、服务器优化和调整方法、人力成本优化和提升方法等。

业务痛点

在做成本优化前，我们需要对自身业务情况及现有痛点有全局的了解。目前很多互联网公司都面临着架构上的痛点，云集也不例外。如下图所示，最上层的应用层采用微服务架构，增加了一个缓存，这是因为电商场景会有秒杀需求，需要写入很快。

云集主要使用腾讯云上的CDB，业务微服务的架构导致数据库实例数很多。针对每一个微服务的数据库实例，会有基础的一主一从，另外还会有一个用户从库，一般一个系统会对应三个数据库实例。

从中间箭头再往下看，业务数据库通过Flink、Canal等组件输出到大数据以后，会做数据的统计分析，生成T+0、T+1的报表。同时，也会将部分大数据分析的数据同步回业务数据库，供用户查询，形成数据的循环。

右边的话有一个Cloud DB通过OMS到OceanBase的链路，比如有一个订单系统业务，分了32个实例，有个需求是业务需要做整个系统的聚合查询，在原来的分库分表架构下无法实现，因此同步到一个OceanBase集群里面，满足业务查询的需求。以上就是云集现在的整体架构。

那么这个架构存在哪些问题？总的来说，包括四个方面。

第一，数据孤岛。从公司整体角度来看，同一个查询理论上只需要执行一次即可，但由于业务需求不同，无形之中将一份数据在很多存储系统中存储多份。导致请求量放大很多，执行多次。而且数据也存放多份，导致成本上升。

第二，分库分表。分库分表主要依赖于一些中间件，而每个中间件有自己的特点和适用场景，更为关键的是分库分表中间件带来很多问题，需要从业务或运维侧避免:

• 业务侵入，业务需要设计多张表来满足不同的查询需求，所有的查询需求需要围绕分区键，增加了业务复杂度。
• 聚合查询和关联查询变得困难，当出现跨库查询或关联查询时，需要业务将数据收集到应用层进行处理，变得异常困难。
• 运维变得复杂，当需要扩容或缩容时，异常痛苦，需要大量运维操作进行扩容和数据搬迁， 另外当备份和恢复时，也会非常复杂和繁琐。

第三，运营成本，随着微服务进行水平拆分或者垂直拆分，导致数据库实例数大幅增加，资源成本直线升高，另外，每个实例的资源并没有得到充分利用，CPU 利用率未满20%。如果CPU 超过20%，一旦业务波动，服务器就难以支撑，需要预留一定的硬件资源。

第四，数据安全，因等保审核要求，云集需要满足至少两地三中心的容灾水平，这会带来成本的成倍上升。云集在腾讯云上为生产环境做本地备份和远程备份，在远处备份过程中，会遭遇大量运维问题，比如拉取容易失败、拉取耗时过长。另外，因为数据量过大，需要更高的流量，这也导致流量成本大幅上升。

成本优化方案

基于上述架构痛点，我们探索了几种成本优化的方案。

• 业务架构复杂，数据流循环和其他环节冗长，故障概率较高，决定舍弃分库分表架构。
• 在数据治理和数据归档方面，归档服务器存储容量有限，无法满足需求，通过将归档数据转移到OceanBase，利用其数据压缩率高的特性，在节省存储成本的同时，变相扩展容量上限，目前无明显瓶颈。
• 整合业务实例，在保证服务可用的情况下，尽量申请更少的服务器资源；增加服务器资源闲时利用率，比如电商业务主要在白天运行，晚上业务较少的时候就可以生成T0、T1报表数据，充分利用资源。
• 考虑使用具备HTAP特性的分布式数据库替代传统数据库，将在线和分析的业务集中在一套集群中完成，简化数据链路环节，降低业务架构复杂度，减少运维人力。并且在相同业务负载的情况下，发挥分布式数据库高性能的优势，使用更少的机器资源，优化成本。

上述的成本优化方案面临的阻力有哪些呢？

一个新的架构体系需要时间来验证是否能支持现有业务的发展，需要在架构替换前期证明它可以支持业务的发展，并且说服开发团队增加工作量以支持架构改造、学习和适应新技术是值得的。因此，人力和新技术的学习成本是云集架构改造面临的主要阻力。

云集+ OceanBase 的成本优化方案

在整个成本优化过程中，主要考虑了以下几个原则：

• 稳定性强，保证整体业务的稳定和无感知。
• 兼容性高，简化新技术和架构的应用，降低开发难度，减少学习成本。
• 不过度优化，避免因过度优化而降低业务的波动能力。

之所以选择 OceanBase 作为数据存储解决方案，主要是因为：

• OceanBase 与 MySQL 的兼容性，减少开发工作量和版本的稳定性。
• OceanBase 的吞吐量和生态系统的支持良好。
• HTAP 能力和水平扩展能够满足我们的 TP 和 AP 场景的业务需求。

通过引入OceanBase，业务由原来的CDB + ETL + 大数据的架构转变为一套OceanBase集群支撑HTAP业务，减少了数据链路的中间环节，同一套技术栈同时降低开发工作量，通过OceanBase RTO<8s、RPO=0的高可靠性也满足了等保审核的需求，实现了成本上的优化。

总结

本文介绍了基于目前大环境下降本的需要，云集的数据库架构以及使用痛点，探索了实施降本过程中的方案。最终通过引入OceanBase分布式数据库，在满足业务场景的基础上，通过其高性能、高压缩、高可靠、HTAP的特性，为云集节约了机器、存储、人力运维的成本。近几年的大环境变化使得云集业务流量减少了很多，由原来每月的服务器成本峰值达到800多万，降为现在不到100万。

这一成本降低的结果是非常显著的。通过技术的优化和适应环境变化，成功地实现了成本的大幅度减少。这不仅仅是对云集来说，也是对其他企业进行成本优化的一个启示。通过优化技术和适应环境，我们可以有效降低成本，提高效率，获得更好的经济效益。

未来，我们也会不断尝试OceanBase新的特性，比如最新的4.2.1 LTS版本，已经在测试当中，希望OceanBase在云集的业务场景里能带来更大的价值。

原文地址：https://blog.csdn.net/OceanBaseGFBK/article/details/141459609

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！