作者 | 馬超

編輯?| 胡巍巍

來源?| CSDN（ID：CSDNnews）

近年來，紅包大戰堪稱是新春佳節中最精彩的開年大戲。

2015年騰訊以超過5000萬元的天價，拿下央視春晚獨家合作權，一夜之間為微信支付帶來1億多張新增銀行卡綁定，僅用一天就完成支付寶幾年走過的道路，被馬云稱為阿里史上的珍珠港事件，自此也開啟了互聯網巨頭春節紅包營銷的序幕。

2016年春晚，支付寶砸下2.69億奪得央視春晚的獨家合作權，并創造史上最經典的集五福紅包玩法，當年支付寶宣布向全國觀眾豪派8億元紅包，除夕當天，支付寶上加好友、換福卡、發紅包的次數達到677億次。?

而2020年春節，快手早早就與央視春晚達成獨家合作關系，本以為今年紅包大戰的C位已經沒有懸念，但是阿里突然在1月11日宣布成為淘寶春晚獨家電商合作伙伴，雖不發紅包，但是阿里帶來了10億元的購物補貼，并將抽取5萬名消費者清空購物車，為紅包大戰再添了一把火。

而今年令人糾心的疫情，也必將使線下活動有所減少，同時也會增加線上活動的熱度，這些客觀因素都必將使今年的紅包大戰更具看點。其實從技術角度講紅包大戰最大的看點是云計算。

搶紅包背后的技術看點之一：分布式架構

如果想承接搶紅包這樣一個短時上億并發量的場景，即便是世界最強超算也力不從心，所以這就要求紅包系統首先要滿足分布式架構的需求，而分布式系統也有一個重要的原則CAP定理。

CAP定理：是指在一個分布式系統（Distributed System）中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance），呈不可能三角關系，既三個目標只能同時做到兩點，不可能三者兼顧。

其實CAP定理并不難理解，因為如果滿足一致性、高可用性，那么一旦集群內有節點故障，為保證數據一致，必將使系統整體陷入中斷。

如果既滿足可用性、又滿足分區容錯性，那么必然存在某個節點在系統對外提供服務時出現宕機，而這時各節點的數據一致性，又無法完全保證。

結合紅包系統的需求分析，系統可用性肯定是要首先保證的，如果真是春晚當天頁面無法訪問，那恐怕營銷不成，反而會讓用戶路轉黑了。

而且在大流量的沖擊下，節點故障也是難免，因此分區容錯性也需要保證，這樣看來，能稍微放一放的只有數據一致性，因此從這個角度上講，紅包的總額必然會圍繞期望值上下浮動。

目前分布式系統交易分發，一般有兩種方式，一是哈希法，將服務請求序列化后計算哈希值，然后根據這個哈希值將請求分配到不同的節點上，當然直接把請求按照順序循環發送集群內的服務器，也可以看作是哈希法的變種，不過這會使入口處的負載設備成為瓶頸。二是將所有請求人為分成幾份，每個集群只處理自己接到的請求，以此為降低入口流量的壓力，但這樣的缺點是，很難將請求平均分配。

搶紅包這樣的系統，只能將以上兩種方案結合。首先根據歷史經驗，將交易量相量的地區結合，分為一組，比如北京、天津和遼寧、長春分為一組、上海、蘇州、南京分為二組等等以此類推，與之對應的云集群，都有自己獨立的紅包額度，也只處理發給自己的請求。這樣能避免入口的瓶頸，也盡量平均分配了請求的處理量。

接下來每個集群，也會將額度分配給內部的服務器，然后每個服務器會將自己庫存范圍內的請求，直接標志為成功，并在自己庫存范圍的基礎上，還會多預留一定比例的需求為待定，待統一減庫存后再確定能否待請求能否成功。

從分布式的角度來看，分區域與分庫存是系統設計的基礎環節，而接下來要做的就是上云了。

搶紅包背后的技術看點之：云計算

2019年雙十一，阿里宣布自身全部核心系統已經完成上云，這是一個非常驚人的成就，隨著傳統的軟硬件分離，迭代的模式逐步顯現出局限性，現今的應用越來越復雜，對算力的要求越來越高，而算法、軟件和硬件的隔閡造成巨大算力的浪費，已經無法滿足在超大規模計算機場景下，提升IT計算效率、降低計算成本的訴求。

這時“云”的價值開始體現，但是云時代軟件開發的方法論與模式，與之前時代完全不同，因為云最大的特點就是可持續交付和微服務化，完全上云不但有巨大的好處，也意味著巨大的挑戰。

分布式與云計算就像一對孿生兄弟，必須要結合使用才能發揮出最大的價值，分布式系統的各節點最好都是整齊劃一，這樣調度成本都可能會降到最低。

