在AWS re:Invent大會上，CTO Werner Vogels分享了亞馬遜在系統(tǒng)設計方面的一些基本經(jīng)驗教訓。

譯自Werner Vogels' 6 Lessons for Keeping Systems Simple，作者 Joab Jackson。

"實體不應無故增多"——威廉·奧卡姆，奧卡姆剃刀

且不說亞馬遜網(wǎng)絡服務 (Amazon Web Services)，這家云巨頭已經(jīng)能夠在其系統(tǒng)和服務上擴展超過二十年，不斷推出新功能，同時保持用戶體驗易于管理。

在其慣例周四主題演講中，AWS 首席技術(shù)官Werner Vogels分享了他二十年來在云巨頭工作的經(jīng)驗中，關(guān)于保持簡單的一些經(jīng)驗教訓。

復雜性總是潛入系統(tǒng)設計中，因此工程師必須勤勉地管理這種復雜性。

目標始終是“以安全的方式擴展我們的系統(tǒng)，使其隨著時間的推移變得更加復雜”，他說道。

從靈活到致命

目標不是消除復雜性，而是有效地管理它。

增強任何系統(tǒng)時的危險在于它帶來了不必要的復雜性，這難以維護，并剝奪了用戶的樂趣。

但正如 Larry Tesler所指出的，復雜性無法消除，只能轉(zhuǎn)移。

現(xiàn)在，存在良好的復雜性，這是為了幫助系統(tǒng)發(fā)展而添加的；然后是那種在沒有架構(gòu)監(jiān)督的情況下發(fā)生的復雜性，它只會減慢用戶速度，并使系統(tǒng)更難以維護，他解釋道。

復雜性不僅取決于系統(tǒng)中組件的數(shù)量，還取決于這些組件的排列方式。

"你無法將給定任務的復雜性降低到某個點以下。一旦達到這一點，你只能轉(zhuǎn)移負擔。"——Larry Tesler

在這里，Vogels 以自行車設計為例。

實際上，自行車最簡單的形式是獨輪車，它只有一個輪子。獨輪車非常靈活（"它們可以原地轉(zhuǎn)彎"），但很難騎。

另一方面是三輪車，它們很容易騎，但笨重且難以操縱，任何騎過三輪車的人都知道。

最好的設計實際上是兩輪自行車，它兼具易用性和靈活性。

"自行車有更多組件，但從整體角度來看，它是最簡單的形式，"他說道。自行車成為最流行的自行車形式并非偶然。

將復雜性放在需要的地方。

Amazon S3（簡單存儲服務）就是一個例子，它只提供最終一致性，而不是強一致性。這意味著如果客戶購買了 Amazon S3 存儲桶，它最終會可用，但可能不會立即可用。

然而，客戶希望獲得強一致性，并已開始構(gòu)建變通方案，以確保在其自身設計中基于 S3 實現(xiàn)強一致性，這導致了他們自身系統(tǒng)中不必要的復雜性。

AWS 最終重新設計了 S3 以實現(xiàn)強一致性，"將復雜性轉(zhuǎn)移到需要的地方"，即遠離客戶。

那么，系統(tǒng)工程師如何管理他們自己系統(tǒng)中的復雜性呢？

Vogels 提供了六個技巧：

1. 構(gòu)建能夠發(fā)展的系統(tǒng)

不向前發(fā)展的軟件系統(tǒng)會消亡。即使是最穩(wěn)定的軟件也會看到世界在沒有它的情況下前進。

此外，誰不想看到自己喜歡的應用程序擁有新功能或運行速度更快？

你的系統(tǒng)會隨著時間的推移而發(fā)展，你需要修改你的架構(gòu)，Vogels 建議道。

"每當你改變數(shù)量級時，你都需要重新審視你的架構(gòu)，"Vogels 說。當 S3 推出時，設計工程師知道他們將改變架構(gòu)。隨著時間的推移，盡管其 API 的占用空間很小，但它積累了驚人的功能范圍。

"你會看到，每年我們都會添加新功能，而不會對我們?yōu)榭蛻籼峁┑墓δ墚a(chǎn)生任何影響，"他說。

網(wǎng)絡服務也是如此，在用戶的請求下，網(wǎng)絡服務得到了顯著的發(fā)展。

"我們知道，無論我們在 2006 年為您提供的網(wǎng)絡功能是什么，到 2010 年肯定會在 2020 年發(fā)生根本性的變化，"Vogels 說。

你需要制定一個策略來應對復雜性，這種復雜性會隨著時間的推移在你的系統(tǒng)中增長。

Vogels 說，可進化性是管理復雜性的前提條件。

2. 打破復雜性

復雜性可能會潛入你的應用程序，就像諺語中青蛙湯里的熱量一樣。

