演講嘉賓簡介：
蔣江偉(花名:小邪)，阿里巴巴集團副總裁、雲智能基礎產品事業部負責人。
以下內容根據演講視頻以及PPT整理而成。 本次分享主要圍繞以下四個方面：
一、上雲的核心
二、資源使用方式演進
三、穩定性演進
四、探討與總結
一、 上雲的核心
1.目的
電商與雲架構的演進方式和思路一致，圍繞兩個目的。第一，研發角度希望使系統的研發方式變得像一臺服務器一樣，例如客戶訪問、交易、商品、用戶等系統，增加一臺服務器，只需要把服務器添加上去，配置好IP的址就可以直接上線，獲得一臺服務器的計算能力。就運維角度而言，幾十萬臺服務器的管理方式希望與一臺服務器一樣。因此研發角度和運維角度的本質都是希望通過研發的不斷演進使若干服務器像一臺服務器一樣使用並管理。
2.當上雲成為必然趨勢，開發者關心什麼
當前“上雲”已成為必然趨勢，“上雲”的核心分為以下三點。
彈性：當開發者需要資源時能夠即刻擴容。由於應用系統架構非常複雜，涉及成百上千個系統。希望當每一個應用系統遇到彈性問題時都能很快擴縮容。
穩定性：穩定性經歷了幾個階段。首先，過去20年，穩定性是以硬件的穩定性來驅動的。例如一些小型機通過硬件的冗餘、容災實現計算資源的穩定。進入互聯網時代之後更多是通過架構的方式使系統更加穩定。但很多公司不具備通過架構保障穩定性的能力，需要直接購買物理資源，希望系統更加穩定。因此雲演進到使用廉價PC，可以保證資源相對更加穩定。
可管理性：各種公司提供各種各樣的應用系統，在雲上為更多客戶服務。那麼雲端應用、系統的管理能否夠做到和手機管理APP一樣方便，能否對不同的公司開發的應用系統、運維繫統簡單的進行管理和運維？
二、 資源使用方式演進
1.阿里巴巴早期資源管理模式痛點
資源效率相對低，人工效率相對低：資源預算往往無法準確評估。特別是在業務高速發展時，可能突然有一塊業務超出了預期，例如廣告業務的增長，此時需要的是中間件的資源。如果資源預算準確，運維人員或資源供應人員將根據預算來提供資源。但資源預算週期很長，以周為單位。當資源預算不充分時，需要增加資源。增加資源需要進行評估、層層審批、說明佔用資源目的等流程，對於工程師而言十分繁瑣。
資源預測不準確是常態，並且是非常正常的。資源預測不準導致購買資源、使用資源過程中出現了各種工程師需要關注的問題。事實上，不同的部門或應用之間的資源使用率非常低。例如消息中間件因為某一塊業務對消息使用的突然增長導致資源不夠。而此時其它系統有很多資源，系統的load負載非常低，此時能否使用其它系統的資源就是一個更復雜的問題。沒有統一的資源調度能力時，各業務部門管理使用自己的資源，在線的很多系統資源佔用並不高，而某個部門由於擔心資源無法回收，借調資源流程複雜等原因，不願意對其它部門釋放資源。
2.架構優化提升資源使用效率
全站容器化和統一調度：統一資源調度的前提是全站容器化。希望不同的應用、系統、中間件、緩存等都能夠跑在容器裡面，就可以進行統一的資源調度。合併資源池後，通過資源池分配以及調度所有資源。全站容器化與資源池合併，進行全局資源統一調度，非常好的解決了不同業務單元之間資源共享的問題，提高了資源利用率與庫存利用率。不同業務單元（例如交易業務與搜索業務，跨行業業務）的峰值及峰值時刻不同，因此需要通過資源池合併來充分使用資源。其優勢在於統一調度資源的效果遠遠好於一個業務單元自身通過系統、機器、代碼優化等充分使用資源的效果。
運維標準化：統一資源調度節省運維成本，提高了交付效率和運行穩定性。由於資源調度的技術方式是一致的，統一資源調度中投入的研發或運維不僅使調度產品變得更加容易使用更加產品化。同時需要投入的人力資源也更少。目前容器化和統一資源調度已經漸漸成為行業發展演進的趨勢。
混部資源池提升資源使用率至40%：不同的系統在不同時刻的峰值不同。例如阿里巴巴雙11活動時峰值非常高，日常峰值與雙11峰值可能相差30倍。現在由於阿里雲的存在，雙11處理變得非常簡單。然而在過去不理想的狀態下，準備著雙11的資源量，而平時只需要1/30的資源，資源浪費非常嚴重。從技術演進的角度而言，可以將在線數據與離線數據進行混部。離線數據基本上是在在線數據產生之後進行離線計算。在線業務的峰值時間與離線業務的不同，並且離線業務可以接受部分有損，即可以接受報表生成時間稍延後（而非數據準確性有損）。而在線業務不能接受部分有損，比如用戶下單時需要實時反饋，而不能在下單五分鐘之後顯示購買是否成功。當前混部資源是發展的技術趨勢，即把離線業務部署到在線，在線業務部署到離線。在全站容器化統一資源調度的情況下，在雙11活動峰值很高時，將在線業務調度到離線，使用離線資源補充在線資源，通過離線資源來談在線業務，就可以大幅度降低當天的資源消耗。平時也可以將離線資源部署到在線業務上，得到了非常好的收益。
混部後資源使用效率從10%+提升到了40%，有效降低了企業在硬件資源方面的投入成本。
3.雲計算
產品化解決方案：容器化、統一調度、混部等都是架構優化方案。要讓離線跑到在線，在線跑到離線，仍然涉及很多需要工程師解決的問題。而云需要的是產品化、商品化的解決方案，實現資源即買即用。使工程師或用戶不需要複雜架構即可實現資源使用效率和人工效率的顯著提升。容器化、全局資源調度、混部等是互聯網公司演進的基本邏輯，可以大幅度提升能力效率與資源效率，再據此進行產品化演進。例如當前阿里雲的一些產品性能較好，穩定性較強。是由於阿里雲背後有豐富的業務場景的錘鍊，例如雙11、業務複雜度問題等，都使產品成熟度更高。
全站雲化降低電商成本：首先，大家需要注意的點是，面向雲的研發模式與面向互聯網的研發模式存在異同。相同點是目的都是為了像一臺服務器一樣簡單的管理雲端計算資源、研發系統架構。不同之處在於其資源池大小。容器化、統一調度、混部等架構優化方案的確可以降低電商成本。使用產品化方案雲計算電商成本可以更低。下圖為模擬混部與雲計算在降低電商成本方面的對比，橙色部分表示跑在雲上的方案，藍色部分為混部方案使用。任何一項業務都有峰值、低谷。可見非雲的混部方案利用自己持有的資源，不利用雲資源，除峰值以外的日常時期佔用過多資源，水位跑不滿。以雙11為例，峰值時期混部方案在跑滿的情況下資源仍然不夠，需要額外籌備或購買雲資源。雲計算方案可以彈性釋放多餘資源，因此日常以及雙11峰值狀態下都是跑滿的。架構方案在混部、全局調度等情況下的年成本為1475單位，並且技術相對複雜，存在業務降級，需要研發人員的持續關注。而云化方案成本僅需要848單位，同時技術相對簡單，業務無降級，人力資源的投入將更低。
雲化為數據庫應用帶來很好收益：數據庫的預算比較複雜。流量、併發量大時需要做分庫分表，最終通過Hash方式對某一個id進行Hash。數據庫一般每三年做一次預算，做一次資源儲備，因此數據庫資源浪費十分嚴重。該問題的核心是存儲、計算未分離，即使計算量不高時也佔用大量的計算資源。PolarDB X是阿里雲自研的一款優性能產品。從MySQL分庫分表到PolarDB X存儲、計算分離的演進是典型的數據庫雲化過程。PolarDB X使用分佈式存儲，其優勢是可以彈性釋放多餘計算資源，也可以彈性收回資源。阿里雲上有三個基座：神龍解決計算方面問題，盤古解決存儲部分問題，洛神解決網絡問題。盤古早期就支持了雲上和集團的各種業務，實現了計算與存儲的分離，按需申請存儲資源，產生了良好收益。盤古云化後成為了商品，PolarDB 和PolarDB X都可以直接使用。阿里雲數據庫的性能、運維等方面優勢明顯，直接基於阿里雲的數據庫進行研發等操作可以大幅度降低成本。
雲計算規模化帶來新的玩法——搶佔式實例：以搶佔式實例為例。搶佔式實例的SLA不太高，價格十分低廉。搶佔式實例並非阿里雲原創，在AWS上已經是一套非常成熟的機制，並且在很多公司得到良好使用。下圖為某移動廣告及數據分析公司使用搶佔式實例，成本得以大幅度下降。服務器切割後存在一些碎片資源、庫存資源等，將其作為搶佔式實例進行收買。搶佔式實例的SLA不能保證，當其它客戶需要完整的一塊資源時，可能恰好包含某一塊碎片資源，該實例就可能會被釋放，但是回收前5分鐘會通知客戶。當然如果客戶研發能力較強，可以通過PASS平臺建立自己的平臺，利用大量碎片資源進行調度，可以在保證SLA的情況下使成本儘量更低。在研發能力強的情況下，比如阿里雲，使用搶佔式實例只需要使用正常計算實例的20%左右，就可以得到解決同樣問題的計算能力。
高效使用資源案例：如下圖所示，某些在線旅遊網站利用業務峰值、時間進行彈性付費；某些媒體公司利用熱點事件快速進行彈性操作；某些渲染公司使用搶佔式實例、經濟型實例等降低成本，提高渲染效率。下圖為過去數據，目前效果數據應該更加優秀。
面向雲的研發與過去不同。從前的資源池可以視為小池塘，而面向雲的資源池如同大海。雖然看似雲端資源有些浪費，但是整體而言更有優勢。下圖所示為某O2O公司上雲後資源使用效率較線下效率顯著提升。該公司業務峰值在午餐、晚餐時間，一次性服務器採購成本高。該公司面向雲利用全局統一資源調度、容器化、秒級彈性實例等操作解決了日峰值問題，節省了成本，提高了服務能力。
三、 穩定性演進
穩定性是每一家公司都十分關注的性能，穩定性直接關係到產品優劣、客戶滿意度，非常重要。穩定性的演進過程可大致分為以下三階段。
1.早期IT時代
商用軟、硬件廠商提供穩定性：用戶架構簡單，成本高。主要使用主機、小型機等方式保障穩定性。過去以現在做架構的方式在硬件層面做了很多與穩定性相關的操作，相應的其成本比較高。例如通過冗餘的方式，使用兩塊綁卡、更多內存，在一條鏈路失效時切換另一條等方式。
2.互聯網時代
架構優化提高穩定性：技術複雜，成本低。使用廉價PC Server不如小型機穩定。由於內存、主板、CPU、內核等各種原因，使用PC存在萬分之三的服務器宕機率，但相同計算密度下價格非常低廉。因此需要通過架構優化提升穩定性。當一臺服務器IP不通時可直接將其從集群中剔除，當整個集群存在問題時將業務切換到另一個集群上。例如阿里巴巴電商業務，甚至當某的的服務器不可用時可以切換到另一的的服務器上工作，架構非常靈活且高可用，擁有強大的調度、容錯容災能力。
高可用架構-容量能力：三八女王節活動需要做容量確定，確定需要多少筆交易能力。對每一個應用都需要進行容量規劃、確定其所需計算資源，並進行全鏈路壓測。
高可用架構-應用治理：需要了解應用之間的依賴關係。通過應用間的依賴關係可以進行鏈路跟蹤、故障演練、監控、判斷緩存是否失效等多種操作。
高可用架構-運行管控：例如容量確定並不一定能夠滿足所有容量能力，需要進行限流降級。例如客戶需求為峰值100筆交易能力，而業務方認為該數值過高，只提供80筆交易的能力。在峰值時期對20%的交易進行限流，其它時間80%的交易能力足夠使用。那麼在峰值的幾分鐘時間進行一定限流，既不影響大部分正常時間的交易，又能節省20%的資源儲備，是十分合適的。另外可以實現開關預案、監控報警等功能。
高可用架構-容錯容災：包括同減雙活、異的多活、流量調度等能力。
3.雲計算產品化
雲計算通過軟硬件結合提供很高的單點穩定性：用戶架構簡單，成本低。不計成本價格情況下，雲的理想模式是出售小型機、同時擁有互聯網架構的產品與能力，在單機穩定的同時架構能力也非常強。雲上客戶有大有小，技術能力參差不齊，但是對雲產品、對服務器的要求同樣嚴格。阿里雲目前提供的SLA指標是全球最高指標，為其投入了大量資源。阿里雲希望單機穩定性、可用性都可以達到非常高的標準，為客戶提供比物理機更高的穩定性。雲服務器的生命週期約3年，不如小型機生命週期長，雲在硬件、在服務器中實現高可用性就成本而言並不划算。並且雲是使用廉價硬件實現高穩定性，抬高物理資源成本並不符合雲化趨勢。因此客觀而言，雲計算達不到小型機的穩定程度。
雲計算提高穩定性的方法如下圖所示。通過商品化方式提供單點穩定性和分佈式全棧化的產品和解決方案。例如硬件系統監測+AI故障預測，可以預測磁盤、主板等損壞的時間、故障率、故障誘發原因等指標，提前預警以便遷移應對。雲上可以進行熱遷移，在預測出故障的情況下及時遷移計算實例，消除故障於無形，宕機率降低到原來的1/5。另外高可用全網部署能力可以消除硬件故障及對業務的單點威脅。例如通過分散資源部署到不同批次，不同位置。實現上述能力的前提是需要有一定的規模，因此業務規模越大，方法越有效，穩定性越高。
全棧穩定性解決方案及產品：利用互聯網沉澱的一些能力，利用阿里巴巴在金融、電商、物流等方面沉澱的能力，輸出了一些高可用性產品。其中PTS是一款全鏈路壓測工具，在架構互聯網化的前提下可以發起大規模的在線業務全鏈路壓測，高仿真線上峰值流量。PTS能夠精準判斷支持目標的QPS、TPS所需的資源，判斷並均衡系統資源。
四、探討與總結
1.容器的最佳載體探討
物理機or虛擬機？容器是當前發展趨勢。許多公司基於物理機做容器服務。客觀而言，通過虛擬機對容器進行多次虛擬化並不好，基於物理機做容器服務是最好的。但是基於物理機做容器服務就失去了雲的優勢。雲有五大優勢。第一是彈性能力強，可以大幅度降低成本，提升可用性。第二是供應鏈效率高，不使用雲，就不能通過鼠標的簡單操作建立計算實例，而要進行諸多複雜操作流程。第三是財務效率高，不使用雲時是一筆持有三年、四年的資產，而云上購買服務器後永久擁有。第四是穩定性好，雲服務由專業公司提供穩定性，比客戶自己保障穩定性更強。第五是雲上產品豐富度高，並且不斷推陳出新。其中包括阿里雲的產品，也包括其它合作伙伴推出的產品，客戶自己研發的東西也可以產品化、服務化，提供給雲上其它客戶。因此雲上生態更加繁榮。
神龍子系統：其主服務器為第三代虛擬化技術，為容器服務而生。第一代虛擬化技術以VMware為典型代表，第二代以Xen與KVM為代表。第三代虛擬化技術即軟硬件結合，彌補前兩代的缺陷，以硬件方式進行虛擬化，虛擬化開銷幾乎為零，成本大幅度降低。
如果客戶希望擁有更強的管控能力，可以在運維管控方面投入更多資金、人力，那麼可以採用神龍子系統做容器服務。當然也可以使用雲虛擬組建或其它服務器。
2.像管理手機APP一樣管理雲端應用
阿里巴巴呼籲通過標準化簡化雲端應用的管理。否則不同公司提供的服務、軟件、應用系統的管理方式不盡相同，涉及大量研發、測試、生產環境，專有云、公共雲、IoT環境，流程複雜，管理困難。而每一個手機用戶都可以便捷的管理手機APP，其核心就是標準化，例如安卓系統、華為系統等。
3.Open Application Model
阿里雲聯合Microsoft Azure發佈了OAM（開發應用模型），是全球首個雲原生應用標準定義與架構模型。OAM在開發人員層定義應用的組件、依賴以及架構，在運維人員層定義應用的運維配置和運行時參數，在平臺層執行OAM應用描述。使OAM可以一鍵安裝、多處運行，使用標準化方式透出平臺的基礎能力與特性。只要符合OAM標準，不論在阿里雲、其它雲還是在其它個人搭建的KPS環境都可以進行更加方便的管理。
4.總結
雲計算創新：基於雲架構，開發者在研發與運維模式上不斷創新。專注雲上資源的使用，雲廠商提供資源和靈活使用資源的工具。充分利用雲計算解決應用穩定性問題。通過OAM，雲上應用管理和手機APP管理一樣簡單。
雲計算挑戰：第一，穩定性超過小型機，同時保證價格低廉。第二，IDC建設更綠色節能。第三，可信科技創新持續穩步提升。第四，從Run on Cloud到Develop on Cloud。
雲未來：隨著計算機互聯網化，計算機愈加影響到人類生活的方方面面，帶來了巨大價值。雲計算與之相似，雲資源、雲特性將會帶來一種新的研發模式。相信隨著雲的快速發展，雲將會帶來更加深切的變化。今天雲的關注點還在於資源、成本、運維、彈性、效率、穩定性等角度，未來雲將會更加深入的影響到應用、商業模式，為社會帶來更大的價值。