在AWS re:Invent大會上，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ù)雜性，它只會減慢用戶速度，并使系統(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（簡單存儲服務(wù)）就是一個(gè)例子，它只提供最終一致性，而不是強(qiáng)一致性。這意味著如果客戶購買了 Amazon S3 存儲桶，它最終會可用，但可能不會立即可用。
然而，客戶希望獲得強(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)會消亡。即使是最穩(wěn)定的軟件也會看到世界在沒有它的情況下前進(jìn)。
此外，誰不想看到自己喜歡的應(yīng)用程序擁有新功能或運(yùn)行速度更快？
你的系統(tǒng)會隨著時(shí)間的推移而發(fā)展，你需要修改你的架構(gòu)，Vogels 建議道。
"每當(dāng)你改變數(shù)量級時(shí)，你都需要重新審視你的架構(gòu)，"Vogels 說。當(dāng) S3 推出時(shí)，設(shè)計(jì)工程師知道他們將改變架構(gòu)。隨著時(shí)間的推移，盡管其 API 的占用空間很小，但它積累了驚人的功能范圍。
"你會看到，每年我們都會添加新功能，而不會對我們?yōu)榭蛻籼峁┑墓δ墚a(chǎn)生任何影響，"他說。
網(wǎng)絡(luò)服務(wù)也是如此，在用戶的請求下，網(wǎng)絡(luò)服務(wù)得到了顯著的發(fā)展。
"我們知道，無論我們在 2006 年為您提供的網(wǎng)絡(luò)功能是什么，到 2010 年肯定會在 2020 年發(fā)生根本性的變化，"Vogels 說。
你需要制定一個(gè)策略來應(yīng)對復(fù)雜性，這種復(fù)雜性會隨著時(shí)間的推移在你的系統(tǒng)中增長。
Vogels 說，可進(jìn)化性是管理復(fù)雜性的前提條件。
2. 打破復(fù)雜性
復(fù)雜性可能會潛入你的應(yīng)用程序，就像諺語中青蛙湯里的熱量一樣。
"小的變化起初似乎很容易管理、很容易吸收，但如果你忽略了警告信號，系統(tǒng)就會變得越來越復(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ù)需求對齊
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ù)部門可能會說它需要 100% 的正常運(yùn)行時(shí)間。這是可行的，但代價(jià)高昂。因此，系統(tǒng)設(shè)計(jì)師可能需要指出 100% 的可靠性將有多昂貴。
“然后你們就可以進(jìn)行對話了，”他說。
Vogels 曾說過，一切都會一直失敗。所以訣竅是計(jì)劃失敗。
4. 將工作組織成單元
隨著應(yīng)用程序的流行和功能的增加，它在操作方式上也會產(chǎn)生復(fù)雜性?？紤]使用基于單元的架構(gòu)來保持這種日益增長的復(fù)雜性的簡單性。
“構(gòu)建系統(tǒng)的時(shí)間通常比運(yùn)行系統(tǒng)的時(shí)間要少得多。因此，提前投資可管理性至關(guān)重要，”Vogels 說。
管理這些操作也必須分解成更小的構(gòu)建塊。這是為了減少影響范圍，這對于最大限度地減少停機(jī)時(shí)間至關(guān)重要。
“單元在復(fù)雜系統(tǒng)中創(chuàng)造秩序，”他說。“它們將問題隔離到特定單元，而不會影響其他單元。”
需要一個(gè)路由器和控制平面將請求路由到各個(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ū)動架構(gòu)來設(shè)置此服務(wù)，這與普遍的看法相反，對于此任務(wù)來說是一種糟糕的方法，因?yàn)閬碜杂脩舻呢?fù)載請求速率將是不可預(yù)測的。
相反，AWS 將更改寫入 S3 文件，負(fù)載均衡器以定期輪詢間隔提取這些文件。
“簡單需要紀(jì)律”——AWS 首席技術(shù)官 Werner Vogels
“這是一種我們稱之為持續(xù)工作的模式，”Vogels 說。這種方法避免了峰值、積壓和瓶頸，并且還使系統(tǒng)能夠自我修復(fù)，因?yàn)椤癝3 是不可滲透的?！?/span>
AWS 的Route 53域名服務(wù)在其運(yùn)行狀況檢查器上采用相同的原理：輪詢而不是排隊(duì)。
6. 自動化所有事務(wù)
要管理復(fù)雜性，就自動化復(fù)雜性。
AWS 使用自動化來完成許多任務(wù)，甚至包括構(gòu)建新的區(qū)域，這是完全自動化的。
問題不在于自動化什么，而在于什么不自動化。只有那些真正需要人工參與的決策才應(yīng)該有人工干預(yù)。其他一切事情都應(yīng)該自動化。
“自動化應(yīng)該是標(biāo)準(zhǔn)，例外情況是我們需要人工參與，”Vogels 說。“手動輸入只應(yīng)在真正需要人工判斷的領(lǐng)域中需要?！?/span>
安全是 AWS 的一個(gè)高度自動化的流程，其中包括自動化威脅情報(bào)等流程。AWS 每天收到“數(shù)萬億”個(gè) DNS 更改請求，每天至少識別 100,000 個(gè)惡意域名，這通過一個(gè)自動化流程完成——這是一個(gè)手工無法完成的流程。
支持票證是另一個(gè)適合自動化的領(lǐng)域通過代理。代理最適合非常狹窄的用例，在這些用例中，它們被賦予了一系列工具，可以通過稱為“無服務(wù)器提示鏈”的流程來解決問題。
如果代理無法解決問題，只需將其提請人工注意。
“自動化所有不需要高度判斷力的事情，”Vogels 說。
