架構師職業迴歸：分散式系統架構師 - Leon

banq發表於2022-05-27
架構分散式

不久前，在一個並不遙遠的IT世界裡，架構師的角色被認為是不必要的。開發人員精通他們在大學資料庫和網頁設計課上學到的三層架構和ERD。精通物件建模、UML圖解和文件的架構師只是臃腫的，是已逝的瀑布時代的遺物。

這在雲端計算時代已經完全改變了。現代的架構師不是畫類圖，而是製作使微服務之間相互作用的順序和步驟。

分散式微服務系統架構的第一步是從事件風暴開始的。這是由Alberto Brandolini推廣的一種設計思維方法。它是一個協作過程，用於發現系統的領域，併產生微服務的範圍和邊界。微服務的術語在很大程度上借鑑了Eric Evans的領域驅動設計軟體方法，其核心是業務領域。這是一個需要實現的應用問題空間或業務功能。一個微服務的範圍就是這個單一的領域。

讓我們把話說清楚，領域驅動設計和事件風暴是架構性的，而不是功能性的。一個功能分析員雖然是業務領域的專家，但卻缺乏技術上的細微差別來產生適當的範圍和微服務的相互作用。然而，他們將與架構師合作。

在光譜的另一端，軟體開發人員將更關注技術範圍，並看到業務流程。在微服務的世界裡，沒有適當設計的牛仔編碼只會產生一個分散式的微控制器。大多數企業今天開始他們的雲端計算之旅，將永遠被網路延遲、複雜性和（上帝保佑）意外的資料損失所創傷，這些都是由設計不良的分散式系統引起的。

敏捷原則仍然適用。全面的文件是不需要的。相反，一個微服務和能力的清單將有助於計劃衝刺。微服務的劃分可能會有錯誤，所以變化可以在途中發生。但是，透過思考設計和它應該如何工作，將使實施時的系統更加乖巧。

人和關係是這個過程的核心。架構師很少在孤立的環境中工作。她必須與客戶的領域專家、開發團隊和專案經理互動。策略和適當的政治敏銳性是對她的角色的一個硬性 "軟技能 "要求。

從物件導向設計的角度來看，架構師在編碼開始之前應該是中立的。雖然Eric Evans的書重在物件導向的原則，但必須瞭解他是在前SOA時代寫的，更不用說微服務時代了。對微服務進行建模，聚合其實體、值物件和關係是高階開發人員或團隊領導的任務。而他們的模型將是他們的程式碼。架構師將對微服務之間的合同進行建模。他們將使用REST（OpenAPI）合同（或gRPC）進行同步呼叫，並透過Kafkaesque事件進行非同步呼叫的事件規範。

合同可以改變，整個開發過程中的事件也可以改變。沒有什麼是一成不變的。但是，整體的呼叫順序以及一個服務如何與下一個服務對話以提供功能，需要一個整體的系統檢視。一些在微服務上工作的開發者將無法看到或考慮到在他們領域的雜草中的東西。

但是微服務是自成一體的...

"正確的設計意味著每個微服務都是自成一體的，不管其他服務做什麼，都要做自己的事情"，或者這樣認為。這是正確的，但業務功能往往會跨越多個服務。因此，需要這個能看到大局並能協調它們的人。

從這個角度來看，當前端沿著微型前端的新生模式劃分時，也同樣適用。當你想協調多件軟體的時候，就是你開始需要一個架構師的時候。

在所有這些理論化的過程中，架構師還應該寫出概念證明或棘手的程式碼。俗話說，"程式碼贏得爭論"，所以適當的編碼能力是一個硬性要求。不畫框，不知道它們的意思。她還可以專注於測試程式碼或健身功能，以確保軟體按預期執行。當然，她還應該在實踐層面上熟悉DevOps和承載程式碼的雲基礎設施。

當年的情況要簡單得多，一個開發人員就可以構建整個單體架構並讓一百個使用者入駐。即使在今天，一個好的軟體開發團隊也足夠了。他們可以解決大多數問題，但他們會在不斷地編寫和重寫、分割和組合他們的微服務時增加專案的價格標籤。因此，對於今天迎合數百萬使用者的複雜系統，軟體架構師是成功的必要條件。

物件導向的象牙塔架構師已經死了！分散式系統架構師萬歲！
 

相關文章