為什麼InVision將微服務合併回整體？ - bennadel

微服務解決技術和人員問題
為了瞭解為什麼我要破壞一些微服務，重要的是要了解為什麼首先要建立微服務。微服務解決了兩種型別的問題：技術問題和人員問題。

• 技術問題是應用程式的一個方面給基礎架構帶來了不必要的負擔。反過來，這很可能導致較差的使用者體驗（UX）。例如，影像處理需要大量的CPU。如果此CPU負載太大，則可能會開始耗盡應用程式的其餘處理資源。這可能會影響系統延遲。而且，如果它變得足夠糟糕，可能會開始影響系統可用性。
• 人的問題，而另一方面，有一點做與所有的應用程式和一切與你的團隊是如何組織的。您在應用程式的任何給定部分中工作的人越多，開發和部署的速度就越慢且容易出錯。例如，如果您有30位工程師都在爭奪“連續部署”（CD）相同的服務，那麼您將獲得很多排隊；這意味著，許多本來可以運送產品的工程師實際上正圍坐在等待輪到他們部署的時候。

早期的InVision微服務通常解決了“人”問題
自8年前成立以來，InVision一直是一個整體系統，當時只有3位工程師在研究它。隨著公司的發展並獲得關注，系統的數量幾乎沒有增加，而工程團隊的規模開始迅速增長。幾年之內，我們有數十名工程師-後端和前端-都在同一程式碼庫上工作，並且全部部署到同一服務佇列。
正如我上面提到的，很多人都在同一個地方工作可能會變得非常棘手。不僅各個團隊都在爭奪相同的部署資源，這還意味著每次宣告“事件”時，都必須回滾幾個團隊的程式碼。而且，在管理事件時，沒有團隊可以部署。可以想象，這在整個組織中引起了很大的摩擦，無論是工程團隊還是產品團隊。
因此，誕生了“微服務”來解決“人們問題”。一組選定的工程師開始在他們認為與團隊邊界相對應的應用程式各個部分周圍繪製邊界。這樣做是為了使團隊可以更獨立地工作，獨立部署並運送更多產品。早期的InVision微服務幾乎與解決技術問題無關。
 

如果邊界很好，康威定律就是好的
如果您使用微服務，那麼您無疑會聽說過Melvin Conway在1967年提出的“康韋定律”。它指出：

設計系統（廣泛定義）的任何組織都將產生其結構是組織溝通結構的複製設計。
人們經常用“編譯器”示例來說明該法則：

如果您有四個小組從事編譯器工作，您將需要透過4次編譯。
這裡的想法是，解決方案是圍繞團隊結構（和團隊通訊開銷）“最佳化”的，不一定設計為解決任何特定的技術或效能問題。
在微服務之前的世界中，對康威定律的討論通常是負面的。與之類似，Conway法則表示您的應用程式規劃和組織欠佳。但是，在後微服務世界中，康韋定律具有更大的自由度。因為，事實證明，如果您可以將系統分解為具有內聚邊界的一組獨立服務，則可以以更少的錯誤釋出更多的產品，因為您已經建立了更加專注於處理涉及服務的服務的團隊。職責範圍更窄。
當然，康威定律的好處在很大程度上取決於您劃定界限的位置。以及這些邊界如何隨著時間演變。這就是我和我的團隊-Rainbow Team-出現的地方。
多年來，InVision必須從組織和基礎架構的角度發展。這意味著，在後臺，有一個較舊的“舊版”平臺和一個不斷髮展的“現代”平臺。隨著我們更多的團隊遷移到“現代”平臺，這些團隊負責的服務需要移交給其餘的“傳統”團隊。
今天-2020年-我的團隊將成為傳統團隊。我的團隊已逐漸但穩定地負責越來越多的服務。這意味著：人員更少，但程式碼儲存庫更多，更多的程式語言，更多的資料庫，更多的監控儀表板，更多的錯誤日誌，以及更多的late-night頁面。
簡而言之，隨著時間的推移，康威定律給組織帶來的所有好處對我的“傳統”團隊來說已經成為負債。因此，我們一直在努力“確定”我們的職責範圍，使平衡恢復到康韋定律。換句話說，我們正在嘗試更改服務邊界以匹配團隊邊界。這意味著將微服務合併回整體。
 

微服務不是“微小”的，而是“正確大小的”
微服務架構可能發生過的最糟糕的事情是“微”一詞。微型是一個毫無意義但繁重的術語，幾乎充滿了歷史內涵和人類偏見。一個更有用的術語是“正確大小”。微服務從來都不是“小型服務”，而是“合適大小的服務”。
“微型”一無所有。這不代表任何意思; 它什麼也不需要。另一方面，“大小合適”意味著必須對服務進行適當的設計以滿足其要求：它負責“適量”的功能。而且，“正確”不是一個靜態的概念-它取決於團隊，其技能，組織狀態，計算出的投資回報率（ROI），擁有成本以及投入的時間該服務的執行時間。
對於我的團隊來說，“大小合適”意味著更少的儲存庫，更少的部署佇列，更少的語言以及更少的操作儀表板。對於我規模較小的團隊，“合適的規模”更多地是關於“人”而不是“技術”。因此，與InVision最初引入微服務來解決“人問題”的方式一樣，我的團隊現在正在銷燬那些相同的微服務以解決“人問題”。
 

