過渡架構的作用：一周處理近百起高嚴重性事件，如何重寫這個技術負債系統？

2015 年在 AWS，我接手了一款技術債累累的產品。在一個美好的一周里，我們共處理了 70~100 起高嚴重性事件。這個系統不具備基本的協議，如 API 速率限制、工作優先級、或者像隔離噪音鄰居這樣的防御功能，但是它很容易在一秒內處理上百萬個請求。換言之，在它后面有一個巨大的集群，但是這很有用。在對這個系統進行首次評估的時候，我們真的不知道從何入手。擺在我們面前的挑戰似乎不可逾越。我們知道重寫系統是必要的，但是我們必須獲得重寫系統的權利。AWS 的一個核心工程原則是：

　　……工程師們感謝我們的前輩。我們贊賞工作系統的價值，以及其中所體現的體驗。我們知道，很多問題本質上都不新鮮。

　　簡而言之，它意味著尊重先前的事物。那時，我想我們并沒有真正意識到，隨著我們職業生涯的發展，這個原則將如何影響我們作為工程師和領導者的思維方式。

　　重 寫

　　在那個時候，重寫系統的想法很有誘惑力�，F在回想起來，我真的很高興我們沒有這么做。而在我后來的職業生涯中，我了解到這種誘惑有一個名字：

　　第二系統效應（又稱第二系統癥候群）是指由于期望值過高和過度自信，小型、優雅而成功的系統往往會被過度設計的、臃腫的系統所取代。

　　雖然這個系統在當時處于一個不太理想的狀態，但是它并不需要重寫；它只是需要一點愛❤。

　　過渡架構

　　過渡架構實際上是迭代開發的一種漂亮說法。這意味著，要小步前進�；氐竭@個系統：我們決定采取迭代的方法來修復我們所繼承的“爛攤子”；將我們重寫它的愿望擱置一邊。我們有一座大山要攀登，但我們必須邁出第一步。首先，我們審視了所有的問題，然后創建一個圖來排列這些問題。排列圖看上去像這樣……

　　
這張圖給了我們一種有趣的視角（圖中數字系虛構）。一旦我們看到了上圖中的根本原因，我們就知道系統存在兩個大問題。我們需要在系統中加入速率限制，然后想辦法擴展服務 X，這樣它就不會在負載下崩潰。我們把小團隊分成幾個小組，集中力量解決這兩個具體問題。我們承認這個系統的其他部分也是一團糟的，但是我們選擇接受它們，因為我們知道這些問題為我們的客戶解決了問題，但是卻給我們帶來了操作上的麻煩。幾次沖刺過去了（感覺似乎是永恒的），我們最終實施了速率限制的第一次迭代。太棒了……是嗎？錯了！