漫畫 - 一口氣搞懂 Serverless ！
呃，我可能是別人眼中所說的不用奮鬥的一代。
大家喜歡聽的什麼多姿多彩的生活，我都經歷過一些些。
我家裏開的是連鎖超市，主要集中在幾個二線城市。
在我上小學的時候，各連鎖店裏開始裝電腦，購置並安裝了完整的收銀設備。
我爸說要向那些大的連鎖超市學習，提高生產效率。
那個時候我對那些灰色界面的收銀軟件很感興趣，可惜爸媽不讓我碰。
後來他們給我買了電腦，當時小鎮上有電腦的人家不多，親戚的小孩也常常跑到我這兒來玩電腦。
也正由於和電腦接觸得早，上大學時就選了計算機專業。
我纔剛上大學沒幾個星期，我爸就問我：
那個時候我連數據庫什麼的都還沒有個概念，還在學反碼補碼，我告訴他：能，但現在不行，等我一兩年。
我爸說不要緊。按照他的思維，我們不需要完全會寫，只要明白怎麼寫出來就行，具體的實現我們可以交給軟件公司做。
但搞明白軟件是怎麼造出來的很重要，因爲這能夠幫助我們在購置軟件時站在供應商的角度思考，知己知彼，縮小我方信息差。
做買賣本質上玩的就是這一套。
2005 年，我大三，學校要搞一次軟件開發大賽，一共有三個命題，其實基本涵蓋了所有場景，學生可以自由發揮。於是我就想到了超市的收銀軟件。
當時淘寶剛火起來，我想爲啥不學習一下呢， 徹底革新我爸的商業模式，從線下轉到線上！
整個網上商城， 瀏覽商品，購物車，下單，配送，但我們主要賣的是自己的貨源。
當時用到的技術是 MySQL+ Java + JSP，然後自己買了服務器讓服務跑起來。
在學校演示這套系統時，我拿了最高的成績。
滿心歡喜之餘，我嘗試把這套系統用到實際業務中，先從自家的總店開始試點。
沒想到我爸給我潑了一盆冷水，他說我們這裏的用戶沒有上網購物的習慣，送貨問題沒法解決。
我不服，非要嘗試，果然理想與現實間存在着巨大的差異，我跌了一個大跟頭。
雖然我搞了很多活動，發傳單宣傳商城，但真正上網購物的寥寥無幾。
有些願意嚐鮮的，在網上買了東西，都是我親自開車送貨的。
畢業回家，我本想出國留學，但被我爸拽了回來， 我先跟着信息部的負責人老張學習，然後慢慢接班。
當時家裏的每個超市都很大，都有一二十臺 POS 機， 每個超市有一臺服務器，一個數據庫。
POS 機直接連到本超市的服務器上， 典型的客戶端 / 服務器結構。
在那個時代，我估計大家都是這樣的吧！
說實話，這樣的軟件架構表面看似挺穩的，只要機器不出問題，穩定供電，整套收銀系統就沒有問題。但實際上面臨着許多缺陷：
-
機器是真的會壞的，而且真的有壞過的案例
-
每次有商品數據要更新都要通知每一家店的管理人員進行更新，出現紕漏是很正常的
-
更新軟件的時候，工程師需要到各個現場配置，更新
-
各個店面統一數據困難，每個月統計數據的時候需要統一彙總，不能隨時隨地得知當前各分店的數據
-
等等......
每一家店單獨運作一套系統，這缺點要是列下去就沒完沒了了
我建議老張搞箇中央機房，把軟件集中化，每個門店都連接到統一的機房服務器，這樣就把上面的問題給解決了：
後來的系統改造，經過投標、招標，我們選了本地一家頗有實力的公司來做。
我發揮了計算機專業的優勢，幫助老張發現了不少問題。
看來我爸說的是對的，縮小信息差很重要。
中央機房運作了幾年，效果不錯， 不過自家的機房管理起來非常麻煩。
平時需要仔細規劃、購買服務器，需要安裝軟件， 需要負責運維，我們還專門建立了一個團隊來應對這些事情。
更可氣的是黑客攻擊無處不在
還有就是宕機、斷網，一出事就是大事，影響所有的超市，我在半夜不知道被叫醒了多少次。
這還不算啥，有一年爲了配合超市雙 11 期間促銷，我讓我爸一下子買了好多服務器，雙 11 過後，全部閒置了，把我爸氣得夠嗆。
所以當阿里雲出現的時候，我兩眼放光，這簡直就是爲了解救我而設置的。
馬上、立刻、全面上雲。
操作系統會按照你的要求自動給你安裝好。網絡自然不用操心， 要多大帶寬直接買就行。
安全問題也不用操心，如果出了問題，我就可以理直氣壯地給我爸說：你看，這不是我的問題，是阿里雲的問題，哈哈。
而且機器能很方便地擴容，CPU 核心從 4 核到 8 核，內存從 16G 到 64G......
從此以後，我們的機房中的服務器要下崗了。
轉眼間，十多年過去了，伴隨着超市 IT 系統的發展， 我也從一個用 JSP 寫網上商城的少年成長爲公司的技術領頭人。
技術在不斷變遷， 小程序興起，我們也跟着做了小程序，用優惠信息吸引顧客掃碼關注、註冊，慢慢地積累了幾百萬粉絲。
每個月我們都在小程序給會員發送優惠券，可以在線下門店消費。
沒想到這下可慘了，搶購優惠券的請求量很難準確估算，也就很難預估需要準備多少臺虛擬機來應對。
我趕緊發動我所有的關係去解決這個問題，一個偶然的機會，我發現了一個新技術：函數計算， 即 Serverless。
平臺會根據請求的數量來創建對應的函數實例來執行，無需人工干預，瞬間彈性擴容，應對流量爆發。
在中國，誰家的 Serverless 技術最強呢？
權威諮詢機構 Forrester 發佈的報告顯示， 阿里雲函數計算憑藉在產品能力、安全性、戰略願景和市場規模等方面的優勢脫穎而出，產品能力位列全球第一，這也是首次有中國雲廠商進入 FaaS 領導者象限。
正好我們之前用的也是阿里雲的虛擬機，就是它了！
除了函數計算外，由於業務需要查詢會員數據庫，我們希望它也能無縫彈性擴展，於是就使用了阿里雲的表格存儲。
上了這套 Serverless 的系統， 再也不用考慮服務器，虛擬機用多少 CPU，多少內存了，彈性十足！
函數部署也特別簡單，完全不需要考慮底層的細節，一鍵更新函數就搞定。
當年的雙十一度過得非常平穩，事後進行成本估算：以前買雲服務器的時候，會按照可能遇到的最高併發量進行性能評估，由於 Serverless 是按量計費，用多少花多少，最終評估下來，當年在成交量增加 120% 的情況下，成本比往年節省了 45%！研發交付效率提升也超過 30%！
從那以後，我爸對我刮目相看，看我的眼光都溫柔了不少。
當然，除了技術之外我還是很關心業務的，貼合各種當代的新潮玩法。前不久給公司搭了個直播間，在平臺上促銷自己的商品。
後來想了想，自己玩沒意思，我嘗試聯繫了超市附近各行各業的商家，邀請他們加入我的直播間，一起嘮嗑賣貨。其實當時沒多少店家搭理我，唯獨一家洗浴中心的老闆對這個感興趣。
不得不說，那洗浴中心的老闆嘮嗑能力極強，和我算是棋逢敵手。
第一次直播時，我們連鎖超市和洗浴中心各家分店搞了一次聯合優惠活動，但當晚直播竟然從賣貨推銷變成了講相聲。
直播我們每週舉辦一次，越來越多網友聞聲而來，成交的訂單數也越來越多。直播當晚的成交量甚至能抵上過去一週的總量。
直播過程中總有熱心的網友主動連麥， 從技術上來說，就需要把多個網友的畫面接入，和主播的畫面合成一個新畫面， 這叫 “混流”。
由於連麥的觀衆不固定，我得考慮一定的併發和彈性，我們的相聲直播一週才一次，不可能去儲備大量服務器去應對業務的高峯期。
之前嘗過 Serverless 的甜頭，這次我立刻讓研發部採用阿里雲函數計算來處理混流的需求。
當併發量上升時，函數計算自動擴容多個執行環境來處理實時數據流， 當業務高峯期過去後，自動縮減資源，非常爽。
當然，Serverless 的應用不僅僅是這些，還有我們的 “相聲” 視頻需要做轉碼，優化推流，我也用了阿里的函數計算，節省了 60% 以上的計算資源。
這兩年，我是深刻地體驗到了 Serverless 的好處：完全不用考慮服務器的事情，集中注意力實現自己的業務邏輯就好！
這麼多年，一路走來，技術在不斷變遷，今年我有幸被母校的計算機學院邀請去作分享，我給大家分享了這些年的技術歷程
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/o0fXfB12B8NO4Im4h8UNPQ