人工智能

用戶從0到5億,中國移動 OneLink 架構演進之路

導語

本文根據范良澤老師在2019年10月31日【第十一屆中國系統架構師大會(SACC)】現場演講內容整理而成。

范良澤(中移物聯網有限公司系統架構專家)

2008年畢業于上海交通大學,曾供職于華為、Opera Solutions等公司,服務于通信、咨詢、金融、地產等領域,一直從事研發相關工作。目前在中移物聯網有限公司就職,負責連接管理平臺OneLink平臺研發工作,通過引入大數據、微服務、DevOps等技術和最佳實踐,構筑全球最大的連接管理平臺。

摘要:近幾年物聯網行業迎來爆發,用戶規模持續指數級增長,OneLink平臺經過架構和容量不斷優化升級,到2019年8月已經成功支撐10萬企業、5億 用戶,逐步成長為全球用戶規模最大的連接管理平臺,為人們日常工作和生活保駕護航。

本文主要分享大數據、微服務和DevOps等技術在OneLink成長和架構演進過程中的應用及實戰經驗,包括:

1、OneLink系統簡介和成長挑戰
2、用戶從0到3千萬到1億再到5億的架構演進
3、百億級RADIUS報文業務優化方案和重難點技術
4、厚平臺薄應用和兩地三中心的災備架構建設

OneLink 背景介紹

中移物聯網有限公司,是中國移動通信集團公司出資成立的全資子公司,有五大核心業務:智能連接、芯片模組、開放平臺、智能硬件、行業應用。

中國移動公眾物聯網連接管理平臺(OneLink),通過專屬的通信網元設備,以高品質、廣覆蓋的通信接入,滿足物聯網業務“規模性、流動性、安全性、穩定性”的特殊需求。為客戶提供物聯網連接管理服務,為合作伙伴提供產品引入代銷結算服務,為省公司提供運營支撐服務。

2015年,我剛剛到公司時,大概在幾百萬不到一千萬的物聯網用戶,現在有5億多的物聯網用戶。

OneLink體系,主要涉及四個較大部分:

連接管理;

增值服務;

能力開放;

國際業務;


增值服務是與大家有合作空間的場景,現在已經提供的能力有:智能出入、移動商旅、健康管理、智慧金融、智能制造,安全服務。

這些服務源自我們內部能力,外部客戶及合作伙伴引入的一些能力,形成了對外的行業標準能力。

業務的發展推動了我們的架構演進,從2014年開始的百萬級,到2019年5億多,業務量猛增,讓對外部交互變得越來越復雜。

那么,用戶從0到百萬千萬再到5億,我們的架構是怎么演進的?

架構演進

應用服務演進

從百萬到千萬帶來的壓力在于,大量數據業務的計算和存儲都是基于Oracle處理,Oracle在數據量較大時,大量統計報表會影響到前臺業務查詢的狀況,響應時間會下降,把計算資源吃掉了很多,所以查詢響應時間會降下來。

對此,我們做的改變是引入了大數據技術,用Hadoop架構來完成計算和存儲的演進,這一部分細節我就不再細講了,前面很多老師也提到了這一點。

而到了數億級時,最大的變化是微服務以及存儲這兩塊有變化。

微服務引進新技術緩存,這樣高頻應用流量卸載,和外部網聯的交互變得更系統,業務上面更清晰,同時也有一些人工智能的分析。

存儲系統演進

最早,我們獨立緩存和業務系統部署在統一虛擬機上。第二個階段,在數千萬的時候,Redis中間有一段時間嘗試過TT,因為TT成本比較高,后來摒棄了。現在引用了RedisCluster來解決高頻場景,目前大概有5到6個集群。

大數據架構中演進

早期,只處理日志類的業務,只涉及自身業務模塊運行狀況,比如運行狀況分析、異常情況分析,當幾千萬級時,剛才提到,我們大數據集群緩解了Oracle的計算壓力,當時,只用了存儲還有報表以及上層查詢的標準語句。

現在大數據已經變得很復雜了,有很多組件,包括流式統計、批處理以及人工智能,剛才提到,短時間內出現大量卡的狀態,可能會有業務影響,我們通過人工智能辦法把它識別出來。

像有些ToB場景,對流量的使用費用比較高,需要降一些成本,也會通過人工智能方法去把套餐做一些優化,這樣的場景在現在大數據中就能完成。

