免費參與·100+跨境活動 
免費下載·4000+跨境資料 
免費學習·2000+直播課程 
免費加入·15萬+賣家交流群 
2020-04-28 15:25
Shopify高級工程師 Kirsten Westeinde 在 Shopify Unite 2019 大會上討論了 Shopify 向模塊化單體架構的演變。這包括使用設計收益線（ design payoff line ）來決定何時進行此更改，如何實現更改，以及為什么將微服務排除在目標架構之外。
一個關鍵的結論是，單體不一定是一個糟糕的架構，它具有許多優點，比如單個測試和部署管道。在項目開始時，當必須快速交付新特性時，這一點特別有用。只有在跨越了“設計收益線”時，也就是糟糕的設計阻礙特性開發的那一點，才應該開始改進架構。就 Shopify 而言，改進其架構并不意味著轉向微服務，而是轉向模塊化單體架構。這結合了單體（例如單個測試和部署管道）和微服務（例如代碼模塊化和解耦）的優點。
Westeinde 認為，單體架構是一個很好的項目起點，他說：“其實，我建議新產品和新公司開始時使用單體架構。”她列舉了其中的一些優點：
一個項目包含所有代碼；
只有一個代碼庫，測試和部署都很簡單；
所有數據都可用，無需跨服務傳遞；
一組基礎設施。
由于這些優點，Shopify 一開始只是一個小型的 Ruby on Rails 單體，隨著時間的推移，逐漸發展成為一個非常大的代碼庫。當這種情況發生時，它意味著 Shopify 開始變得不可維護，并且因此很難交付新特性。例如，更改一段代碼會對看似無關的代碼造成意想不到的副作用，并且構建和測試應用程序花費的時間太長。
Westeinde 援引 Martin Fowler 的設計耐力假說（ design stamina hypothesis ）解釋說，是時候重構他們的架構了——一旦功能開發被糟糕的設計所阻礙，設計收益線就會被跨越，這意味著投入資源來修復它是有意義的。
最初，Shopify 將微服務視為一種可選的、更易于維護的架構。然而，由于分布式系統的復雜性，它被排除在外，取而代之的是更易于維護的單體架構：
我們意識到，我們喜歡單體所有的東西，代碼都在一個地方，而且向一個地方部署。我們遇到的所有問題都是由代碼中不同功能之間缺乏界限所直接導致的。
Westeinde 解釋說，他們意識到他們的設計目標是提升系統的模塊化，比如使用微服務，同時保持一個單一的可部署單元，像一個單體。為了實現這一點，Shopify 采用了模塊化的單體模式。這使得代碼之間有了邊界，但要使代碼都在同一個位置并且部署到同一個位置。遷移路徑如下：
代碼重組：最初，代碼的組織方式類似于典型的 Rails 應用程序，頂層部件以技術組件命名，如控制器。這被更改為基于業務功能進行組織，如“賬單”和“訂單”，從而更容易定位代碼。
隔離依賴關系：每個業務組件彼此隔離，然后通過公共 API 供外部使用。他們內部開發了一個名為 Wedge 的工具，它跟蹤每個組件的隔離情況。它構建一個調用圖，然后計算出哪些調用（比如跨組件的調用）違反了規則。
強制邊界：一旦每個組件都實現了 100% 的隔離，它們之間就有了強制的邊界。其思想是，當代碼試圖訪問它沒有顯式依賴的組件的代碼時，就會出現運行時錯誤。以這種方式聲明依賴關系也將使它們在依賴關系圖中可視化。
最后，Westeinde 解釋說，這個例子很好地說明了架構如何根據業務需求發展：
良好的軟件架構是一項不斷演化的任務，而應用程序的恰當解決方案完全取決于你的操作規模。
（來源：K哥聊出海）
