【TEGer 在全球架构师峰会】 : 腾讯海外计费系统架构演进

欢迎大家前往云加社区，获取更多腾讯海量技术实践干货哦~

作者简介：abllen，2008年加入腾讯，一直专注于腾讯计费平台建设，主导参与了腾讯充值中心、计费开放平台、统一计费米大师等项目，见证了米大师从0到1，业务营收从PC到移动多终端再到全球化的跨越过程。20+篇支付专利主撰写人。目前专注于跟团队一起为腾讯业务提供稳定高效安全的全球化个人和企业市场计费服务。

本文由腾讯技术工程官方号发布在云加社区！

经过海外3年建设，腾讯Midas（米大师）计费逐步构建起了一个分布式的全球计费系统，来助力公司及业内产品计费扬帆出海，走向深蓝。在刚过去的北京全球架构师峰会上，腾讯计费平台部架构师陈宁国分享了Midas在海外计费系统架构演进上的一系列思路与做法。

Midas计费，目前已经接入2000+ APP，60多万家商户，覆盖国内10+和海外40+渠道，托管账户总量200多亿，每日流水稽核500多亿条，基本上涵盖了所有常见的计费模式，如虚拟代币购买、道具、订阅、实物等，是一个全方位的一站式计费平台。

在讨论海外的计费架构演进前，先看下国内在线交易系统的简要架构。

该架构下，计费系统已具有如下能力：

1.整体多地部署，具备跨城容灾能力

2.就近接入，通过GLSB等机制，尽量将用户的请求从邻近公网入口导入计费系统，这可以明显降低用户时耗，提升体验；

3.域内系统自治，存储底层来解决必要的数据跨区域访问问题，如某些风控策略，数据必须全局共享, 底层的透明网关会根据请求信息来就决定是本地访问还是远程访问。在这个机制下，故障时一地区可在短时间内甚至无缝来承载另一地区的全部交易请求，以达成系统的高可用。

计费走向海外国际化，所要面对的首要核心问题就是地域跨度，从下图即2017-12-7日的Midas全球各区域实时支付时耗图就可以看到，内部网络单路径的时耗，经常性约200ms左右，作为对比，深圳到上海的时耗一般都在50ms以内，而实际的请求往往要经历多次路径接力，特别是从用户终端到就近接入点，耗时更久，这对系统流程控制、监控、发布等都有挑战。其次，随着部署地域的增加，不同地区的网络结构，机器软硬件环境，及机器数都会有所限制，譬如在国内，一整套计费系统一般机器数都在百台以上，而在海外某些地区，出于业务试水等情况，机器可能刚开始只有3~5台，那么就需要有办法将数百台机器的计费系统缩减到只需3台即可正常运行。还有就是底层存储，需要能实现跨区域数据主动动态迁移。

架构演进之一，整体网络优化。

Midas海外计费，目前主要部署在香港(HK)和加拿大(CA)两大公司自有IDC，及南北美、欧洲、澳洲的AWS，还有部分是合作伙伴机房。在这些区域间，涉及到多级骨干网，二级网络和本地运营商网络，物理路径长，时耗常不稳定，我们通过利用公司全球POP加速点的部署，结合分析海外网络结构特点，建设了8个自营的交易中心入口，并利用智能DNS远程代理方式，来优化如AWS的接入点，最终有效避开了局部经常性的网络异常，加之终端的针对性优化，如预加载，请求合并等，成功将全球17个地区单次通信平均时耗明显降低。

下图是MC的优化前后支付时耗图，可以看到优化后平均单次通信时耗都降到了800ms内。

架构演进之二，配置、发布及数据处理

针对海外的机房差异性大的特点，我们设计了一套配置的统一推送同步系统，譬如针对合作商网络，布置中间层代理，对于不同地域，将配置打标记做差异化减少网络数据流量，并且实现应用及活动规则等细粒度配置同步，同时，还能实时获得各配置下发的进度及生效情况，最终实现的配置的跨国秒级下发。