"小的變化起初似乎很容易管理、很容易吸收，但如果你忽略了警告信號，系統(tǒng)就會變得越來越復雜，越來越難以管理和理解，"他說。 答案是將系統(tǒng)分解成多個更易于管理的組件。

Amazon CloudWatch最初是一個簡單的監(jiān)控服務。隨著更多功能的添加，每個功能都加載到登錄頁面上，直到頁面變得非常繁忙，AWS 才重新設計了它，使其只保留核心功能。其他功能被遷移到它們自己的環(huán)境中。

服務應該有多大？它應該能夠容納在一個工程師的腦子里。

“如果你無法記住它，你的服務通常就太大了，”Vogels 說。

3. 將架構(gòu)與業(yè)務需求對齊

Vogels 說，通過完善的 API 構(gòu)建具有“智能端點”和“細粒度接口”的業(yè)務重點組件。將它們分散，以便它們“獨立發(fā)展”。

企業(yè)技術(shù)并非為了自身而構(gòu)建。它是為客戶而構(gòu)建的。因此，系統(tǒng)架構(gòu)師需要與他們服務的業(yè)務部門緊密合作。

協(xié)作至關(guān)重要。業(yè)務部門可能會說它需要 100% 的正常運行時間。這是可行的，但代價高昂。因此，系統(tǒng)設計師可能需要指出 100% 的可靠性將有多昂貴。

“然后你們就可以進行對話了，”他說。

Vogels 曾說過，一切都會一直失敗。所以訣竅是計劃失敗。

4. 將工作組織成單元

隨著應用程序的流行和功能的增加，它在操作方式上也會產(chǎn)生復雜性?？紤]使用基于單元的架構(gòu)來保持這種日益增長的復雜性的簡單性。

“構(gòu)建系統(tǒng)的時間通常比運行系統(tǒng)的時間要少得多。因此，提前投資可管理性至關(guān)重要，”Vogels 說。

管理這些操作也必須分解成更小的構(gòu)建塊。這是為了減少影響范圍，這對于最大限度地減少停機時間至關(guān)重要。

“單元在復雜系統(tǒng)中創(chuàng)造秩序，”他說?！八鼈儗栴}隔離到特定單元，而不會影響其他單元。”

需要一個路由器和控制平面將請求路由到各個單元。路由標簽可以基于區(qū)域 ID、主機 ID、客戶 ID。

“隨著時間的推移，分解成單元將有助于您維護客戶的可靠性和安全性，”他說。

5. 設計可預測的系統(tǒng)

不確定性難以處理。因此，提前設計您的系統(tǒng)以減少不確定性。

AWS 為其面向客戶的負載均衡器運行一個超平面，以處理數(shù)百萬客戶用來更改配置的所有更改。

令人驚訝的是，AWS 沒有使用事件驅(qū)動架構(gòu)來設置此服務，這與普遍的看法相反，對于此任務來說是一種糟糕的方法，因為來自用戶的負載請求速率將是不可預測的。

相反，AWS 將更改寫入 S3 文件，負載均衡器以定期輪詢間隔提取這些文件。

“簡單需要紀律”——AWS 首席技術(shù)官 Werner Vogels

“這是一種我們稱之為持續(xù)工作的模式，”Vogels 說。這種方法避免了峰值、積壓和瓶頸，并且還使系統(tǒng)能夠自我修復，因為“S3 是不可滲透的?！?/p>

AWS 的Route 53域名服務在其運行狀況檢查器上采用相同的原理：輪詢而不是排隊。

6. 自動化所有事務

要管理復雜性，就自動化復雜性。

AWS 使用自動化來完成許多任務，甚至包括構(gòu)建新的區(qū)域，這是完全自動化的。

問題不在于自動化什么，而在于什么不自動化。只有那些真正需要人工參與的決策才應該有人工干預。其他一切事情都應該自動化。

“自動化應該是標準，例外情況是我們需要人工參與，”Vogels 說?！笆謩虞斎胫粦谡嬲枰斯づ袛嗟念I域中需要?！?/p>

安全是 AWS 的一個高度自動化的流程，其中包括自動化威脅情報等流程。AWS 每天收到“數(shù)萬億”個 DNS 更改請求，每天至少識別 100,000 個惡意域名，這通過一個自動化流程完成——這是一個手工無法完成的流程。

支持票證是另一個適合自動化的領域通過代理。代理最適合非常狹窄的用例，在這些用例中，它們被賦予了一系列工具，可以通過稱為“無服務器提示鏈”的流程來解決問題。

如果代理無法解決問題，只需將其提請人工注意。

“自動化所有不需要高度判斷力的事情，”Vogels 說。