网易计费系统架构升级之路.docxVIP

网易计费系统架构升级之路 2021-08-17 更多内容关注：fullstack888 项目背景 网易蜂巢计费系统为网易云计算基础服务供应全体的计费服务，业务范围涵盖完整的产品售卖流程，包含定价、订单、领取、计费、结算、优待、账单等主体功能，支持十几种不同产品的售卖，产品外形上贯穿了IaaS、PaaS和SaaS类别。同时，计费方式还供应了了按量、包年包月、资源包等多种方式。该项目的业务范围之广，玩法品种之多，数据要求之严注定了它将成为一个烫手的山芋，而且还是一个费劲不讨好的工作。 该项目在人员上已经几经易手，就我所知，已经换过两拨完整的开发和测试团队了，而且已经全部离职。不得不说，该项目已经变得令人谈之色变，让人敬而远之。在这样的背景下，后期接手的开发和QA不得不硬着头皮上，踩着雷过河，当心翼翼的应对着不断涌来的业务需求。随之而来的是高居不下的bug率，越来越难以维护的代码，无法扩展的架构问题，我们开头意识到这样下去是不行的。于是我们从8月份开头了漫漫的架构升级之路。 重新动身 在我们开头优化架构之前，我们重新梳理了计费系统完整的业务，得到了如下图所示的业务领域： 梳理以后发觉，计费系统承载了太多非计费的业务，包含订单、账单、结算和代金券等，这些业务代码散落在各处，没有严格地业务边界划分，而是“奇观般”的融合在了一个工程里面。形成这个局面的缘由在于计费系统初版设计时，根本没有考虑到这些问题，当然也不行能考虑到，而在后面逐渐地迭代过程中，也未能去准时地调整架构，架构腐化不是一天内完成的。当然，这方面有部分技术的缘由，也有部分人为的缘由所在，由于当时担任计费系统的开发就只要一人，还是刚毕业的同学。目前看来，也是难为这位同学了。 技术债务的问题不是小事，千里之堤毁于蚁穴。既然我们找到了问题的症结所在，那么处理的方式也就显而易见了，一个字：拆！我们分析了全部的业务，订单是最大也是最简单的一个业务，而结算和账单考虑到后期有可能迁移到云领取团队，我们打算优先把订单系统拆分出去！ 拆分的阵痛 订单拆分说起来简约，做起来难。套用一句业界常说的话，就是开着飞机换轮胎。由于在我们拆分的同时，不断地有新的业务需求进来，还有一些bug需要处理，所以不太可能让我们特地进行拆分的工作。因而，为了不影响正常的业务迭代，我们打算拉出独立分支进行开发。我们分出两人特地处理拆分的工作。 为了最小化风险，订单拆分我们分了两步进行：一，模块独立；二：系统独立。 模块独立 模块独立是将订单的代码首先在工程内部独立出来，我们接受独立Module的方式，将订单独立成了一个Order的模块。它拥有完全独立的服务层、业务层以及长久化层。其他模块可以依靠Order，而Order不能依靠除公共模块外的其他业务模块。全体的模块划分如下图所示。模块的拆分过程中我们也发觉了原先很多不合理的地方，例如：其他服务直接操作订单的长久化层(DAO)、模块直接依靠关系混乱、Service所在的Pacakge不合理、存在大量无用的代码和规律、任凭的命名等。我们边拆分边重构，虽然进度比预期要缓慢一些，但全体上在向着合理的方向进行。 模块独立的过程中我们遇到了业务层级关系的问题。由于订单模块不再依靠于其他业务模块，而又有一些业务规律是由订单触发的，需要在计费模块完成，我们又不能直接调用计费模块的Service。针对这个问题，我们接受了领域大事的方式来解耦，简约来说就是订单通过发布大事的方式来与其他模块进行通信，当时实现的代码其实也相当简约。 我们并没有独立拆分web层，由于系统还没有独立，web层作为统一的打包入口也承载着订单的流量。而且，Controller层的规律相对比较简约，完全可以在系统独立时再做。通过大家的努力，8月底订单已独立模块的方式上线了，一切正常。 系统独立 模块拆分完成后，紧接着就是系统独立，此时我们需要将订单系统独立部署。这里一个关键的问题是，独立部署意味着单独供应服务，而依靠订单系统的业务方格外之多，包含前端、主站、大部分的PaaS业务和计费，都有需要直接依靠订单接口的地方，贸然独立风险很大。针对这个问题，我们接受使用haproxy七层转发代理来将流量分发到不同的vip来处理。虽然，在上线过程中遇到了一些坎坷，但最终还是成功了。现在看来这个选择是格外对的，由于这样可以在业务方无感知的情况下平滑升级。但长远来看，最终我们还是以独立的vip对外保留服务。 订单和计费直接我们接受RabbitMQ来完成主体通信，关于接受MQ还是HTTP调用我们内部还进行了一番争辩。之所以最终还是接受MQ来进行通信，是由于我们发觉很多业务流程并不需要计费系统马上响应（大部分流程都是订单触发的），也就是我们常说的弱依靠。另外，职责上计费系统的响应的质量也不应影响到订单的主体流程，举个例子：用