针对海外机房众多的问题，还研发了全球发布平台，能根据各地域机房情况采取相应的最优化发布策略，最终实现即时的按需发布。

随着发布地点的增加，监控和交易数据的实时处理愈发重要，我们构建了一个集中式的数据收集及处理平台，最终实现秒级的全球交易异常告警及数据稽核。

架构演进之三，跟随部署

计费针对海外的机房环境差异及机器数限制，采用了两项策略。

一项解决环境依赖，譬如，对能提供docker类虚拟化容器环境的，构建计费系统的镜像来部署；对不能提供虚拟化容器的，在自有的开发框架层上，直接打包开发环境的runtime，不再依赖部署机器的runtime，同时，还提供这些runtime的hook，使得框架中的app也不再依赖部署机器的runtime。最后，对于app使用的特定库，要求尽量采用静态编译的办法来解依赖。

另一项，对于机器数量有限制的，采取灵活适配的办法，通过将大的系统模块完全微服务化来达成。微服务化后，每个系统都有一个或多个app组成，而这些app均可以在统一的框架下运行，这样最少3台机器（考虑存储的需要）就可以部署所需要的全部功能，并且，微服务化后还使得计费部署能根据场景灵活组合做最佳化适配。细节如下图

架构演进之四，框架与交易引擎

前面讲到要完全微服务化，随着逻辑被分拆，app增多，会面临新的服务治理的问题，一方面是服务间的访问调度，一个是服务内逻辑的可控性。

对于服务调度，我们开发了TDF框架，来实现服务间的动态路由、负载均衡、灰度、引流、流控等管理。

对于服务内逻辑，特别是计费强调高一致事务类的，我们开发了交易引擎 TDXA，通过范式定义来简化XA事务开发，如包括 TCC\ TRY_BEST\DB及几者的混合处理等，实现事务及异常处理的完备；同时引入图形化的流程管理，使得逻辑流程可以通过图检查来确保完备，还可以展示某个请求的处理过程，这使得流程更加清晰化，增强逻辑可维护性。

架构演进之五，跨地域动态迁移

在跨地域情况下，严重的时耗问题使得远程访问代价过大，这时就需要有办法能将远程访问尽量变本地化，下图是我们考虑的策略，根据用户的就近位置来决定数据归属。如对同一个账户表，如果用户位置变动是短暂行为，则仍旧是远程访问原位置数据，如果位置明确变动，则会自动做数据的平滑迁移，即短期的数次远程访问后，会将数据搬到用户新的所在位置，变成快速本地访问，这可以明显降低交易时耗，提升用户付费体验。

经多以上的这些架构调整，最终我们构建了一套全球化的计费系统，实现如下预定目标：

1.灵活按需部署，按需快速发布、灰度、扩容，并实现高可用

2.多主中心 + 各小中心 + 集中式运营，具体为：

A)自营全球7大机房，外发部署就近8国，覆盖全球主要区域

B)4大POP加速点， 3大远程代理，单次通信时耗降低到1s内；

C)海外已接入40个渠道，基本涵盖各区域主流渠道

D)业务接入周期从1月降低到3天，实现秒级的发布与异常告警；

E)数据跨地域动态迁移，基本做到全本地化访问，进一步降低付费时耗。

3.我们认为这是目前阶段能达到的较合理的计费体系，线上运行也表明符合预期。

结束语

经过持续建设优化，Midas米大师已成为一套完备的全球性、全场景、一站式整体解决方案。支付的持续发展有赖于付费场景的扩展，Midas欢迎各类业务的洽谈接入与合作。米大师自身也将继续追求技术的突破，不断迭代演化，为各业务营收带来更大的价值。

专题介绍

ArchSummit全球架构师峰会是InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会，参会者数量1000+。其中，出品人及演讲嘉宾中高级技术专家比例占79%，90%拥有10年以上开发经验。本次“TEGer在全球架构师峰会”专题将带来TEG人在会上的系列主题分享。