結語：大多數技術不必“獨立擴充套件”
支援建立獨立服務的論點之一是，這些服務可以“獨立擴充套件”。這意味著，您可以在如何配置伺服器和資料庫以滿足服務需求方面更有針對性。因此，您可以建立一些較小的服務，而獨立地擴充套件其他服務，而不必建立大規模的服務以僅擴充套件部分功能。
在為什麼需要獨立擴充套件的所有原因中，關鍵原因是服務經常被使用，但這在我（非常有限）看來通常是無關緊要的。除非某個功能受CPU或IO或記憶體的約束，否則獨立可伸縮性可能不是您要擔心的“靈活性”。在很多時候，您的伺服器都在等待事情發生；嚮應用程式新增“更多HTTP路由處理程式”不會突然耗盡它的所有資源。
如果我可以返回並重做我們早期的微服務嘗試，那麼我將首先100％首先關注所有“ CPU繫結”功能：影像處理和調整大小，縮圖生成，PDF匯出，PDF匯入，檔案版本控制rdiff，ZIP存檔生成。我會沿這些邊界分散團隊，讓他們建立“純”服務，該服務只處理輸入和輸出（即，沒有“整合資料庫”，沒有“共享檔案系統”），以便其他所有服務都可以使用它們同時保持鬆散耦合。
我並不是說這可以解決我們所有的問題-畢竟，“人”的問題比“技術”的問題要多。但是，它本可以解決更多的“正確”問題，從長遠來看，這可能會使生活變得更輕鬆。
 

駭客新聞討論：
認識到微服務是解決人員和組織問題的技術工具。我們需要了解，許多“新”技術正規化（尤其是那些來自FAANG或其他大型組織的技術正規化）通常旨在解決大規模運營的組織問題，而不是提供我們都應該追求的某種技術靈丹妙藥建立。
 
微服務是一種公司的組織管理工具，微服務是解決人員和組織問題的技術工具
  
微服務也可用於解決技術問題。例如，很難在python整體中執行一些python3.5和一些python3.9。整體必須選擇一個python版本，並在某個時間點將其全部切掉。微服務允許更底層的技術變更（在生產中，而不僅僅是在測試套件中）逐步採用。
 
微服務的一個真正問題是您不能再將資料庫系統用於事務完整性。（banq注：這是將微服務與事務完整性割裂的看法，微服務是位於業務事務完整性下的設計，當然這種業務事務完整性不是將邊界擴充套件到無窮大，這是有邊界的，是有界上下文的微服務。）
 
這是一篇很棒的文章-我一直試圖保證的一件事是，您不需要對微服務進行“全力以赴”。一個主要的整體應用程式沒有什麼錯，它的一些部分分成了微服務，這對於效能或團隊管理是必不可少的。
 
技術解決方案是解決人員問題的糟糕解決方案，而架構模式可能是解決人類協作問題的更糟糕的解決方案。微服務通常是“ SOA”的一個好聽的名字，但較小的名稱卻無濟於事，SOA的顯著地位主要是為了向您出售用於許多微服務的硬體主機。微服務佔據了SOA（服務邊界）中最困難，最重要的部分之一，並以更小...替代了它。
 
本文與微服務無關。這是關於在微服務之上構建的整體，然後將程式碼拉回到整體中。如果您使用自己的資料構建服務，並構建用於處理增量的轉換層，則隨著時間的流逝，您可能會脫離整體，為您的域和子域提供謹慎的服務。
 
微服務教會了我如何正確地將DDD應用到整體中。那可能是我去年獲得的最有用的東西。
 
banq評：表面上看：微服務是解決人員和組織問題的技術工具，其實微服務是解決業務問題的技術工具，而對於管理者來說，人員和組織就是用來解決業務問題的，因此業務問題等同於人員與組織問題，但是這兩者還是不同的，解決人員與組織問題的工具很多，比如敏捷與DevOps等；而解決業務問題的工具不多，如DDD，這裡面有一個誰決定誰的問題，對於主張人員與組織問題的人來說，業務問題是盲盒，業務前瞻性設計是沒有必要，只要驅動開發人員摸著石頭過河，快速迭代反饋，在編碼中學習接受教訓，不斷反覆；而對於注重業務問題的人來說：如果我們從事該行業軟體多年，我們對業務問題已經相當瞭解，那麼透過劃分有界上下文，切分業務邊界，然後根據業務邊界劃分人員團隊。這兩種方法各有所長，敏捷迭代適合新專案，DDD適合老專案。