该项目在人员上已经几经易手，就我所知，已经换过两拨完整的开发和测试团队了，而且已经全部离职。不得不说，该项目已经变得令人谈之色变，让人敬而远之。在这样的背景下，后期接手的开发和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来完成。为了避免“脑裂”的问题，我们特别将该表的主键采用UUID的形式。存量表因为无法做大规模修改，我们通过限制北京MySQL用户的权限来避免写入和修改全局表。
这个设计很糟糕，但是当时的条件限制，我们也拿不出更好的设计了。虽然上线的过程有些曲折，当这个架构还是成功运行了，这是令我们最为欣慰的事情。因为为了适配这个架构，团队的小伙伴做了很多工作。不可否认，这个架构存在诸多弊端，其中最大的隐患就在于数据库的“双主”同步，这就像一颗随时会爆的炸弹萦绕在我们心头。当时专线还没有搭建好，所有的流量均通过外网隧道代理，糟糕的网络质量无疑放大了这个风险。为此，DBA们向我们吐槽了好久，幸好我们抗打击能力很强。
在做完双Region的支持以后，计费团队就继续做产品需求了，因为架构调整导致需求列表已经很长了。而且当时也说的是，短期内（至少今年）不会再有第三个Region了，我们也想着快点做完，多花点精力投入到重构中。但是计划赶不上变化，9月底我们被通知到第三个Region来了，而且已经被提高到第一优先级支持了。
其实多Region的支持的问题我们总结出主要表现在一下两个方面，一是应用层面的接口互通；二是底层数据库的同步。
我们先说底层数据库的同步，对计费系统而言，数据的一致性是至关重要的，但多机房部署是在挑战CAP定律。是不是就没有了这样的数据库方案了呢，有，那就是Google的Spanner，号称可以在全球做到强一致的数据库。但是我们没有这样的数据库。其实我们也考虑使用NoSQL数据库——Cassandra，但是这个数据库运维起来太复杂，我们也没有这方面的经验，也就放弃了。还是回归到MySQL，受限于传统关系型数据库在扩展性方面的问题，我们不可能把整个库在各个Region都同步一份。但是计费原始数据又必须在各个Region内收集，于是我们决定——拆，把计费拆层两个部分，分为bill-agent(数据采集)和bill-central(数据计算)两个部分。
现在再来看跨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架构我们之所以能够这么设计，就在于计费系统不需要实时出账，我们完全可以把数据保存下来，离线计算以后再出账，这是可以接受的。但这并不适用与所用情况，有些性能要求很高的横向业务就不适合这种场景。
前面提过几次技术债务的问题，有些问题是可以通过工具来解决了，有些只能通过内部重构来解决。左耳朵耗子曾经说过一句话对我感触很大，大意是说有些公司在解决问题时偏流程，有些公司偏技术。我想我们既然是技术团队，在解决问题时能通过技术方式解决的就应该尽量用技术解决，流程和人都是不可靠的。
如果你要问我做蜂巢计费最困难的地方是什么？我的回答肯定是业务太复杂了。这种复杂性不是因为我们架构设计的不好导致的复杂，而是业务本身就是十分复杂的。现在计费系统需要支持十几种产品的售卖形式，涵盖IaaS、PaaS和SaaS的绝大部分产品，同时各个产品的售卖和计费模式都存在或多或少的差异，这让我们很难通过一个统一的模型就涵盖所有的场景。我们找到了一条缓解这个问题的方式——抽象化。
横向系统或者支持系统如果需要服务多个产品，那么抽象化设计是不可或缺的一个缓解。如果越早进行抽象化，那么后期对接和维护的成本也就会越低，还能把系统的边界划分得更清晰。计费系统早期的设计在抽象化方面没有过多的规划，在后期的对接方面又处于比较弱势的一方，导致计费系统出现了大量的特化代码。这些特化代码对一个服务十几个产品的支持系统无疑是伤害巨大的。现在我们已经意识到了问题的严重性，也着手在做这方面的重构工作了。但是挑战依然很大，因为业务的复杂性是无法通过技术手段就能降低的，这方面我们只有和产品、运营和销售各方面一起努力，打造一个合理、灵活、稳定的新计费。
从八月底加入计费团队以来，收获良多，无论是在技术上，还是在对业务的理解上，都有了许多新的认识。最为给力的还是团队的小伙伴们，因为计费本身的需求非常多，处理这些需求的人都只刚刚够。后来我们又做了两版跨Region改造、订单拆分、框架替换、抽象化等优化工作，迭代周期从两周一次压缩到了一周一次，开发和QA的小伙伴也都是任劳任怨。当然，大家能在这个过程中有所收获才是最关键的。
计费系统可以说是我接触过的最为复杂的一个系统，越是复杂的系统越需要清晰的头脑和良好的设计。云计算产商的博弈已经到了白热化阶段了，大家拼的不光光是每个产品的质量和体验，还有整个云平台的内功。公有云平台本身就是一个庞大、复杂的系统，如何把这个系统建设好，用户体验做好、服务质量提高、稳定性得到保障，这本身就是极为有难度的一件事情。计费系统作为公有云平台一个重要的组成部分，可以说扮演着一个极为关键的角色。做得好可以对整个平台提供助力，而做的差则会拖慢整体的发展进程。我们已经找到了适合自己的一条道路，相信会走上正轨！