作者丨趙鈺瑩
隨著云計算的不斷發(fā)展，很多開發(fā)者都對這一技術將為開發(fā)方式帶來的變化充滿興趣，云計算解決的是從 CAPEX 到 OPEX 的轉(zhuǎn)變問題。云可以帶來哪些切實的好處？在云環(huán)境下應該怎么做應用架構？基于從傳統(tǒng)架構到云架構的親身經(jīng)歷，阿里巴巴合伙人、阿里云智能基礎產(chǎn)品事業(yè)部總經(jīng)理蔣江偉（小邪）闡述了企業(yè)由新架構和新研發(fā)模式帶來的價值點。本文整理自正在召開的 QCon 上海 2019 蔣江偉（小邪）的演講內(nèi)容。
大家好，我是阿里巴巴合伙人、阿里云智能基礎產(chǎn)品事業(yè)部總經(jīng)理蔣江偉（小邪），本次分享的主題是“基于云架構的研發(fā)模式演進”，之前也有機會分享這個主題，但當時是作為電商的研發(fā)負責人，是站在開發(fā)者的角度思考問題。兩年前，我加入了阿里云，現(xiàn)在是站在云計算的角度思考這個問題。
當上云成為確定性趨勢，開發(fā)者應該關心哪些問題呢？站在我自己的角度來看這些問題，我在電商領域做了將近 9 年，在阿里云又干了 2 年時間，在這個過程中，我感受到最大的兩點不同：一是資源的彈性，二是穩(wěn)定性。
先說資源的彈性。在互聯(lián)網(wǎng)時代，我們更多是通過頂層架構設計，如多集群部署和分布式架構的方式來實現(xiàn)出現(xiàn)資源相關問題時的快速切換，我們做了很多事情都是在讓彈性變得更加簡單，并通過混部計算任務來提高資源利用率。在云上做這些事情是不一樣的，因為我們沒有辦法掌握客戶的架構體系，更多的不是從架構的角度來做，而是通過產(chǎn)品和商品的角度來解決問題。
再說穩(wěn)定性，過去二十年，我們通過硬件的方式不斷提升冗余性，互聯(lián)網(wǎng)時代通過分布式架構提升穩(wěn)定性，云計算是非常不一樣的，因為不知道用戶是什么樣的架構。
最后是可管理性，我們對應用的可管理性提出了一個暢想：云計算時代，應用的管理運維將更加標準化。
彈 性
首先看彈性，先看一下我在阿里巴巴的經(jīng)歷，我在做中間件的時候，做了一些服務器的預算，當我們的業(yè)務不可預測，比如一些創(chuàng)新的業(yè)務或者業(yè)務突然爆發(fā)，預算很難完全滿足需求，這時需要增加服務器，就需要重新做預算，這是非常痛苦的。假設我們有預算，設備上線也需要兩周時間，雖然這已經(jīng)是非?？斓乃俣攘?，但作為工程師，我還是更希望有時間把性能做好，把功能做好，而不是參與資源生命周期管理。事實上，服務器的負載非常低，部門之間也不愿意把服務器資源讓給其他部門，因為不知道將來用的時候還有沒有。人力的效率問題也非常低，要關注服務器的整個流程，但這些問題在云時代又有著不同的表現(xiàn)，比如云計算時代，客戶不需要自己解決網(wǎng)絡維修等問題，而我們又是如何解決這些問題的呢？
阿里巴巴采用了全站容器化的方式來解決這個問題，各種服務、各種中間件都實現(xiàn)容器化。所有的業(yè)務都容器化之后，就可以打通資源池。當有一個業(yè)務需要擴容時，我從公共池子里提供資源給他。當他不需要這些資源時，可以釋放回來。通過容器實現(xiàn)標準化，通過統(tǒng)一調(diào)度實現(xiàn)資源的使用申請和釋放。但是，整個推進過程也是非常難的，這可以稱為是一個 CTO 工程，自上而下推進全公司的容器化，包括數(shù)據(jù)庫、中間件、緩存... 通過建設統(tǒng)一的資源池相對可以緩解這些問題。
容器化之后，如何整體提高資源的利用率呢？特別是在線和離線。因為阿里巴巴的業(yè)務是峰值驅(qū)動的業(yè)務，在雙 11 和大促時，流量是非常高的，可以達到平時峰值的 30 倍，對計算有著更高需求，我們采用的方法是混部。雙 11 時，可以把離線的資源讓出來，把在線業(yè)務調(diào)度到離線服務器上，整個計算資源能夠更好地使用?；觳亢螅站Y源利用率從 10% 以內(nèi)提高到 40%。如果不是一家大數(shù)據(jù)的公司，服務器的資源利用率肯定是低于 10% 的，如果高于這個數(shù)值，風險也相對增加，這還是需要通過技術的方式解決這個問題。
總結(jié)下來，全站容器化、統(tǒng)一調(diào)度和混部都是通過架構的方式來提升資源利用率，本質(zhì)上就是云化的過程，產(chǎn)品化和商品化之后就是云計算。當商品化之后，資源池的規(guī)模擴大了很多，資源是即買即用的。
如果采用混部架構，電商日常的資源利用率是比較低的。雙 11 的時候，大數(shù)據(jù)的業(yè)務要降級。如果采用云的話，不需要使用架構上對混部場景重構的方式，也不需要預留這些資源。雙 11 的時候，直接使用云的資源，全部是容器化部署就好。
如下圖，我們做了這樣一個模型，日常（非大促時期）的資源使用，大數(shù)據(jù)占用了較多資源，可能換算下來是 350 天；雙 11 的時候，資源大部分被電商占用，換算下來可能使用的是 15 天，通過下圖可以看到云化后資源的使用成本進一步大幅下降。最重要的是，云化后不需要再關注復雜的混部架構，技術也相對簡單。我覺得能在下層解決的問題絕對不會在上層解決，如果運營都可以感知到架構的變化，這不是很好的體驗。
我們再看對數(shù)據(jù)的影響，過去做數(shù)據(jù)庫預算，做好分庫分表的規(guī)則，一般是做三年，三年之后數(shù)據(jù)庫會達到一個什么樣的使用量和訪問量，這就存在很嚴重的資源浪費問題，因為在到達三年之前，所有的計算和存儲資源并沒有被很好的利用和使用。如今，通過將計算和存儲分離，計算的節(jié)點是有彈性的，存儲通過分布式的方式來實現(xiàn)，存儲的節(jié)點也是可以擴容的，這樣就很好地解決了資源浪費問題。
云計算規(guī)模化帶來了新的玩法，這是我自己對電商的想法，電商大促時，計算資源不用單獨購買服務器資源，直接利用云計算池子里碎片的計算資源就可以。我們的客戶已經(jīng)這么做了，充分利用阿里云的搶占式實例，搶占式實例的起售價格非常低，只有標準實例的十分之一，當然需要工程師在架構設計上做好準備，把實例可用性的不確定性變成計算的確定性。因為搶占式實例可能一個小時后被回收，但是至少有一個小時的使用時間。
在阿里云上已經(jīng)有大量用戶，使用云資源的方式上領先于電商。比如，充分利用彈性的能力，使用按量付費的實例。我們有一個客戶，用幾分鐘的彈性資源使用時間完成了秒殺的過程。
下圖所示是一些具體事例，我們也有一個外賣行業(yè)的客戶，使用 ECS 是按小時使用的，可在業(yè)務低峰期停機不收費，高峰期啟動執(zhí)行業(yè)務計算。這樣上云后整體的 IT 成本降低了 20%，人均維護服務器數(shù)量提升了 3 倍。
總結(jié)下來，阿里巴巴曾經(jīng)是提前采購一些服務器應對大促，大促完成后給云計算。同時，我們也通過架構來提升資源效率和人力效率。之后，我們把這些工作產(chǎn)品化和商品化輸出，云計算上面有大量的客戶在用創(chuàng)新的方式在使用。
穩(wěn)定性
接下來，我跟大家分享穩(wěn)定性。過去二十年，大家都在使用硬件冗余或者通過單點技術突破來解決這樣的問題，直到今天，依舊有很多企業(yè)在沿用這樣的方式。我們的小型機非常穩(wěn)定，但是通過硬件冗余的方法來做的。那么，互聯(lián)網(wǎng)公司怎么解決穩(wěn)定性問題呢？
互聯(lián)網(wǎng)公司也是普遍采用了一種架構的方式來解決可靠性問題，就是分布式和集群的方式。同時，我們也通過框架、限流、流量預測來解決各種因為分布式問題帶來的缺陷。比如雙 11，我們通過壓力測試模擬雙 11 流量，通過架構優(yōu)化讓流量非常均衡。總結(jié)起來就是用大量的廉價服務器通過集群的方式解決單個節(jié)點不可靠的問題。阿里云上又不一樣，因為我們不知道客戶業(yè)務是什么樣子的，客戶認為云應該是可以保證數(shù)據(jù)穩(wěn)定性和可靠性的，但這是需要購買相應服務才可以享受到的，但客戶認為云就是需要具備這樣的能力，所以我們今天更多采用的是軟件和硬件結(jié)合的方式提高單點可靠性。
現(xiàn)在看來，這與過去二十年的目的是一樣的，不過解決方法不一樣。主要是云計算管理了海量服務器，基于歷史數(shù)據(jù)，磁盤和主板故障時間是可以預測的。當出現(xiàn)故障或即將出現(xiàn)故障時，我們可以進行遷移，客戶在這個過程中是沒有感知的。就像我們做了支付業(yè)務，后面接了螞蟻支付、微信支付和銀聯(lián)支付，如果其中一個支付出現(xiàn)問題可以切換到另外一個，用戶是感覺不到的。云計算也是一樣，單純硬件損壞是沒辦法避免的，但是通過虛擬化，當一臺硬件出現(xiàn)問題可以迅速切換到另一個，道理是一樣的。其次，我們結(jié)合了互聯(lián)網(wǎng)架構過去沉淀的一些經(jīng)驗和能力，比如壓測的經(jīng)驗、微服務管理的經(jīng)驗、故障演練和診斷的能力，將這些能力進行商品化，企業(yè)不需要自己做復雜架構就可以擁有這些能力。
簡單總結(jié)下來，早期，軟件和硬件都提供了單點的穩(wěn)定性。隨著規(guī)模的擴張，互聯(lián)網(wǎng)移動化的來臨，越來越多的企業(yè)選擇通過架構的方式提高穩(wěn)定性。但是，并不是所有企業(yè)都具有這樣的能力，云計算通過軟硬件結(jié)合的方式解決單點穩(wěn)定性，同時結(jié)合了互聯(lián)網(wǎng)架構整體提高了可靠性和冗余性能力。
我們內(nèi)部也有過探討，容器用物理服務器承載是比較好的方式，用虛擬機就做了兩層虛擬化。但是，采用物理服務器有些云計算核心的競爭力就沒法獲取了，一是彈性能力，二是云計算軟硬件結(jié)合的高可靠性，硬件資源的快速迭代等。因此，阿里云也創(chuàng)新地提出了神龍這樣一套架構，通過硬件 MoC 卡，把虛擬化卸載到 MoC 卡上面，性能得到顯著提升。我認為，容器的最佳載體一定是類似于神龍這樣架構的裸金屬服務器。一方面可以獲得容器的好處，另一方面也可以獲得云計算方面的好處。
OAM 正式開源
最后，我們希望云上的應用管理像手機 APP 一樣，手機 APP 肯定是標準化的。我們今天安裝和部署通過容器和 k8s 肯定是標準化的，但是這個應用本身你怎么去配置它，你怎么去運維它，它非常不標準。我們希望能夠定義這個事情，當然這個事情也剛剛開始。今天，我們阿里云聯(lián)合了微軟云一起發(fā)布開放應用模型 Open Application Model（OAM），項目主頁：
https://openappmodel.io/
OAM 是一個專注于描述應用的標準規(guī)范。有了這個規(guī)范，應用描述就可以徹底與基礎設施部署和管理應用的細節(jié)分開。這種關注點分離（Seperation of Conerns）的設計好處是非常明顯的。舉個例子，在實際生產(chǎn)環(huán)境中，無論是 Ingress、CNI 還是 Service Mesh，這些表面看起來一致的運維概念，在不同的 Kubernetes 集群中可謂千差萬別。通過將應用定義與集群的運維能力分離，我們就可以讓應用開發(fā)者更專注應用本身的價值點，而不是”應用部署在哪“這樣的運維細節(jié)。
此外，關注點分離讓平臺架構師可以輕松地把平臺運維能力封裝成可被復用的組件，從而讓應用開發(fā)者專注于將這些運維組件與代碼進行集成，從而快速、輕松地構建可信賴的應用。OAM 的目標是讓簡單的應用管理變得更加輕松，讓復雜的應用交付變得更加可控。
在這個模型里，開發(fā)人員負責定義應用組成、依賴與架構；應用運維人員負責定義應用運行時配置與運維需求。這是一個開源的項目，我們也希望開發(fā)者一起來參與這個項目并貢獻源代碼。
結(jié)束語
總結(jié)一下，我今天主要講了三件事情：一是彈性的問題；二是穩(wěn)定性的問題；三是阿里云與微軟合作發(fā)布的 OAM，定義了一套應用管理的標準和協(xié)議，希望開發(fā)者能夠像管理手機應用一樣管理云上的應用。
最后，云計算其實也面臨一些挑戰(zhàn)，比如穩(wěn)定性如何超過小型機、IDC 建設如何更加綠色節(jié)能、云計算如何更加值得信賴等。阿里云希望通過流程的方式、技術的方式，產(chǎn)品定義的方式推動云計算可信的發(fā)展，希望更多開發(fā)者能夠真正基于云來做整個軟件生命周期管理，從 Run on Cloud 發(fā)展到 Develop on Cloud。