最后,看一下數據庫的演進,早期就是單庫,把存儲、查詢還有統計報表計算都統一放到一個單庫里。到了幾千萬的時候就出現瓶頸,把一部分計算邏輯挪到了Hadoop上,同時,重慶放到一個庫里,北京放到一個庫里。有的省份就已經是7000萬、8000萬接近上億的用戶量,這種情況下帶來很大的壓力。

第二、是按照用戶拆分、客戶拆分,這樣會降低性能負擔。通過不斷的演進,我們數據庫漸漸完成了拆分,或者說分布式中間件來完成我們數據庫的演進。這部分求是我們的數據庫的變化的狀況。

災備建設演進

早期,大概幾十萬級別時,只做數據備份,外部的數據直接轉發到異地的機房,只做數據的冷備,如果說機房出了問題,這個數據還在,但恢復可能就這個維度,恢復這個機房。

目前,我們正在建設兩地三中心,打造同城雙活異地災備,異地機房的備份和前面那一個狀況有一些類似,只不過現在多了一些實時的,前面的是每天備份一次。

我們計劃同城建立雙活,大數據和數據庫完成實時同步,在和外部交互的狀況,通過路由做用戶切換,內部應用層做打造,達到同城雙活的目的,這部分我們做了一部分驗證還沒驗證完,正在上線,預計年底會投產。我們會用更復雜的混合云來完成架構兼容性的演進。

案例分享

首先,舉個例子,比如手機開機、關機,數據或狀態變更,會上報到網關上面,接下來,會經過中間層業務傳遞到上面的平臺。物聯網設備也一樣。

現在,用戶量越來越多了,短時間有大量的設備會移動的,像汽車、高鐵上面都有很多設備,傳感器設備會產生大量數據,這個時候業務網關設備是廠商負責建設的,它收到終端上面的信息會傳到我們的平臺,這個網關才會傳到最終的業務平臺上面去,這個時候會存在新的瓶頸,我們一開始不知道這里的問題,后來,通過實際驗證才發現,這個地方壓力存在一萬每秒就存在數據丟失問題。

早期,寫了一個文件來完成數據的緩存,后面,上層業務在讀這個文件,聚合業務也在讀這個文件,這樣對業務來說存在一定的條件。最后,會把這個數據存到Oracle里面,還有統計報表、查詢業務之間的資源,有互相影響的,影響了一個業務從端到端的吞吐量,總共算起來估計在5000左右,我們當時用戶量從上千萬開始就已經面臨壓力了。接下來逐步對它做了演進。

業務網關當時有一個背景,貿易戰很早就開始。設備廠商像中興、華為都受到了影響,只能把它繞過去,我們引用東南西北四個基地從業務網關繞過去,像這些專用客戶使用專用的APN,通過我們專用網絡來解決它的瓶頸問題。我們接入數據以后,把它緩存下來,后端所有業務通過Kafka完成解網。

后端業務主要兩點,第一點,是把Redis單機完成集群的變化,這樣進行動態的擴充。計算,最開始也是在Oracle里完成存儲,后面,我們基于大數據流式計算來完成數據的業務更迭。

現在最外部壓力大概在20萬每秒,阿里雙十一金額很高,但是訂單量真正會引起供銷存變化的數據量峰值也才20萬每秒,我們承接的固定業務是7×24小時不停的數據,阿里雙十一有個峰值后面會降下來,我們20萬每秒是緩慢上升的。在我們業務處理時,業務處理大概到100萬層面了。

隨著業務量上升,隨著用戶量發展,引起了架構變化。早期架構業務也可以支撐,用戶量大了以后帶來各種模塊出現瓶頸。

心得體會

剛才,提到當我們在規模小的時候,架構缺陷不會暴露,當我們規模成長以后這些缺陷會慢慢放大,業務的發展會促進我們架構演進,業務量加大以后去改進、優化它,這些架構演進會更好的促進業務的發展。

老魚,企業級老編一枚,你若有故事,歡迎聯系!

央視網黃樂:安全合規是一切工作的重要基礎

上一篇

到2023年,全球數字化轉型支出將達到2.3萬億美元

下一篇

你也可能喜歡

用戶從0到5億,中國移動 OneLink 架構演進之路

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
重庆时时后一8码方法 5分pk10-APP稳定版下载 武汉酒店按摩师招聘 排列三和值遗漏 手机麻将外挂软件 分分11选5手机版下载 股票配资平台大全 福建22选5开奖结 手机上怎样玩qq麻将 浙江6+1彩票每周开奖时间是几点 江苏十一选五今天结果 石家庄沐足按摩技师招聘 四川快乐十二开奖走势图 排球比分网站 贵州麻将技巧 江苏11选5开奖结果 河南22选5专家预测