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

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

"實(shí)體不應(yīng)無故增多"——威廉·奧卡姆，奧卡姆剃刀

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

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

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

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

從靈活到致命

目標(biāo)不是消除復(fù)雜性，而是有效地管理它。

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

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

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

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

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

在這里，Vogels 以自行車設(shè)計(jì)為例。

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

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

最好的設(shè)計(jì)實(shí)際上是兩輪自行車，它兼具易用性和靈活性。

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

將復(fù)雜性放在需要的地方。

Amazon S3（簡單存儲(chǔ)服務(wù)）就是一個(gè)例子，它只提供最終一致性，而不是強(qiáng)一致性。這意味著如果客戶購買了 Amazon S3 存儲(chǔ)桶，它最終會(huì)可用，但可能不會(huì)立即可用。

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

AWS 最終重新設(shè)計(jì)了 S3 以實(shí)現(xiàn)強(qiáng)一致性，"將復(fù)雜性轉(zhuǎn)移到需要的地方"，即遠(yuǎn)離客戶。

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

Vogels 提供了六個(gè)技巧：

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

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

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

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

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

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

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

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

你需要制定一個(gè)策略來應(yīng)對(duì)復(fù)雜性，這種復(fù)雜性會(huì)隨著時(shí)間的推移在你的系統(tǒng)中增長。

Vogels 說，可進(jìn)化性是管理復(fù)雜性的前提條件。

2. 打破復(fù)雜性

復(fù)雜性可能會(huì)潛入你的應(yīng)用程序，就像諺語中青蛙湯里的熱量一樣。

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

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

服務(wù)應(yīng)該有多大？它應(yīng)該能夠容納在一個(gè)工程師的腦子里。

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

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

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

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

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

“然后你們就可以進(jìn)行對(duì)話了，”他說。

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

4. 將工作組織成單元

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

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

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

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

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

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

5. 設(shè)計(jì)可預(yù)測的系統(tǒng)

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

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

令人驚訝的是，AWS 沒有使用事件驅(qū)動(dòng)架構(gòu)來設(shè)置此服務(wù)，這與普遍的看法相反，對(duì)于此任務(wù)來說是一種糟糕的方法，因?yàn)閬碜杂脩舻呢?fù)載請(qǐng)求速率將是不可預(yù)測的。

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

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

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

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

6. 自動(dòng)化所有事務(wù)

要管理復(fù)雜性，就自動(dòng)化復(fù)雜性。

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

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

“自動(dòng)化應(yīng)該是標(biāo)準(zhǔn)，例外情況是我們需要人工參與，”Vogels 說?！笆謩?dòng)輸入只應(yīng)在真正需要人工判斷的領(lǐng)域中需要?！?/p>

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

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

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

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