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