蜂巢（已更名为网易云计算基础服务）计费系统架构升级之路

本文链接：https://blog.csdn.net/jessicaiu/article/details/84337113

本文讲述了网易蜂巢计费系统从项目背景、业务拆分到多Region支持的架构升级过程。面对技术债务，团队进行了模块独立、系统独立的拆分，解决了代码混乱和维护性问题。在多Region支持上，经历了摸着石头过河的阶段，最终通过数据库优化和代理组件RegionProxy实现了稳定架构。通过引入Apollo管理和Elastic-Job替换原有框架，提升了系统的可维护性和效率。

摘要由CSDN通过智能技术生成

欢迎访问网易云社区，了解更多网易技术产品运营经验。

项目背景

蜂巢计费系统为网易云计算基础服务（网易蜂巢）提供整体的计费服务，业务范围涵盖完整的产品售卖流程，包含定价、订单、支付、计费、结算、优惠、账单等主体功能，支持十几种不同产品的售卖，产品形态上贯穿了IaaS、PaaS和SaaS类别。同时，计费方式还提供了了按量、包年包月、资源包等多种方式。该项目的业务范围之广，玩法种类之多，数据要求之严注定了它将成为一个烫手的山芋，而且还是一个吃力不讨好的工作。

该项目在人员上已经几经易手，就我所知，已经换过两拨完整的开发和测试团队了，而且已经全部离职。不得不说，该项目已经变得令人谈之色变，让人敬而远之。在这样的背景下，后期接手的开发和QA不得不硬着头皮上，踩着雷过河，小心翼翼的应对着不断涌来的业务需求。随之而来的是高居不下的bug率，越来越难以维护的代码，无法扩展的架构问题，我们开始意识到这样下去是不行的。于是我们从8月份开始了漫漫的架构升级之路。

重新出发

在我们开始优化架构之前，我们重新梳理了计费系统完整的业务，得到了如下图所示的业务领域：

梳理以后发现，计费系统承载了太多非计费的业务，包含订单、账单、结算和代金券等，这些业务代码散落在各处，没有严格地业务边界划分，而是“奇迹般”的融合在了一个工程里面。造成这个局面的原因在于计费系统初版设计时，根本没有考虑到这些问题，当然也不可能考虑到，而在后面逐步地迭代过程中，也未能去及时地调整架构，架构腐化不是一天内完成的。当然，这方面有部分技术的原因，也有部分人为的原因所在，因为当时负责计费系统的开发就只有一人，还是刚毕业的同学。目前看来，也是难为这位同学了。

技术债务的问题不是小事，千里之堤毁于蚁穴。既然我们找到了问题的症结所在，那么解决的方式也就显而易见了，一个字：拆！我们分析了所有的业务，订单是最大也是最复杂的一个业务，而结算和账单考虑到后期有可能迁移到云支付团队，我们决定优先把订单系统拆分出去！