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

标签: | 发表时间:2017-12-26 09:02 | 作者:
出处:http://mp.weixin.qq.com




作者简介: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人在会上的系列主题分享。


你认为产品出海

 除了计费,还会遇到什么大的挑战? 

12月31日前

在留言区分享你的看法, 点赞前三名将获得

腾讯CDC“怪企鹅按摩捶”一个


读者须知


为了给大家分享更多的腾讯技术消息,即日起,腾讯技术工程官方号将转为订阅号。推荐你将“腾讯技术工程官方号”置顶,第一时间获取腾讯技术工程的独家资讯和技术干货。近期还将有大量腾讯周边礼品赠送活动哦!

相关 [腾讯 外计 系统架构] 推荐:

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

- -
作者简介:abllen,2008年加入腾讯,一直专注于腾讯计费平台建设,主导参与了腾讯充值中心、计费开放平台、统一计费米大师等项目,见证了米大师从0到1,业务营收从PC到移动多终端再到全球化的跨越过程. 目前专注于跟团队一起为腾讯业务提供稳定高效安全的全球化个人和企业市场计费服务. 经过海外3年建设,腾讯Midas(米大师)计费逐步构建起了一个分布式的全球计费系统,来助力公司及业内产品计费扬帆出海,走向深蓝.

工作十年,在腾讯沉淀的高可用系统架构设计经验

- - 掘金 架构
在系统的开发过程中,很多开发者都为了实现系统的高可用性而发愁. 本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用系统的架构设计需要有哪些关键的设计和考虑. 希望腾讯的经验方法,能够给广大开发者提供参考. 内容较长,您可以收藏后持续阅读. 1 高可用系统的架构设计思想.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.

Digg.com 的系统架构

- - 标点符
在过去的几年间,我们一直致力于重构Digg的架构,现在我们称之为“Digg V4”.本文我们将全面介绍Digg的使用的系统和技术. 首先,我们来看下Digg给大众用户提供的服务吧:. 人们通过浏览器或者其他应用来访问这些Digg服务. 一些有Digg账户的用户,可以得到“我的新闻”. 每位用户可以得到的我们称之为“热门新闻”.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.

支付宝系统架构

- - 编程语言 - ITeye博客
支付宝的开源分布式消息中间件–Metamorphosis(MetaQ). Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件,类似于LinkedIn的Kafka,具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用 于大吞吐量、顺序消息、广播和日志数据传输等场景,在淘宝和支付宝有着广泛的应用,现已开源.