网易计费系统架构升级之路
共 7546字,需浏览 16分钟
·
2021-08-18 20:49
项目背景
网易蜂巢计费系统为网易云计算基础服务提供整体的计费服务,业务范围涵盖完整的产品售卖流程,包含定价、订单、支付、计费、结算、优惠、账单等主体功能,支持十几种不同产品的售卖,产品形态上贯穿了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来进行通信,是因为我们发现很多业务流程并不需要计费系统立即响应(大部分流程都是订单触发的),也就是我们常说的弱依赖。另外,职责上计费系统的响应的质量也不应影响到订单的主体流程,举个例子:用户支付了一个云主机的订单,如果计费系统此时无法响应,业务上相对来说可以接受过一小会儿计费再处理,而不是把订单直接退款给用户。MQ的引入在技术和职责层面都将订单和计费分的更开了。当然,强依赖的服务是我们无法避免的,其中之一就是结算模块还留在计费中,订单需要通过接口调用结算服务来完成支付。
前期,我们在模块独立时采用事件解耦的方式,在此时也获得了收获。我们通过一个统一的转化层,将那些事件直接转化层RabbitMQ可以识别的消息,这样代码的改造工作就大大减少了。
系统独立后一个直接的表象就是每个系统的代码行数大大降低了。独立前,整体的代码行数已经达到了12W行以上(包含配置文件),独立后,计费系统降低到了10W以下,订单维持在4W以下。代码行数的降低将直接提高系统的可维护性。个人认为如果一个工程里的代码超过10W行,那么维护性将大大降低,除非是那些有着严格自律意识的团队,否则,我建议还是尽量降低代码行数。
经过大家一个月的努力,订单系统终于已独立的姿态提供服务了。过程很艰辛,但是收获良多。
拆分的收获
订单独立后,一个直接的好处就是我们能独立的思考问题了,这在以前是很难做到的一件事情,因为大家不得不小心翼翼的处理那些依赖,做事会畏手畏脚的。另外一个好处就是,我们的工作可以有侧重点的进行了。订单业务可以说是产品最为关注的业务,也是计费对外暴露的主要入口。下图就是我们在拆分后规划订单的业务架构,大家对后期的订单规划充满期待。
多Region的挑战
公有云产商面临的一大挑战就是多Region环境的支持。普通的互联网行业出于高可用的考虑,往往会把核心系统部署到多个机房,然后根据自己的实际应用场景选择冷备、双活甚至三活。我们经常听到的“两地三中心”、“三地五中心”等等高大上的名词就是多机房高可用的缩影。这些行业做多机房部署的主要目的是为了提高系统的可用性,不是其业务的必须属性。换句话说,他们不做多机房部署也可以,做了当然更好。而公有云产商不一样,多Region部署就是其行业属性之一。如果哪个云产商不提供多region产品的支持,那么它肯定是不完整的。不得不承认,我们在这方面的经验是比较欠缺的,在多Region的支持上走了一些弯路。
摸着石头过河
今年上半年的时候,蜂巢开始计划启动北京Region,预计年中交付,当时对我们横向业务提出了很大的技术挑战。一是在于横向系统设计之初并没有考虑到对Region环境的支持,我们很被动;二是我们并没有跨Region系统设计的经验,我们很着急。计费系统面临的问题更加严重,因为它对数据的一致性要求更高,而且出错的影响范围也更大。而且当时计费的技术债务已经很高了,产品的需求列表也拍了很长,套用一句很形象的话说,“留给我们的时间不多了”。
在这种情况下,我们“胆战心惊”的给出了第一版的多Region设计方案,主体架构如下所示:
因为当时计费系统还没有拆分,所有的业务都在一个系统中完成的,就是我们常说的“大泥球”系统。这种情况下我们很难做到多Region部署,订单和账单其实只有在一个Region部署就可以了,而计费的数据采集和请求分发是要下沉到各个Region的,而计算过程可以集中完成。采用"双主"同步复制的方案实则是无奈之举。数据库的同步只能基于实例级别,而无法细分到表,我们各Region中计费数据库中存在资源的计量表,这个数据需要同步到杭州Region来完成。为了避免“脑裂”的问题,我们特别将该表的主键采用UUID的形式。存量表因为无法做大规模修改,我们通过限制北京MySQL用户的权限来避免写入和修改全局表。
这个设计很糟糕,但是当时的条件限制,我们也拿不出更好的设计了。虽然上线的过程有些曲折,这个架构还是成功运行了,这是令我们最为欣慰的事情。因为为了适配这个架构,团队的小伙伴做了很多工作。不可否认,这个架构存在诸多弊端,其中最大的隐患就在于数据库的“双主”同步,这就像一颗随时会爆的炸弹萦绕在我们心头。当时专线还没有搭建好,所有的流量均通过外网隧道代理,糟糕的网络质量无疑放大了这个风险。为此,DBA们向我们吐槽了好久,幸好我们抗打击能力很强。
涅槃重生
在做完双Region的支持以后,计费团队就继续做产品需求了,因为架构调整导致需求列表已经很长了。而且当时也说的是,短期内(至少今年)不会再有第三个Region了,我们也想着快点做完,多花点精力投入到重构中。但是计划赶不上变化,9月底我们被通知到第三个Region来了,而且已经被提高到第一优先级支持了。
有了第一版双Region的经验,这一次我们淡定了很多。当然,我们不可能在沿用第一版的设计了,因为DBA就会跟我们拼命的。回过头来梳理多Region支持面临的问题时,我发现一开始我们就自己给自己挖了一个坑,然后往里面跳。横向支撑系统显然都需要对所有Region提供支持,但这并不代表其需要在各个Region内部署(我还与团队其他的小伙伴分享了这方面的想法,网上应该还能找到这一次分享的ppt——《跨Region实践初探》)。因为公有云产商经常会提供多个Region的服务,有得甚至达到几十个Region,如果横向支持系统每个Region都要全量部署的话,那么我们花在运维上的精力就可以拖垮我们,更不要说还有最为困难的数据的一致性问题。
其实多Region的支持的问题我们总结出主要表现在一下两个方面,一是应用层面的接口互通;二是底层数据库的同步。
我们先说底层数据库的同步,对计费系统而言,数据的一致性是至关重要的,但多机房部署是在挑战CAP定律。是不是就没有了这样的数据库方案了呢,有,那就是Google的Spanner,号称可以在全球做到强一致的数据库。但是我们没有这样的数据库。其实我们也考虑使用NoSQL数据库——Cassandra,但是这个数据库运维起来太复杂,我们也没有这方面的经验,也就放弃了。还是回归到MySQL,受限于传统关系型数据库在扩展性方面的问题,我们不可能把整个库在各个Region都同步一份。但是计费原始数据又必须在各个Region内收集,于是我们决定——拆,把计费拆分成两个部分,分为bill-agent(数据采集)和bill-central(数据计算)两个部分。
Bill-Agent负责Region内日志的收集和简单聚合。
Bill-Central负责日志收集外的全局事务处理。
通过这样的拆分,架构就清晰多了。再多加Region,我们只需要部署Bill-Agent就可以了。Bill-Agent将处理过的计费数据写入本地库的一张资源表,利用NDC(马进在网上分享过关于这个中间件的介绍)将资源表单向同步到Bill-Central的中央库,然后Bill-Central统一在对计费数据进行处理。有意思的是,这张资源表就是我们在第一版设计中新建的资源表,因为我们将主键修改为UUID,所有使用NDC同步表的方案是相当顺利的。当然,NDC在我们其他项目的跨Region支持上也发挥了重要作用,比如:跨机房缓存更新的问题。这一版的数据库方案在技术评审时大家都比较满意,DBA也肯定了我们的方案。
现在再来看跨Region调用的问题。在多Region的横向系统中,我们发现或多或少的存在着机房间的接口调用问题。这些问题有可能是某些Region的库不能写需要路由到主库来写导致的,也有可能是全局缓存的问题,还有就是Global业务向Region内服务发送指令。计费属于最后一种场景,我们有一些业务场景需要由杭州Region触发,然后调用各个Region内的服务的接口。在第一版的实现中,计费系统自己实现了跨Region代理部分,但是实现的不是很好,代码的可维护性比较差,加重了调试的难度。这一版的设计中,我们决定把跨Region接口代理单独拿出来重新做,结合多Region的应用场景,然后封装一些非功能性的特性,这就成了后面我们很重要的一个组件——RegionProxy。
RegionProxy最开始是为了解决跨Region调用的非功能性问题,简化应用系统处理的成本。但是设计上经历了比较大的调整。最开始的设计我们是希望Region内所有跨Region的HTTP调用都能通过RegionProxy来代理,RegionProxy之间能够发现对方并且相互通信,那么Region内的应用系统就只需要与本Region的RegionProxy通信就可以调到任意一个Region的应用系统了。但是在方案评审的过程中,我们发现如果都用RegionProxy代理,可能会导致跨Region调用多出一跳或者两跳,调试可能会比较困难。后来,我们放弃了这个方案。再后来,我们发现ServiceMesh的方案和我们最初RegionProxy的方案是十分相似的。
在RegionProxy的设计上我们进行了简化处理,我们将所有Region的业务系统录入到一个全局的配置中心(我们自己开发的ConfigCenter)中,然后通过一个自己开发的一个HttpProxy的Java库来与ConfigCenter通信来完成跨Region的调用。这样做的好处就是使用方用起来比较轻量,但是在网络连通性方面我们需要与所有Region的系统做到互通。在开发Proxy库的时候,我们不仅对跨Region的HTTP调用进行了封装,而且对普通的HTTP调用也加入了非功能性的封装,这样系统可以通过Proxy库完成所有的HTTP调用请求,极大的简化了代码的维护成本。后面,我们使用RegionProxy来代理请求后,确实删除了很多以前的无用代码,整体流程上也清晰了许多。
多Region的感悟
经过两版多Region的改造,我们确实收货了很多宝贵的经验,非常难得。实际上,在多Region的支持上,大家需要清晰地认识到为什么要支持多Region,以何种方式去支持多Region,多Region支持与高可用的关系等基本问题。如果这些问题回到不好,或者不清楚,那么很容易就会掉到陷阱中去。另外一个感悟就是结合业务的实际场景,第二版的多Region架构我们之所以能够这么设计,就在于计费系统不需要实时出账,我们完全可以把数据保存下来,离线计算以后再出账,这是可以接受的。但这并不适用于所有情况,有些性能要求很高的横向业务就不适合这种场景。
拿来主义
前面提过几次技术债务的问题,有些问题是可以通过工具来解决了,有些只能通过内部重构来解决。左耳朵耗子曾经说过一句话对我感触很大,大意是说有些公司在解决问题时偏流程,有些公司偏技术。我想我们既然是技术团队,在解决问题时能通过技术方式解决的就应该尽量用技术解决,流程和人都是不可靠的。
难以管理的配置文件
计费项目面临的诸多问题之一就有配置文件的管理,因为业务流程的原因,计费系统有着大量的各种各样的配置。以前我们把配置文件放到工程里面,通过自动化部署平台来指定使用不同的配置文件。这样做的一个显著问题就是代码和配置耦合起来了,每次修改什么配置都得提交代码,而我们提交又有着一套严格的流程,导致整体效率不高。另外一个问题就是可视化的问题。往往QA在线下环境测试都是通过的,而上线以后出了问题,基本上都是配置导致的问题。针对这几个的问题,我们决定使用Apollo来管理我们的配置,
替换定时任务框架
计费系统严重依赖于定时任务,有许多流程需要通过定时任务来推动。以前我们使用QUARTZ+MYSQL来作为我们分布式定时任务框架,但是这种做法的可维护性太差,而且对数据库侵入很高,对测试也不友好。在QA的不断吐槽中,我们决定替换掉现有的定时任务框架。在调研开源的定时任务框架后我们决定使用Elastic-Job来作为我们的分布式定时任务框架。目前,我们的两个项目的所有定时任务(除bill-agent外)都已迁移到Elastic-Job上来了。
抽象化设计
如果你要问我做蜂巢计费最困难的地方是什么?我的回答肯定是业务太复杂了。这种复杂性不是因为我们架构设计的不好导致的复杂,而是业务本身就是十分复杂的。现在计费系统需要支持十几种产品的售卖形式,涵盖IaaS、PaaS和SaaS的绝大部分产品,同时各个产品的售卖和计费模式都存在或多或少的差异,这让我们很难通过一个统一的模型就涵盖所有的场景。我们找到了一条缓解这个问题的方式——抽象化。
横向系统或者支持系统如果需要服务多个产品,那么抽象化设计是不可或缺的缓解。如果越早进行抽象化,那么后期对接和维护的成本也就会越低,还能把系统的边界划分得更清晰。计费系统早期的设计在抽象化方面没有过多的规划,在后期的对接方面又处于比较弱势的一方,导致计费系统出现了大量的特化代码。这些特化代码对一个服务十几个产品的支持系统无疑是伤害巨大的。现在我们已经意识到了问题的严重性,也着手在做这方面的重构工作了。但是挑战依然很大,因为业务的复杂性是无法通过技术手段就能降低的,这方面我们只有和产品、运营和销售各方面一起努力,打造一个合理、灵活、稳定的新计费。
推荐阅读: