同事們大家好。
今天，我們提供 Tugberk Ugurlu 的一篇文章的翻譯供您參考，他致力於以相對較小的篇幅概述設計現代軟體系統的原則。 以下是作者對自己的總結：
由於截至 2019 年，在一篇 habro 文章中絕對不可能涵蓋架構模式 + 設計模式這樣一個龐大的主題，因此我們不僅推薦 Uruglu 先生本身的文本，還推薦他善意包含在其中的眾多鏈接。 如果您喜歡，我們將發布有關分散式系統設計的更專業化的文字。
快照 來自 Unsplash
如果你從未面臨過從頭開始設計軟體系統這樣的挑戰，那麼當開始這樣的工作時，有時甚至不知道從哪裡開始。 我相信你首先需要劃定界限，這樣你對自己到底要設計什麼有或多或少的自信，然後捲起袖子在這些界限內工作。 作為起點，您可以選擇一種產品或服務（最好是您真正喜歡的產品或服務）並弄清楚如何實施它。 您可能會驚訝於這個產品看起來多麼簡單，而它實際上包含多麼複雜。 不要忘記： ，沒關係。
我認為我能給任何開始設計系統的人最好的建議是：不要做任何假設！ 從一開始，您就需要指定有關該系統的已知事實以及與之相關的期望。 以下是一些可以幫助您開始設計的好問題：
- 我們要解決的問題是什麼？
- 與我們的系統互動的使用者峰值數量是多少？
- 我們將使用什麼模式來寫入和讀取資料？
- 預期的失敗情況是什麼，我們將如何處理它們？
- 對系統一致性和可用性的期望是什麼？
- 您在工作時是否需要考慮與外部驗證和監管相關的任何要求？
- 我們將儲存哪些類型的敏感資料？
這些只是對我和我多年來參與的專業活動的團隊都有用的幾個問題。 如果您知道這些問題的答案（以及與您必須工作的環境相關的任何其他問題），那麼您可以逐漸深入研究問題的技術細節。
設定初始級別
這裡的「基線」是什麼意思？ 事實上，在我們這個時代，軟體產業的大多數問題「可以」用現有的方法和技術來解決。 因此，透過駕馭這種情況，當你面臨其他人必須在你之前解決的問題時，你就能取得一定的領先優勢。 不要忘記，編寫程式是為了解決業務和使用者問題，因此我們力求以最直接、最簡單（從使用者的角度）的方式解決問題。 為什麼記住這一點很重要？ 也許在你的座標系中，你喜歡為所有問題尋找獨特的解決方案，因為你想，「如果我到處遵循模式，我會是什麼樣的程式設計師」？ 實際上， 這裡的藝術是決定在哪裡做什麼。 當然，我們每個人都會不時地處理獨特的問題，每個問題都是真正的挑戰。 然而，如果我們的初始水平已經明確，那麼我們就知道該把精力花在哪裡：尋找現成的選項來解決擺在我們面前的問題，或者進一步研究它並獲得更深入的理解。
我想我能夠讓您相信，如果專家自信地理解某些出色的軟體系統的架構組件是什麼，那麼這些知識對於掌握架構師的藝術並在該領域打下堅實的基礎是不可或缺的。
好吧，那麼要從哪裡開始呢？ U GitHub 上有一個儲存庫，名為 ，從中您可以學習如何設計大型系統，並為有關該主題的面試做好準備。 存儲庫有一個包含範例的部分 ，其中特別考慮了他們如何設計系統 例如 Twitter、Uber 等。
然而，在繼續討論本資料之前，讓我們仔細看看我們在實踐中面臨的最重要的架構挑戰。 這很重要，因為您必須指定一個頑固且多方面問題的許多方面，然後在給定係統中有效的法規框架內解決它。 Facebook 前員工寫道 ，他分享了自己篩選數百名申請人的經驗。 雖然該影片重點關注大型系統設計以及在尋找此類職位候選人時非常重要的成功標準，但它仍然可以作為設計系統時最重要的事情的綜合資源。 我也建議 這個影片。
建立有關儲存和檢索資料的知識
通常，您關於如何長期儲存和檢索資料的決定會對系統效能產生重大影響。 因此，您必須先了解系統的預期寫入和讀取特性。 然後你需要能夠評估這些指標並根據所做的評估做出選擇。 然而，只有了解現有的資料儲存模式，您才能有效地應對這項工作。 原則上，這意味著與以下方面相關的紮實知識 .
資料庫可以被認為是具有極高可擴展性和持久性的資料結構。 因此，在選擇特定資料庫時，資料結構的知識應該對您非常有用。 例如， 是一個支援各種類型值的資料結構伺服器。 它允許您使用列表和集合等數據結構，並使用眾所周知的演算法讀取數據，例如， ，以持久且易於訪問的方式組織此類工作。
快照 來自 Unsplash
一旦您對各種資料儲存模式有了足夠的了解，您就可以繼續研究資料一致性和可用性。 首先，你需要了解 至少在一般意義上，然後透過仔細研究已建立的模式來完善這些知識 и 。 透過這種方式，您將深入了解該領域，並了解讀取和寫入資料實際上是兩個截然不同的問題，每個問題都有其獨特的挑戰。 借助一些一致性和可用性模式，您可以顯著提高系統效能，同時確保資料順利流向應用程式。
最後，結束關於資料儲存問題的討論，我們也應該提到快取。 它應該在客戶端和伺服器上同時運行嗎？ 您的快取中將包含哪些資料？ 為什麼？ 如何組織緩存失效？ 是否會定期、以一定的時間間隔進行？ 如果是，多久一次？ 我建議開始研究這些主題 上述系統設計入門。
溝通模式
系統由各種組件組成； 這些可能是在同一實體節點內運行的不同進程，也可能是在網路不同部分運行的不同電腦。 您網路中的某些資源可能是私有的，但其他資源應該是公開的，並對從外部存取它們的消費者開放。
需要確保這些資源之間的通信，以及整個系統與外界的資訊交換。 在系統設計的背景下，我們再次面臨一系列新的、獨特的挑戰。 讓我們看看它們有何用處 ，什麼p.
快照 來自 Unsplash
在組織與外界的溝通時，總是非常重要的 ，這項規定也需要認真對待並積極推行。
連線分佈
我不確定將這個主題放在一個單獨的部分對每個人來說都是合理的。 儘管如此，我將在這裡詳細介紹這個概念，並且我相信術語「連接分佈」對本節中的材料進行了最準確的描述。
系統是由許多元件正確連接而成的，它們之間的通訊通常是根據已建立的協定（例如 TCP 和 UDP）來組織的。 然而，這些協定本身通常不足以滿足現代系統的所有需求，現代系統通常在高負載下運行，並且高度依賴使用者需求。 通常需要找到分配連接的方法來應對系統上如此高的負載。
該分佈基於眾所周知的 （DNS）。 這樣的系統允許網域轉換（例如加權循環法和基於延遲的方法）來幫助分配負載。
這是非常重要的，實際上我們今天處理的每個大型網路系統都位於一個或多個負載平衡器後面。 負載平衡器有助於在多個可用執行個體之間指派客戶端請求。 負載平衡器有硬體和軟體兩種形式，但在實踐中，您更常需要處理軟體負載平衡器，例如 и . 從概念上講也與負載平衡器非常相似，儘管第一個和第二個之間存在一個範圍 。 根據您的需求設計系統時必須考慮這些差異。
您還應該了解 （CDN）。 CDN 是一個全球分散式代理伺服器網絡，它從地理位置更靠近特定用戶的節點傳遞訊息。 如果您使用 JavaScript、CSS 和 HTML 編寫的靜態文件，則最好使用 CDN。 此外，提供流量管理器的雲端服務如今很常見，例如， ，為您提供全球分發並減少處理動態內容時的延遲。 但是，當您必須使用無狀態 Web 服務時，此類服務通常很有用。
我們來談談業務邏輯。 建構業務邏輯、任務流程和元件
因此，我們設法討論了系統的各個基礎設施方面。 最有可能的是，使用者甚至沒有考慮系統的所有這些元素，坦白說，根本不關心它們。 使用者感興趣的是與您的系統互動是什麼樣的，透過這樣做可以實現什麼，以及系統如何執行使用者命令，它如何處理使用者資料以及如何處理使用者資料。
正如本文標題所示，我將討論軟體架構和系統設計。 因此，我不打算涵蓋描述如何創建軟體組件的軟體設計模式。 然而，我越想越覺得軟體設計模式和架構模式之間的界線非常模糊，而且這兩個概念是緊密相關的。 我們舉個例子 （事件溯源）。 一旦採用這種架構模式，它將影響系統的幾乎每個方面：資料的長期儲存、系統中採用的一致性等級、系統中元件的形狀等等。 因此，我決定提及一些與業務邏輯直接相關的架構模式。 儘管本文必須限於一個簡單的列表，但我鼓勵您熟悉它並思考與這些模式相關的想法。 給你：
- 概念 ， 尤其， ,
協作方法
您極不可能在專案中作為參與者完全負責系統設計過程。 相反，您很可能必須與在您的任務之內和之外工作的同事進行互動。 在這種情況下，您可能需要與同事一起評估所選的技術解決方案，確定業務需求並了解如何最好地並行化任務。
快照 來自 Unsplash
第一步是對您想要實現的業務目標以及您必須處理哪些移動部分形成準確和共同的理解。 組建模技術，特別是 （事件風暴）有助於顯著加快此過程並增加成功的機會。 這項工作可以在概述之前或之後完成 ，然後隨著產品的成熟而深化。 根據此處將達到的一致性級別，您還可以製定 針對您工作的有限環境。 當您需要談論系統架構時，您可能會發現它很有用 ， 建議的 ，特別是當你需要了解你需要深入研究問題的細節，並想像你想要溝通的事情。
在這個主題上可能還有另一種成熟的技術，其用處不亞於領域驅動設計。 然而，我們以某種方式回歸到對主題領域的理解，因此該領域的知識和經驗 應該對你有用。
來源： www.habr.com