引子
“天下武功，無堅不摧，唯快不破”，相信大家對星爺電影《功夫》中的這句話耳熟能詳。實際上，“天下武功，唯快不破”最早出自古龍先生的著名武俠小說《小李飛刀》：“小李飛刀，例無虛發，只出一刀，無人能擋，只因天下武功無堅不摧，唯快不破。”
其意思是說，天下的眾多武功裡，只有“快”找不到剋制它的方法。當武功的速度達到極致的時候，有時候不需要複雜招式，只是簡單的一招就可以克敵。
2022年11月28日，一年一度的亞馬遜雲科技 re:Invent 2022 大會在美國內華達州拉斯維加斯拉開帷幕。據悉，本次大會吸引了約50000人現場參加，而線上參加的人數超過300000 人。這場為期五天的雲端計算盛會又給大家帶來了很多新的驚喜。
在筆者看來，本次峰會有三大焦點主題，分別是 資料、效能和安全。Amazon CEO Adam Selipsky 的 Keynote 至少一半時間都在談資料，包括資料的產生、資料的處理、資料的分析、資料的保護、資料的應用等。還有 VP Swami Sivasubramanian 的 Keynote，幾乎整個都在談資料。而VP Peter DeSantis 的 Keynote 則大部分時間在談效能，包括更快的網路訪問速度、更高的磁碟訪問速度、更快的晶片運轉速度、更快的函式啟動速度等等。實際上縱觀峰會，還有快速的產品釋出速度、更快的資料流動速度、更快的創新速度等。
所有這些“快”，就像火箭高速發動機，將亞馬遜雲科技推向了一個全新高度。如同“天下武功，唯快不破”中的“快”，“速度”也已成為亞馬遜雲科技手中的一把最快的刀，披荊斬棘，勢不可擋，奔向遠方。下文，將選取本次峰會上眾多釋出之中筆者認為非常具有代表性的五個底層效能創新，來一一為您講述亞馬遜雲科技是如何將“快”做到極致的。
1. Lambda函式冷啟動時間降低90%
2015年，亞馬遜雲科技正式釋出 Amazon Lambda，開創了無伺服器計算時代。過去8年間，Lambda的功能一直在豐富和完善中。
Lambda 具有獨到的優勢。在開發方面，它採用簡單的程式設計模型，可方便地呼叫其它亞馬遜雲科技服務；在運維方面，Lambda 函式能快速響應不斷變化的使用模式。因此，越來越多的使用者喜歡它、使用它。在本次峰會上，亞馬遜雲科技宣佈，每個月有100萬客戶使用 Lambda，每個月 Lambda 函式的呼叫量超過100億次。
但是，過去，Lambda 函式冷啟動時間過長的問題一直在困擾著使用者們。要理解這個問題的根因，需首先簡單瞭解下其實現原理。
Lambda 函式執行在微虛機 (MicroVM) 中。關於 Firecracker，多年前筆者曾經寫過一篇介紹性文章，容器在公有云上的落地姿勢，您可以參考，請注意文中有些資訊可能已經有些過時了。
亞馬遜雲科技劃分了一個池子，專門用於執行 Lambda 函式的微虛機。當使用者部署函式時，函式程式碼要麼被上傳到 S3 中，要麼將函式映象上傳到 Amazon Elastic Container Registry（ECR）中。
當函式第一次被呼叫時，Lambda 從 S3 或 ECR 中拉取程式碼，然後拉起一個 Firecracker 微虛機，並進行執行時和函式程式碼初始化。接著，程式碼被執行，並返回函式的輸出。
接下來，Lambda 將使這個微虛機保持執行一段時間，因此後續請求都將由這個正在執行的容器來處理和執行。一段時間內沒有函式呼叫的話，亞馬遜雲科技將關閉此容器。當一個新事件出現時，Lambda 會啟動一個新微虛機—這過程包括亞馬遜雲科技為啟動“微虛機”所做的一切，以及初始化你的程式碼。
這就是亞馬遜雲科技啟停其 Lambda 函式的基本方式。這種方法可提高亞馬遜雲科技的基礎設施的效率，大大降低客戶的執行成本。
每個 Lambda 函式的生命週期包括三個過程：初始化（init）、呼叫（invoke）和關閉（shutdown）。所謂初始化過程，指的是第一次呼叫函式時所需要的執行和響應時間，包括下載程式碼、拉起微虛機、執行時初始化和函式初始化等環節所花的時間。後續呼叫過程則會比第一次初始化快得多，因為只包括函式執行環節。我們將函式的初始化過程稱為“冷啟動”。任何後續請求都將由正在執行的容器中已經包裝好的函式處理，每次函式呼叫只需要一次所謂的“熱啟動”。
根據對生產 Lambda 工作負載的分析，冷啟動通常發生在不到1%的呼叫中。冷啟動的持續時間從不到100 毫秒到超過1秒不等。其中，Java 語言編寫的 Lambda 函式的冷啟動時間最長，主要因為三個因素：一是 JVM 的啟動時間，二是 Java 類的解壓時間，三是 Java 類的初始化程式碼的執行時間。
Lambda 函式冷啟動時間過長會帶來一系列問題，這也讓 Lambda 函式啟動效能最佳化成為近幾年最熱門的最佳化領域之一。特別是其最長的1秒時間，決定了 Lambda 函式可能很難用於對延時非常敏感的聯機交易，這會大大壓縮了 Lambda 的使用場景。為了克服這個問題，使用者們甚至發明了非常規手段，比如每隔15分鐘 ping 一次自己的函式，以確保它是活著的。
幸運的是，本次峰會上，亞馬遜雲科技宣佈了 Lambda SnapStart 新特性。為 Java 函式啟用 Lambda SnapStart，可以使其冷啟動速度提高10倍。這是一次數量級級別的效能提升。
我們來看看該特性的實現原理。它利用了 Firecracker 的 MicroVM Snapshot 功能。在函式冷啟動或函式更新階段或新版本建立時，函式會被啟動執行並完成初始化，Lambda 然後會為函式的記憶體和磁碟狀態建立一個快照（Snapshot）並快取下來。在冷啟動過程中，透過恢復（Resume）快照，就可以讓函式很快就緒。
只要快照存在，當函式被呼叫時，只需要恢復快照就可以了。而恢復快照比建立和初始化新的 Lambda 執行環境要快10倍，這就是為什麼該特性雖小但效果這麼明顯的原因。
此最佳化使 Lambda 函式的呼叫時間更快且更可預測。實際上，該技術的背後還有三個創新點。一是採用一致性的快照技術，二是提升了快照處理的效率，三是預測性快照載入。這三大創新合併在一起，才帶來數量級的效能提升。
本次峰會上，亞馬遜雲科技推出了對使用 Amazon 自己的 JDK 發行版 Corretto (java11) 執行時的 Lambda Java 函式的支援，其他 Java 框架的支援應該很快就會推出。
實際上，我們回頭看的話，這功能實在太重要了，其實應該更早些推出才對，甚至在2014年宣佈的時候就應該具備。
這個看起來小小的特性，也許能為 Lambda 巨大的改變，因為使用者們太需要它了。他們在歡呼：“This is a great and long awaited change!”“Honestly, this is how Lambda should be, by default.”“其它 Java 版本、python 和 node.js 什麼時候開始支援呢？”
亞馬遜雲科技的合作伙伴 Micronaut 迫不及待地使用“Hello World”Java 程式做了對比測試。很顯然，程式的啟動速度得到了大幅提升。
在該功能所聲稱的效能提升得到充分的證實並在持續最佳化後，筆者甚至相信它將改變 Lambda 的擴充套件性在無伺服器領域和整個行業中的認知，並將使得 Lambda 函式作為聯機函式變成可能。甚至 Serverless 時代的真正到來會因此而大大加快！
2. 資料庫TPS效能提升30%
現在亞馬遜雲科技談效能，已經無法不談 Nitro 了。Peter DeSantis 在其 Keynote 中一上來就說，自2014年以來推出的每一個的 Amazon EC2 例項都在利用 Amazon Nitro 這項技術，它對亞馬遜雲科技產品和服務效能的提升居功至偉。
本次峰會上釋出的最新版本 Amazon Nitro v5，相比前一代 v4，它具有兩倍的計算能力、多出50%的記憶體頻寬和兩倍頻寬的外圍元件互連高速 (PCIe) 介面卡，支援每秒60%的資料包 (PPS) 速率增加，資料包延遲減少30%，每瓦效能提高40%。
在2021年 re:Invent 峰會上，亞馬遜雲科技釋出了 Nitro SSD。
這款亞馬遜雲科技自研的 SSD，具有更低延遲、更加可靠、資料自動加密等特點，它不僅幫助亞馬遜雲科技實現了對 SSD SLA 的控制而且還大大降低了成本了。
Nitro SSD 還有更多的價值。在2022年的 re:Invent 峰會上，亞馬遜雲科技宣佈基於Nitro SSD，亞馬遜雲科技實現了 TWP（Torn Write Prevention，撕裂寫預防）功能，使得資料庫的 TPS 效能提升了至少30%。
資料庫是網站、APP 等產品重要的底層核心支撐服務，其效能的重要性不言而喻。而 TPS（Transactions per Second，每秒事務數）是資料庫最核心的效能指標之一，TWP 使得 IO 密集型的應用能從 MySQL 或 MariaDB 上獲得更高的效能和更低的時延。
簡單介紹下 TWP 產生的背景。通常資料庫場景下，資料寫入頁大小（page size）是16KiB，而目前檔案系統中常用的頁大小都是4KiB。因此，資料庫要將一個16KiB的資料寫入磁碟，那在作業系統級別上需要寫4個4KiB大小的資料塊。在極端情況下（比如系統斷電或作業系統當機）可能無法保證這一操作的原子性，比如可能在寫入4KiB 時發生了斷電，此時只有一部分寫是成功的，這樣就產生了資料一致性問題。
為了解決這個問題，資料庫實現上通常都會採用“雙寫緩衝區（Double Write Buffer，以下簡稱 DWB）”的機制。如下圖所示，當 MySQL 要寫入16KiB資料的時候，資料首先被寫入 DWB 緩衝區，然後分4次寫入表空間。
顯然，這種設計雖然保證了16KiB資料的寫入可靠性和原子性，但是卻帶來了直接的效能損失和間接的成本增加。
得益於 Nitro SSD 對16KiB原子寫的支援，TWP 技術使得亞馬遜雲科技資料庫服務不再需要DWB快取衝了，而只需要將檔案系統的頁大小直接修改為16KiB即可，資料庫應用就可以原子性地一次性寫入16KiB的資料。TWP 可以確保資料庫應用的16KiB資料在寫入事務期間發生作業系統崩潰或斷電時不會被撕毀。
使用 TWP 技術，在 EC2、EBS 和託管服務（如 Amazon RDS）上執行 MySQL 或 MariaDB 等關聯式資料庫的客戶可以關閉雙寫操作，從而在不影響工作負載彈性的情況下將資料庫效能每秒事務數 (TPS) 加快多達30%。
下圖是在 Amazon r6i.16xlarge EC2 例項上執行 MySQL 8.0 並使用簡單 OLTP 負載的對比測試結果。在關閉 DWB 的情況下，其 TPS 在512個併發執行緒數時提升了2倍，而且隨著執行緒數越多，提升效果越大。
資料庫服務是雲上最基礎的服務之一。TWP 這特性看起來也許不大起眼，但是卻能帶來如此高的效能提升，這讓我們又一次見證了硬體創新的威力。
3. ENA網路卡效能躍升5倍
在看具體內容之前，我們來看看過去16年中 Amazon EC2 例項的網路頻寬的提升曲線。這圖非常直觀、非常漂亮、非常震撼人心。re:Invent 材料的視覺效果越來越好了。
亞馬遜雲科技網路支援三種網路卡，分別是 ENI、ENA 和 EFA。
- ENI：Elastic Network Interface，彈性網路介面。ENI 是一種邏輯網路裝置，代表虛擬網路卡，依賴 Hypervisor 透過網路虛擬化功能實現。
- ENA：Elastic Network Adaptor，彈性網路介面卡，是一種透過 SR-IOV（Single Root I/O Virtualizatio，單根 I/O 虛擬化）虛擬化技術實現的硬體網路裝置。這是一種經過最佳化了的網路介面，能提供更高吞吐量和更好的每秒資料包 (PPS) 效能。
- EFA：Elastic Fabric Adapter，使用定製的作業系統旁路技術來增強例項間通訊的效能。一開始 EFA 用在高效能運算場景中，使得客戶能夠在亞馬遜雲科技上大規模執行需要高階別例項間通訊的 HPC 應用程式，例如計算流體動力學、天氣建模和油藏模擬。
三種網路卡的特性對比：
需要注意的是，EFA 因為採用了 SRD 協議，其最大單流頻寬被提高到100Gbps。但 EFA 和 ENA 有些不一樣，它沒有采用標準 TCP/IP 協議棧，只能面向高效能運算場景。因此，很多使用者早就在期盼著，若能將 SRD 用在 ENA 上，則能惠及更多使用者的更多場景。
2022年的 re:Invent 峰會上，亞馬遜雲科技首次將 SRD 應用到 ENA 上，新推出了 ENA Express。它具有三個特點：
- 簡單：在網路卡上透過簡單配置或一次 API 呼叫來啟用 SRD 即可；
- 透明：應用還是使用 TCP/UDP 協議，ENA Express 自動檢測通訊雙方 EC2 例項之間的相容性，並在兩通訊例項均啟用 ENA Express 後建立 SRD 連線；
- 高效：能大幅提高 EC2 例項之間的單流頻寬和降低網路流量尾部延遲。
SRD 將使用 ENA 的 EC2 例項的最大單流頻寬從5 Gbps增加到25 Gbps，足足提升了5倍。而且，它最多可將P99的延遲降低50%、將 P99.9 延遲降低85%。
那到底 SRD 有什麼魔力能如此大幅提高網路傳輸效能呢？我們來看看 SRD 是什麼、從何而來，又要到哪裡去。
2020年，亞馬遜雲科技發表了一篇論文《A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC》，對 SRD 進行了詳細闡述（論文地址：https://assets.amazon.science...）
在論文摘要中作者寫道：
“亞馬遜雲科技重新審視了現有網路協議，以提供超級計算應用程式（supercomputing application）所需的持續低延遲，同時保持公共雲的優勢：可擴充套件性、按需獲取彈性容量、價效比以及快速採用更新的 CPU 和 GPU。
我們創造了一種新網路傳輸協議 - 可擴充套件的可靠資料包 (SRD)，旨在充分利用現代商業多租戶資料中心網路的優勢（具有大量網路路徑），同時克服它們的侷限性（負載不平衡和不相關流衝突時導致的延遲抖動）。
SRD 不保留資料包順序，而是透過儘可能多的網路路徑傳送資料包，同時避免過載路徑。為了最大限度地減少抖動並確保對網路擁塞波動做出最快的響應，SRD 在亞馬遜雲科技定製的Nitro 網路卡中實現。
SRD 由 EC2 主機上的 HPC/ML 框架透過亞馬遜雲科技彈性結構介面卡（EFA）核心旁路介面（kernel-bypass interface）使用。”
關於SRD的詳情，可閱讀該論文，本文不再贅述。簡單總結，SRD 是一種基於乙太網的傳輸協議，設計初衷是面向超算場景，要結合 EFA 才能使用。其主要特點包括：
- 亂序交付：SRD 放寬了對按順序傳遞資料包的要求，亞馬遜雲科技在 EFA 使用者空間軟體堆疊中實現了資料包重排序處理引擎。
- 等價多路徑路由（ECMP）:兩個 EFA 例項之間可能有數百條路徑，使用大型多路徑網路的一致性流雜湊的屬性，以及 SRD 對網路狀況的快速反應能力，找到訊息的最有效路徑。
- 快速的丟包響應：SRD 對丟包的響應比任何高層級的協議都快得多。偶爾的資料包丟失是正常網路操作的一部分，這不是異常情況。
我們來透過 TCP 和 SRD 兩種協議的對比來看看其優勢。TCP 的傳統路由方式示意圖：
丟包很大機率會引起 TCP 傳輸頻寬的大幅下滑。
而 SRD 採用全路徑傳輸方式：
這種情況下，丟包對頻寬的影響非常小，除了短時間的小抖動，幾乎沒有影響。
“舊時王謝堂前燕，飛入尋常百姓家”。過去只能用於 HPC 叢集中的 SRD 協議，如今應用到最為通用的 ENA 網路卡中。就是它，讓 ENA 網路卡效能一下子躍升了5倍！
這種效能提升帶來的好處是實實在在的。以亞馬遜雲科技記憶體資料庫服務 Amazon ElastiCache 為例，與普通ENA網路相比，ENA Express 能夠降低44%的尾部延遲，TCP 最大單流頻寬將增加4倍，從5Gbps增加到25Gbps。
4. EBS卷最大IOPS提升4倍
IOPS，每秒輸入/輸出操作（Input/Output Operations per Second）的縮寫，是一個常用來表徵儲存裝置效能的數字，數字越大表示儲存的效能越好。
當亞馬遜雲科技在2006年推出 Amazon Elastic Compute Cloud (Amazon EC2) 時（Amazon EC2 Beta），m1.small 例項的本地磁碟儲存容量只有微不足道的160 GiB。此儲存與例項具有相同的生命週期，並且在例項崩潰或終止時消失。在EC2測試版和2008年推出 Amazon EBS 之間的兩年時間裡，這些早期卷能夠提供平均約100 IOPS。
隨著亞馬遜雲科技的早期客戶獲得了 EC2 和 EBS 的使用經驗，他們要求提供更高的 I/O 效能和靈活性。在2012 釋出當時新的預配置 IOPS (PIOPS) 卷時，其 IOPS 達到了1000。多年來，隨著客戶群變得越來越多樣化，亞馬遜雲科技為EBS新增了新的功能和卷型別，同時也在提高效能、耐用性和可用性。
2014年，亞馬遜雲科技推出 Amazon Elastic Block Store 通用型 (SSD) 卷型別，無論卷大小如何，它都能使每個卷的每秒 I/O 操作 (IOPS) 激增至3,000次。
2020年，亞馬遜雲科技與 SAP 合作為 SAP 認證了 Amazon EBS io2 卷。與 Amazon EBS io1 卷型別相比，io2卷的卷耐用性提高了100倍，IOPS 與儲存的比率提高了10倍。
下圖是 EBS 家譜，從2008年的100 IOPS 起點開始，到2012年單個 PIOPS 卷可以提供1000 IOPS，再到今天高階 io2 Block Express 卷可以提供高達 256,000 IOPS。
從曲線視角來看 EBS I/O 效能的持續14年的大幅提升歷程：
從表的視角來仔細看：
在上面 EBS 卷家譜中，引起筆者最大興趣的是2021年釋出的Io2 Block Express型別，其最高IOPS和吞吐量比io2全都增加了3倍。這是一次多麼大的效能躍升啊！
在2020年re:Invent峰會上，亞馬遜雲科技宣佈了io2 Block Express 提供預覽版本，它被設計用於對IOPS和延遲有最高要求的最為關鍵的應用，比如Microsoft SQL Server, Oracle, SAP HANA等。
io2 Block Express 卷使用了多種Nitro系統元件，包括Amazon Nitro SSD儲存和用於EBS的Nitro卡。最大容量可達 64 TiB，並且提供高達 256,000 IOPS 和 99.999% 的耐用性和高達 4,000 MiB/s 的吞吐量。
2021年7月，io2 Block Express 卷正式釋出。
2022年，亞馬遜雲科技宣佈將SRD應用於io2 EBS卷，這就是本章的主角io2 Block Express 卷。過去的一年中，亞馬遜雲科技繼續將SRD協議的覆蓋面延伸到EBS上。甚至可以認為，io2 Block Express = io2 + SRD。
Io2 Block Express 卷效能大幅提升，兩種創新技術功不可沒：一是在網路方面應用了可擴充套件可靠資料包 (SRD) 協議；二是在儲存方面應用了亞馬遜雲科技自研的 Nitro SSD。因為這兩種創新前文都提到過，這裡就不再贅述了。
SRD協議有效改善了 Amazon EBS 塊儲存效能，減少90%的尾部延遲，並將吞吐量提升4倍。
Io2 Block Express 卷使得客戶們可以拋棄本地資料中心昂貴的 SAN 儲存了。
亞馬遜雲科技宣佈從2023年初開始，所有新的 Amazon EBS io2 卷都將在 SRD 上執行。我們拭目以待！
5. Graviton全速衝刺雲端計算制高點
2022年 re:Invent 峰會上，亞馬遜雲科技釋出了 Graviton3E 晶片。
這是一款專用於高效能運算伺服器的 Graviton晶片，在HPC領域內常用的浮點計算和向量計算上了針對性最佳化。與 Graviton3 相比，HPC 效能提升了30%。
在筆者看來，亞馬遜雲科技的 Graviton 晶片具有幾個“快”特點。
一是釋出速度快。2018年釋出 Graviton1，2019年釋出 Graviton2，2021年 Graviton3。這速度剛剛的！
二是效能提升快。從伺服器視角來看，基於 Gravtion 的伺服器的架構有很多直接改進：每臺伺服器3顆 Gravtion 晶片，晶片密度雖然提升了50%，但伺服器耗電量卻和兩路晶片伺服器相當；而且全部晶片由 Nitro 統一管理，提升了安全性的同時，還節省了管理成本。
從晶片本身的效能來看，很難對三款晶片的效能直接進行對比。不妨換個視角，從採用了三種晶片的同樣規格的 EC2 例項的效能和價效比上進行對比：
圖上可以清楚地看出，每一代 Graviton 的每單位容量成本的橙色條越來越短，而效能的黑色條越來越長。我們沒有理由不相信這種趨勢會在 Graviton4 上繼續下去。
三是，亞馬遜雲科技自己的服務向 Graviton 遷移的速度快。
除了計算、資料庫、大資料分析服務外，亞馬遜雲科技也把 SageMaker 服務也執行在 Graviton 上了。
四是使用者的認可速度快。
Databricks CEO Ghodsi 提到：“越來越多的客戶將 Gravtion 晶片帶來的價效比提升視為免費的午餐。”
Gravtion 例項在一些客戶中變得如此受歡迎，以至於在某些地方，這種伺服器有時候甚至會售罄。初創公司 Honeycomb 使用它從英特爾驅動的伺服器切換到 Graviton 伺服器所節省的資金來開發其它功能，而無需提高其價格。該公司的主要開發人員 Liz Fong-Jones 說：“我們使用我們可以得到的所有 Graviton 2和 Graviton 3伺服器，但在我們需要的一些可用性區域 Graviton 3 伺服器卻售罄了。”
五是使用者向 Graviton 遷移的速度快。
這裡舉兩個例子。
一個是 Databricks，它的軟體加快了開發機器學習模型的過程。其執行長 Ali Ghodsi 在最近的一次採訪中表示：“自4月以來，當 Databricks 開始推廣其在由第二代 Graviton 晶片提供支援的亞馬遜雲科技雲伺服器上執行的軟體時，其軟體效能提高了20%，成本卻降低了20%至40%。”
另一個是 Snowflake。其產品高階副總裁 Christian Kleinerman 在一份電子郵件宣告中表示，“與其他型別的伺服器相比，在 Graviton 伺服器上使用 Snowflake 的軟體可以提高10%的速度。效能提升意味著 Snowflake 客戶不需要儘可能多地使用其軟體，促使 Snowflake 在3月其收入將減少近1億美元。同時該公司表示，隨著客戶利用較低的伺服器成本並將更多資料放入 Snowflake 資料庫，它希望彌補這一不足。”
Gravtion 高速衝刺“搶佔制高點”邏輯到底是什麼呢？
從一代代產品釋出，到一項項效能提升，到自身服務全面應用，到使用者加速切換，Gravtion的一切動作都是那麼快速。這背後，亞馬遜雲科技的行為邏輯到底是什麼呢？也許，Forrester Research 高階雲分析師 Tracy Woo 的一句話一語道破了天機：“Gravtion 伺服器晶片成為了亞馬遜雲科技對抗追趕者的秘密武器，它是亞馬遜雲科技要把他們和追趕者拉開差距而正在做的最重要的事情之一”。
資料分析初創公司 Starburst Data 的工程副總裁 Ken Pickering 表示，在 Graviton 伺服器上執行的一個優勢是，它們在並行化或同時處理多個不同的計算作業方面優於英特爾和 AMD，這使得使用 Graviton 處理器的雲伺服器，耗電量更少、速度更快。
這種優勢，也和很多客戶反饋中得到了印證。 有客戶透過租用 Graviton 伺服器節省了10%到40%的計算成本。據一位直接瞭解相關資料的人士透露，Twitter、Snap、Adobe 和 SAP 都是 Graviton 伺服器的客戶，Graviton 伺服器在推出僅三年後就成為了一項收入達數十億美元的業務。自從亞馬遜在去年5月份推出更具成本效益的第三代 Graviton 晶片以來，競爭對手感受到了更大的追趕壓力。
一方面，Graviton伺服器的速度和效率為亞馬遜雲科技客戶節省了資金。另一方面，客戶對此伺服器的需求非常強大，亞馬遜從中獲得的收入也在飆升。據直接瞭解資料的人士表示，截至2021年秋，每年Graviton伺服器收入有望超過50億美元。這意味著繼續高速增長的話，到2022年可能佔亞馬遜雲科技彈性計算雲收入的10%以上。這位人士表示，EC2 收入約佔亞馬遜雲科技去年 620 億美元收入的一半。（備註：亞馬遜雲科技尚未披露 EC2 或 Graviton 的收入。）
寫在最後
前文介紹的這些效能提升和最佳化，包括 Lambda 函式、ENA、EBS、TWP 和 Graviton，都發生在亞馬遜雲科技雲基礎設施的最底層。它們也許不像全新發布的那些服務那麼耀眼，但是，它們帶來的效果卻是最直接的、最實在的、最惠及大眾的、最能幫客戶省錢的。因為這些服務，是亞馬遜雲科技數百萬計的使用者們最常使用的。
亞馬遜雲科技的創新注重因地制宜。比如在 SRD 創新上，傳統資料中心通常採用 Spine-leaf 網路架構，如下圖所示。
而亞馬遜雲科技資料中心網路採用改良版本的 CLOS 網路架構。
可以說，SRD 是最適合亞馬遜雲科技網路架構的網路協議。在這種網路拓撲之中，SRD 軟體在網路端點間提供多路徑，減少擁塞並允許網路在硬體故障時自動修復，從而提高其網路的有效吞吐量，同時減少網路延遲。
亞馬遜雲科技採用立體式全棧創新，系統地提升工程效能。基於各種黑科技，採用以晶片為代表的硬體、以 Nitro 為代表的網路、以 SRD 為代表的協議，為效能帶來了成倍乃至數量級上的提升。
亞馬遜雲科技注重一種協議、全面採用。SRD 在全面支援 ENA 和 EFA 的基礎上，增加了對 EBS 的覆蓋支援，真正實現了“一種協議，全面採用”，最大化地發揮出價值。筆者預測，SRD 必將成為亞馬遜雲科技資料中心內主要的基礎網路協議。
亞馬遜雲科技自研晶片之戰，已贏得累累戰果。自研晶片為亞馬遜雲科技帶來了全面的專業性、高效能、創新速度和安全性。以創新速度提升為例，資料顯示，自從 Nitro 在2017年釋出以來，EC2 例項型別從幾十種一下子增長到五百多種。
亞馬遜雲科技在底層創新的同時，還注重儘量不給使用者帶來額外改動成本。過去，SRD 一直專注在 HPC 領域中，對 TCP/IP 的支援一直存疑。這一次非常關鍵的是，使用了 SRD 的 ENA Express 直接支援了 TCP/IP 和 UDP，因此客戶不需要修改任何的程式碼，就能直接利用 SRD 所帶來的種種能力提升。
“快”是亞馬遜雲科技身上一道最亮眼的標籤，讓亞馬遜雲科技在短短十幾年時間內就成為全球公共雲霸主。亞馬遜雲科技越來越像一位大俠，在內力越發深厚的同時，出招還更快、更準。“快”的背後，是亞馬遜雲科技長遠的眼光、準確的決策和堅決的執行力。
讓這種底層創新和核心效能提升來得更多更猛烈一些吧！！
本篇作者
劉世民
雲端計算技術專家，曾就職於華為、IBM、海航等公司，專注於雲端計算。曾在海航集團易航科技擔任雲服務事業群總經理一職，負責 IDC、雲平臺、系統運維、資訊保安以及使用者服務等業務。維護有“世民談雲端計算”技術部落格和微信公眾號。《OpenShift雲原生架構原理與實踐》作者之一、《Ceph Cookbook中文版》《精通OpenStack》、《機器學習即服務:將Python機器學習創意快速轉變為雲端Web應用程式》譯者之一。
