人工智能

用戶從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 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
大丰收注册
股票短线下载 新快3 和值技巧总结 股票融资费用和利息 融资融券股票一览表 网络广告赚钱 大连娱网棋牌下载安装 贵州快三和值预测 上海11选5数据 下载 宜人股票配资平台 炒股散户能赚钱吗 重庆麻将血战到底规则 天津快乐10分几点开奖结果今天晚上 山东老十一选五 炒股软件免费版 河南快赢481开奖视组走 极速11选5投注技巧