文章來源: 文章作者: 更新時間:2021-07-03 13:42:36 點擊次數:
2015 年在 AWS,我接手了一款技術債累累的產品。在一個美好的一周里,我們共處理了 70~100 起高嚴重性事件。這個系統不具備基本的協議,如 API 速率限制、工作優先級、或者像隔離噪音鄰居這樣的防御功能,但是它很容易在一秒內處理上百萬個請求。換言之,在它后面有一個巨大的集群,但是這很有用。在對這個系統進行首次評估的時候,我們真的不知道從何入手。擺在我們面前的挑戰似乎不可逾越。我們知道重寫系統是必要的,但是我們必須獲得重寫系統的權利。AWS 的一個核心工程原則是:
……工程師們感謝我們的前輩。我們贊賞工作系統的價值,以及其中所體現的體驗。我們知道,很多問題本質上都不新鮮。
簡而言之,它意味著尊重先前的事物。那時,我想我們并沒有真正意識到,隨著我們職業生涯的發展,這個原則將如何影響我們作為工程師和領導者的思維方式。
重 寫
在那個時候,重寫系統的想法很有誘惑力,F在回想起來,我真的很高興我們沒有這么做。而在我后來的職業生涯中,我了解到這種誘惑有一個名字:
第二系統效應(又稱第二系統癥候群)是指由于期望值過高和過度自信,小型、優雅而成功的系統往往會被過度設計的、臃腫的系統所取代。
雖然這個系統在當時處于一個不太理想的狀態,但是它并不需要重寫;它只是需要一點愛❤。
過渡架構
過渡架構實際上是迭代開發的一種漂亮說法。這意味著,要小步前進;氐竭@個系統:我們決定采取迭代的方法來修復我們所繼承的“爛攤子”;將我們重寫它的愿望擱置一邊。我們有一座大山要攀登,但我們必須邁出第一步。首先,我們審視了所有的問題,然后創建一個圖來排列這些問題。排列圖看上去像這樣……
這張圖給了我們一種有趣的視角(圖中數字系虛構)。一旦我們看到了上圖中的根本原因,我們就知道系統存在兩個大問題。我們需要在系統中加入速率限制,然后想辦法擴展服務 X,這樣它就不會在負載下崩潰。我們把小團隊分成幾個小組,集中力量解決這兩個具體問題。我們承認這個系統的其他部分也是一團糟的,但是我們選擇接受它們,因為我們知道這些問題為我們的客戶解決了問題,但是卻給我們帶來了操作上的麻煩。幾次沖刺過去了(感覺似乎是永恒的),我們最終實施了速率限制的第一次迭代。太棒了……是嗎?錯了!
上一篇:內鄉:博物館里的一堂特殊“黨課”
地址:中國·貴州省貴陽市電話:0851-8888888傳真:0851-8888888郵箱:1193159788@qq.com
版權所有:貴陽中瑞盛大企業管理有限公司技術支持:唯爾官網備案號:貴ICP備11017358號-1