為什麼像 MegaFon 這樣的公司需要 Tarantool 進行計費？ 從外面看，供應商通常會帶來某種大盒子，將插頭插入插座 - 這就是計費！ 曾經是這樣，但現在已經過時了，這樣的恐龍已經滅絕或正在滅絕。 最初，計費是一種開立發票的系統 - 計數機或計算器。 在現代電信中，這是 自動化系統，用於與訂戶互動的整個生命週期，從簽訂合約到終止，包括即時計費、付款接受等等。 電信公司的計費就像一個戰鬥機器人——龐大、強大並且裝載著武器。
Tarantool 與它有什麼關係？ 他們會談論它 奧列格·伊夫列夫 и 安德烈·克尼亞澤夫。 奧列格是公司的首席架構師 Andrey 擁有豐富的外部工作經驗，擔任業務系統總監。 從他們的報告筆錄來看 你將了解為什麼企業需要研發，Tarantool是什麼，垂直擴展和全球化的僵局如何成為該資料庫在公司出現的先決條件，關於技術挑戰，架構轉型，以及MegaFon的technostack與Netflix有何相似之處、谷歌和亞馬遜。
「統一計費」項目
此項目稱為「統一計費」。 正是在這裡，Tarantool 展現了它最好的品質。
高階設備生產率的成長未能跟上用戶群的成長和服務數量的成長；由於M2M、物聯網和分公司功能的引領，預計用戶和服務數量將進一步成長導致上市時間縮短。 該公司決定創建一個具有獨特的世界級模組化架構的統一業務系統，而不是目前8種不同的計費系統。
MegaFon 是八家公司合而為一。 2009 年，重組完成：俄羅斯各地的分支機構合併為一家公司，MegaFon OJSC（現為 PJSC）。 因此，該公司擁有 8 個計費系統，擁有自己的「客製化」解決方案、分支機構功能以及不同的組織結構、IT 和行銷。
一切都很好，直到我們不得不推出共同的聯邦產品。 這裡出現了許多困難：對某些人來說，關稅是四捨五入的，對其他人來說是向下捨去的，而對有些人來說則是基於算術平均值的。 這樣的時刻有成千上萬個。
儘管計費系統只有一個版本、一個供應商，但設定差異很大，需要很長時間才能整合在一起。 我們試圖減少他們的數量，但遇到了許多公司都熟悉的第二個問題。
垂直縮放。 即使是當時最酷的硬體也無法滿足需求。 我們使用了 Superdome Hi-End 系列的惠普設備，但它甚至無法滿足兩個分店的需求。 我想要橫向擴展而不需要大量的營運成本和資本投資。
用戶和服務數量增長的預期。 顧問們長期以來一直將物聯網和 M2M 的故事帶入電信界：總有一天，每部手機和熨斗都將配備一張 SIM 卡，並且冰箱裡會放兩張。 今天我們只有一批訂閱者，但在不久的將來將會有更多。
技術挑戰
這四個原因促使我們做出認真的改變。 可以選擇升級系統並從頭開始設計。 我們思考了很長一段時間，做出了認真的決定，進行了招標。 因此，我們決定從一開始就進行設計，並接受有趣的挑戰—技術挑戰。
可擴展性
如果是以前的話 就說吧 8 萬訂戶的 15 張帳單，現在應該可以了 100 億訂閱者及更多 - 負載高出一個數量級。
我們的規模已經可以與 Mail.ru 或 Netflix 等大型網路公司相媲美。
但增加負載和用戶基礎的進一步行動給我們帶來了嚴峻的挑戰。
我們幅員遼闊的國家的地理
加里寧格勒和海參崴之間 7500公里和10個時區。 光速是有限的，在這樣的距離上，延遲已經很明顯了。 在最酷的現代光通道上，150 毫秒對於即時計費來說太長了，尤其是現在俄羅斯的電信領域。 此外，您需要在一個工作天內更新，並且對於不同的時區，這是一個問題。
我們不僅提供訂閱費服務，我們還有複雜的資費、套餐和各種修改器。 我們不僅需要允許或拒絕訂閱者通話，還需要給他一定的配額——即時計算通話和操作，以免他注意到。
容錯
這是中心化的另一面。
如果我們將所有訂閱者集中在一個系統中，那麼任何緊急事件和災難都會為企業帶來災難性的後果。 因此，我們設計系統的方式是為了消除事故對整個用戶群的影響。
這又是拒絕垂直擴展的結果。 當我們橫向擴展時，我們將伺服器數量從數百台增加到數千台。 它們需要可管理、可互換、自動備份IT基礎架構並還原分散式系統。
我們面臨著如此有趣的挑戰。 我們設計了這個系統，當時我們試圖尋找全球最佳實踐來檢查我們的趨勢如何，我們在多大程度上遵循先進技術。
世界經驗
令人驚訝的是，我們在全球電信中沒有找到任何參考資料。
歐洲在用戶數量和規模方面已經落後，而美國在資費平坦度方面已經落後。 我們在中國考察了一些，在印度找到了一些，並從沃達豐印度聘請了專家。
為了分析架構，我們組成了一個由IBM領導的夢幻團隊－來自不同領域的架構師。 這些人可以充分評估我們正在做的事情，並為我們的架構帶來一定的知識。
秤
一些數字用於說明。
我們設計該系統的目的是 80萬訂閱用戶，XNUMX億儲備。 這就是我們消除未來門檻的方法。 這不是因為我們要佔領中國，而是因為物聯網和 M2M 的衝擊。
即時處理 300 億份文檔。 儘管我們擁有 80 萬訂閱者，但如果我們需要收取應收帳款，我們會與潛在客戶以及已經離開我們的客戶合作。 因此，實際體積明顯較大。
2億筆交易 餘額每天都會變化 - 這些是付款、收費、通話和其他事件。 200 TB 數據正在積極變化，改變得慢一點 8 PB 數據，這不是存檔，而是單一計費中的即時數據。 按資料中心擴展 - 5 個站點上的 14 台伺服器.
技術堆疊
當我們規劃架構並開始組裝系統時，我們引入了最有趣和最先進的技術。 其結果是任何互聯網參與者和製造高負載系統的公司都熟悉的技術堆疊。
該堆疊與其他主要參與者的堆疊類似：Netflix、Twitter、Viber。 它由 6 個組件組成，但我們希望縮短並統一它。
彈性固然好，但在大公司裡，不統一就不行。
我們不會將同一個 Oracle 更改為 Tarantool。 在大公司的現實中，這是一個烏托邦，或是一場持續5-10年但結果不明朗的十字軍東徵。 但 Cassandra 和 Couchbase 可以輕鬆地被 Tarantool 取代，這就是我們正在努力的目標。
為什麼選擇塔蘭圖爾？
我們選擇這個資料庫有 4 個簡單的標準。
速度。 我們對 MegaFon 工業系統進行了負載測試。 Tarantool 獲勝 - 它展示了最佳性能。
這並不是說其他系統不能滿足 MegaFon 的需求。 目前的記憶體解決方案非常高效，公司的儲備綽綽有餘。 但我們感興趣的是與領導者打交道，而不是與落後的人打交道，包括在負載測試中。
Tarantool 甚至可以滿足公司的長期需求。
總擁有成本。 對 MegaFon 卷上的 Couchbase 的支援需要花費天文數字，但使用 Tarantool 的情況要愉快得多，而且它們的功能相似。
另一個稍微影響我們選擇的好功能是 Tarantool 比其他資料庫更適合記憶體。 他顯示 最大效率.
可靠性。 MegaFon 在可靠性方面的投資可能比其他任何公司都多。 因此，當我們考慮 Tarantool 時，我們意識到我們必須使其滿足我們的要求。
我們投入了時間和資金，與 Mail.ru 一起創建了企業版本，現在已在其他幾家公司中使用。
Tarantool-enterprise 在安全性、可靠性和日誌記錄方面完全讓我們滿意。
合作關係
對我來說最重要的是 直接與開發商聯繫。 這正是塔蘭圖爾的人用來行賄的。
如果你找到一個玩家，尤其是一個與主播客戶合作的玩家，並說你需要資料庫能夠做到這個、這個、這個，他通常會回答：
- 好吧，把需求放在那堆的底部 - 有一天，我們可能會解決它們。
許多人都有未來 2-3 年的路線圖，幾乎不可能整合到那裡，但 Tarantool 開發人員以其開放性著迷，不僅來自 MegaFon，而且還根據客戶調整他們的系統。 這很酷，我們真的很喜歡它。
我們在哪裡使用 Tarantool
我們在多個元素中使用 Tarantool。 第一個是在試點中，我們在地址目錄系統上製作的。 有一次我希望它成為一個類似 Yandex.Maps 和 Google 地圖的系統，但結果有點不同。
例如銷售介面中的地址目錄。 在 Oracle 上，搜尋所需的位址需要 12-13 秒。 - 令人不安的數字。 當我們切換到 Tarantool，在控制台中將 Oracle 替換為另一個資料庫，並執行相同的搜尋時，我們獲得了 200 倍的加速！ 第三個字母後會彈出城市。 現在我們正在調整介面，以便在第一個介面之後發生這種情況。 然而，反應速度完全不同——毫秒而不是秒。
第二個應用程式是一個流行的主題，稱為雙速 IT。 這是因為來自各個角落的顧問都說企業應該去那裡。
有一個基礎設施層，在其之上有一些域，例如電信等計費系統、公司係統、公司報告。 這是不需要觸及的核心。 當然，這是可能的，但要偏執地確保質量，因為它會給公司帶來金錢。
接下來是微服務層——這是運營商或其他參與者的區別所在。 可以基於某些快取快速創建微服務，將不同領域的資料帶入其中。 這裡 實驗場 - 如果出現問題，我會關閉一個微服務並打開另一個。 這確實縮短了上市時間，並提高了公司的可靠性和速度。
微服務也許是 Tarantool 在 MegaFon 中的主要角色。
我們計劃在哪裡使用 Tarantool
如果我們將我們成功的計費專案與德國電信、Svyazcom、沃達豐印度公司的轉型計劃進行比較，就會發現它具有驚人的活力和創造力。 在實施這個專案的過程中，不僅MegaFon及其結構發生了轉變，而且在Mail.ru上出現了Tarantool-enterprise，以及我們的供應商Nexign（以前的Peter-Service）-BSS Box（盒裝計費解決方案）。
從某種意義上說，這對俄羅斯市場來說是一個歷史性的項目。 這可以與 Frederick Brooks 的《人月神話》一書中的描述進行比較。 然後，在 60 年代，IBM 僱用了 360 名員工來開發用於大型主機的新 OS/5 作業系統。 我們的數量少於 000，但我們的數量是背心，考慮到開源和新方法的使用，我們的工作效率更高。
以下是計費領域，或更廣泛地說，是業務系統領域。 企業界人士對CRM非常了解。 每個人都應該已經有其他系統：Open API、API Gateway。
開放API
讓我們再次查看這些數字以及 Open API 目前的工作原理。 其負載為 每秒 10 筆交易。 由於我們計劃積極開發微服務層並建立MegaFon公共API，因此我們預計這部分未來會有更大的成長。 肯定會有100萬筆交易.
我不知道我們是否可以與 Mail.ru 的 SSO 進行比較 - 這些傢伙似乎每秒有 1 筆交易。 他們的解決方案對我們來說非常有趣，我們計劃採用他們的經驗 - 例如，使用 Tarantool 進行功能性 SSO 備份。 現在 Mail.ru 的開發人員正在為我們做這件事。
CRM
CRM 的訂閱者數量為 80 萬，我們希望將其增加到 300 億，因為已經有 XNUMX 億份文件包含三年的歷史記錄。 我們真的很期待新的服務，在這裡 增長點是互聯服務。 這是一個會不斷增長的球，因為會有越來越多的服務。 因此，我們需要一個故事；我們不想偶然發現這個。
透過開立發票、處理客戶應收帳款自行計費 轉換為單獨的網域。 為了提高性能， 應用領域架構架構模式.
系統劃分域，分散負載，保證容錯。 此外，我們也使用分散式架構。
其他一切都是企業級解決方案。 在通話儲存中 - 每天 2 億，每月60億。 有時你必須在一個月內數一下，而且最好快點。 財務監控 - 這與不斷增長和增長的300億完全相同：用戶經常在運營商之間流動，增加了這部分。
行動通訊中最具電信性的組成部分是 線上計費。 這些系統允許您打電話或不打電話，即時做出決定。 這裡的負載是每秒 30 個事務，但考慮到資料傳輸的成長，我們計劃 250 萬筆交易，因此我們對 Tarantool 非常感興趣。
上圖是我們要使用 Tarantool 的網域。 當然，CRM 本身更廣泛，我們將在核心本身中使用它。
我們估計的 TTX 訂閱用戶數為 100 億，這讓作為架構師的我感到困惑 - 如果是 101 億呢？ 難道所有的事都要重做一次嗎？ 為了防止這種情況發生，我們使用緩存，同時提高可訪問性。
一般來說，有兩種使用 Tarantool 的方法。 第一的 - 在微服務層級建置所有緩存。 據我了解，VimpelCom 正在遵循這條道路，建立客戶端快取。
我們對供應商的依賴較少，我們正在更改 BSS 核心，因此我們有一個開箱即用的客戶端檔案。 但我們想擴大它。 因此，我們採取稍微不同的方法 - 在系統內部創建緩存.
這樣就減少了同步——一個系統負責快取和主控來源。
當僅更新與更新（即資料變更）相關的部分時，此方法非常適合具有事務框架的 Tarantool 方法。 其他一切都可以存放在其他地方。 沒有龐大的資料湖、不受管理的全域快取。 快取是為系統設計的，或是為產品設計的，或是為客戶設計的，或是為了讓維護更容易。 當訂戶致電並對您的服務品質感到不安時，您希望提供優質的服務。
RTO 和 RPO
IT中有兩個名詞— RTO и RPO.
恢復時間目標 是發生故障後恢復服務所需的時間。 RTO = 0 表示即使出現故障，服務仍會繼續運作。
復原點目標 - 這是資料恢復時間，也就是在一段時間內我們可能會遺失多少資料。 RPO = 0 表示我們沒有遺失資料。
塔蘭工具任務
讓我們嘗試解決 Tarantool 的問題。
給定：一籃子每個人都理解的應用程序，例如在亞馬遜或其他地方。 需要 以便購物車每週 24 天 7 小時工作，即 99,99% 的時間。 發送給我們的訂單必須保持順序，因為我們不能隨機打開或關閉訂戶的連接 - 一切都必須嚴格一致。 上一個訂閱會影響下一個訂閱，因此資料很重要 - 任何內容都不應遺失。
解決方法。 你可以嘗試正面解決並向資料庫開發人員詢問，但問題無法用數學方法解決。 你可以記住定理、守恆定律、量子物理，但為什麼 - 它無法在資料庫層級解決。
良好的舊架構方法在這裡起作用 - 您需要充分了解主題領域並用它來解決這個難題。
我們的解決方案：在 Tarantool 上建立應用程式的分散式註冊表 - 地理分佈式集群。 在圖中，這是三個不同的資料處理中心 - 兩個在烏拉爾之前，一個在烏拉爾之外，我們在這些中心之間分發所有請求。
Netflix 現在被認為是 IT 領域的領導者之一，直到 2012 年才擁有一個資料中心。 24 月 XNUMX 日天主教聖誕節前夕，該資料中心出現故障。 加拿大和美國的用戶失去了他們最喜歡的電影，感到非常沮喪，並在社群網路上寫道。 Netflix 目前在東西海岸擁有 XNUMX 個資料中心，在西歐擁有 XNUMX 個資料中心。
我們最初正在建立一個地理分散式解決方案 - 容錯對我們來說很重要。
這樣我們就有了一個集群，但是 RPO = 0 且 RTO = 0 又如何呢？ 解決方案很簡單，取決於主題。
應用中什麼最重要？ 兩部分：投籃 至 做出購買決定，以及 AFTER。 電信中的DO部分通常稱為 訂單捕獲 或 訂單洽談。 在電信中，這可能比在網上商店困難得多，因為必須為客戶提供服務，提供 5 個選項，這一切都會發生一段時間，但籃子已滿。 此時，失敗是可能的，但這並不可怕，因為它是在人的監督下互動發生的。
如果莫斯科資料中心突然出現故障，那麼透過自動切換到另一個資料中心，我們將繼續工作。 理論上，一件產品可能會丟失在購物車中，但您看到它後，會再次添加到購物車並繼續工作。 在這種情況下，RTO = 0。
同時，還有第二個選項：當我們點擊「提交」時，我們希望資料不遺失。 從這一刻起，自動化開始工作- 這是RPO = 0。使用這兩種不同的模式，在一種情況下，它可能只是一個具有一個可切換主伺服器的地理分佈式集群，在另一種情況下是某種仲裁記錄。 模式可能會有所不同，但我們解決了問題。
此外，有了分散式應用程式註冊表，我們還可以擴展它——擁有許多訪問此註冊表的調度程序和執行程序。
Cassandra 和 Tarantool 一起
還有一個案例—— “餘額展示”。 這是 Cassandra 和 Tarantool 聯合使用的一個有趣案例。
我們使用 Cassandra 是因為每天 2 億次呼叫還不是極限，而且還會更多。 行銷人員喜歡按來源對流量進行著色；例如，越來越多的詳細資訊出現在社交網路上。 這一切都為故事增添了色彩。
Cassandra 可讓您水平縮放至任意大小。
我們對 Cassandra 感覺很舒服，但它有一個問題——它不擅長閱讀。 錄音一切正常，每秒30次不是問題—— 閱讀問題.
因此，出現了一個帶有快取的主題，同時我們解決了以下問題：有一個古老的傳統情況，來自線上計費交換器的裝置進入我們載入到Cassandra中的檔案中。 即使使用 IBM 文件傳輸管理器的建議，我們也一直在努力解決這些文件的可靠下載問題 - 有一些解決方案可以有效地管理文件傳輸，例如使用 UDP 協定而不是 TCP。 這很好，但還有幾分鐘的時間，而且我們還沒有全部加載，呼叫中心的接線員無法回答客戶的餘額發生了什麼事 - 我們必須等待。
為了防止這種情況發生，我們 我們使用平行功能儲備。 當我們透過 Kafka 將事件發送到 Tarantool 並即時重新計算聚合時，例如今天，我們得到 現金餘額，它可以以任何速度轉移餘額，例如每秒 100 萬筆交易以及相同的 2 秒。
我們的目標是，撥打電話後 2 秒內，您的個人帳戶中不僅會顯示更改的餘額，還會顯示有關更改原因的資訊。
結論
這些是使用 Tarantool 的範例。 我們真的很喜歡 Mail.ru 的開放性以及他們願意考慮不同情況的意願。
對於來自BCG 或麥肯錫、埃森哲或IBM 的顧問來說，他們已經很難用新的東西給我們帶來驚喜了——他們提供的大部分內容，我們要么已經做了、已經做了，要么正計劃做。 我認為 Tarantool 將在我們的技術堆疊中佔據應有的位置，並將取代許多現有技術。 我們正處於該專案的積極開發階段。
Oleg 和 Andrey 的報告是去年塔蘭圖爾會議上最好的報告之一，17 月 XNUMX 日 Oleg Ivlev 將在 有報告 。 Alexander Deulin 也將在 MegaFon 上發表演講 。 讓我們看看發生了什麼變化，實施了哪些計劃。 加入 - 會議是免費的，您所要做的就是 ... 一切 會議議程已形成：新案例、Tarantool使用新體驗、架構、企業、教程和微服務。
來源： www.habr.com