而如果出現有的節點算力強，有的節點算力弱，那么受木桶原理制約，系統的性能就很可能被算力最弱的節點所限制，而云這種屏底層，向客戶交付標準化硬件的技術，在分布式的架構下就會大顯神威。

也恰恰是由于以上原因，我們可以看到參與這種紅包活動的企業，往往都是純線上企業，因此一旦企業有線下網點的布局，那么在參與紅包活動時都需要考慮給網點的發起請求調高優先級，進行區別對待，這種非標標準的請求會讓系統復雜度呈幾何級數增長。

所以從云的角度上看，用戶搶的不是紅包，而是在各自區域請求中隊列中的云資源。

國產云計算發展的坎坷之路

雖然“云”的好處很多，但是其發展并不算特別順利，在十年前概念提出伊始，普遍不為人看好，甚至被某IT大佬戲稱，“云計算只是新瓶裝舊酒”，其背后的原因還是虛擬化層所耗的資源無法避免。

在阿里云創始人王堅院士，參加央視《朗讀者》節目時曾表示，阿里云是工程師拿命來填的，因為第一個用電的人，第一個坐飛機的人也是拿命來填的。

這還真不是危言聳聽，在成立最初幾年，阿里云的年離職率高達60%以下，甚至在2012年阿里的年會上，王堅還因為看到了那些離開的同事，而失聲痛哭。

但情況從2015年開始改觀，阿里云在Sort Benchmark的排序競賽中，僅用不到7分鐘就完成了100TB的數據排序，打破了Apache Spark之前23.4分鐘的紀錄。

后又獲得2017年中國電子學會頒發的科技進步獎之特等獎，這也是該獎項設立以來的首個特等獎。

接下來，神龍服務器和飛天操作系統的誕生，基本克服了云的弱點，并將云的規模效應發揮到極致。

神龍服務器：阿里云降低虛擬層消耗的秘決，在于神龍服務器這塊完全自研的MOC卡，正是MOC的居中調度，讓阿里神龍服務器不再使用寶貴的CPU資源進行虛擬化層的調度工作，從而大大降低云轉換成本。

飛天操作系統：正所謂韓信點兵，多多益善，飛天能將百萬級服務器連成一臺超級計算機，還能有條不紊地通過云計算向用戶提供計算能力。

我們看到在飛天的基礎公共模塊之上，有兩個最核心的服務，一個是盤古，另一個是伏羲。

盤古是存儲管理服務，伏羲是資源調度服務，飛天內核之上應用的存儲和資源的分配都是由盤古和伏羲管理。具體見下圖：

可以看到飛天中的眾多模塊都是以上古天神命名的，其中：

夸父：負責網絡通信，由于飛天是要將眾多服務器連接在一起的，夸父正是完成他們之間的通信功能。

女媧：與負責命名與協同工作，與神話中造人的工作不同，做為飛天中的唯一女性女媧負責將所有子模塊的命名與協調工作。

盤古：負責分布式存儲。

神農：負責監控，隨時治病救人。

伏羲：負責任務調度及資源管理，這也和精通音律和伏羲氏有點淵源。

大禹：負責集群布署。

鐘馗：負責安全，負責捉鬼。

在國產云計算行業，其它大廠也都有各自的特長，比如騰訊做為全球社區的巨頭騰訊，其QQ類的社交軟件，面對著比其它應用多出幾倍的流量短暫時突發場景，在面對這樣的問題時，以虛擬機為單位補充資源，會很浪費資源。

因此騰訊在容器化方面做了很多細節工作，以滿足這種突發、短時的彈性需求。

而騰訊近期開源的TencentOS Kernel，在容器運行所需的資源調度彈性、系統性能及安全等層面做了很多優化，可謂是開源+“容器云”的典范。

未來：打開水龍頭就能使用云

通過自主掌控的技術，國內的科技巨頭，在云計算領域已經走向了世界的前列，通過云大幅提升計算效率，實現能夠突破傳統IT時代的算力瓶頸，凸顯云計算的整體優勢。

云正在與區塊鏈結合成為Baas，正在與AI結合成為Aaas，云正在不斷下沉，變成互聯網時間的空氣和水一樣基礎設施。

而未來我們可以不再關心云計算背后的細節，就像不用關心水是如何過濾、運送一樣，打開水龍頭就可以使用到云，未來云計算的發展空間和使用場景還會不斷拓寬，未來可期，拭目以待。?

【END】

熱 文?推 薦?

?「今天沾一口野味，明天地府相會！」AI如何抗擊「野味肺炎」

?無代碼開發究竟是不是偽需求？

?云計算的 2020：云原生崛起，重新定義軟件

疫情嚴重，潛伏期也有傳染性？科技公司在行動

?程序員談從科比的曼巴精神中，我們能學到什么？

用開發者的方式共克時艱！

總結

以上是生活随笔為你收集整理的你抢的不是春节红包而是云的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。