關注開源中國OSC頭條號，獲取最新技術資訊
讓我們看一個公司/客戶與前端框架技術團隊之間的典型對話。
這是你從公司/客戶那裡聽到的，技術團隊因此而瘋狂。當整個世界都從微服務中獲益時，為什麼不應該採用微服務，技術團隊很難說服決策者。
讓我們看看微服務的各種開銷和缺陷。除了處理核心應用程序之外，還需要解決所有的這些問題。
微服務的開銷
- 業務間的通信是一大挑戰
- 服務發現和註冊
- 負載均衡
- 去中心化數據管理
- 分佈式日誌
- 監控
- 安全
- 測試
- 性能／指標
- 分佈式事務
- 容器——Docker/Kubernetes
- API網管
- 熔斷
- CI/CD和DevOps
- 其他...
微服務根本不適合每個人。 我們中的一些人在權衡了複雜性與利益之後，決定繼續使用單一架構。 不能因為每個人都跳橋，結果你也往下跳。
微服務只是個選項。如果不做微服務，您仍然可以實現您的目標。
這些問題需要回答。
- 為什麼你想轉向微服務？
- 你想得到什麼好處？
- 你的組織準備好結構和文化變革了嗎？
- 你的公司是否已有工程技術經驗？
- 那打算遷移多少？什麼時候停止？
- 這樣做的好處大於成本嗎?
讓我們看一下不應該選擇微服務的各種場景
場景1：小團隊
只有少量成員的小團隊無法使用微服務加快速度。 組織需要一定的臨界質量來承受微服務的細微差別和開銷，然而，就單體應用而言，一個由極少數員工組成的小團隊就可管理，維護和運營一個穩定，體積適中的應用程序。
場景2：組織結構和文化
無論最初的應用是否是模塊化的，而微服務化後的架構都將會導致模塊化。幾乎所有的軟件架構擁護者都會同意，這是一個非常好的結果。由微服務們所創建的服務將是自包含的和獨立的。
康威定律(Conway's law)規定，“任何設計系統的組織（這裡只是更廣泛地定義信息系統）將不可避免地產生一種設計，其結構是組織通信結構的副本。”從該定律可以理解，傳統架構只是其孤立和分層組織的副本。隨著組織的發展，決策者不斷在他們的團隊和控制下增加更多的人員作為一種力量的表現，所有的溝通都通過他們。
相比之下，微服務的實踐者建議，為了成功，團隊應該小（可能少於 10 人）和獨立。團隊應該與同一團隊中的開發人員、測試人員、數據庫和運維人員進行交叉功能。他們應該負責應用程序的所有方面，包括可用性、可伸縮性、性能等非功能性方面。
如果組織結構不像這樣，他們甚至不應該考慮轉向微服務。這應該是基於微服務的體系結構的第一個先決條件。
場景3: 試圖證明商業理念 Poc 的初創公司
對於成功的產品來說，初創公司 —— 或任何組織 —— 就此而言，有時會做幾個 PoC 來測試對產品、市場需求、業務場景或技術需求。在充分投入到這個想法的研發之前，需要驗證一個商業理念。無論何時完成，組織都需要以極快的速度快速行動。在這種情形下，完整的微服務架構可能不是一個好選擇。建議將整個應用程序用作為 PoC，然後慢慢將其轉換為微服務。
場景4: 非工程類組織
如果你在一個不以工程為核心的終端用戶組織中，那麼如果你採用微服務則其實是不利的。在一天結束時，所有商業組織都在那裡賺錢的。如果你不專注於為客戶創造價值，並且深陷架構的細節和開銷中，那這絕對不適合你。冒險之前要三思。
改變的原因
到目前為止，你必須明白和確定你選擇微服務架構的真正原因。讓我們來聊聊你會考慮選擇什麼的一些場景。
- 如果整個應用程序或所有服務具有需要被佈署為獨立單元的性質，那麼設計不良的微服務應用程序可能會使情況惡化。
- 以前不成功的單體應用程序：如果設計一個單體應用程序對於團隊來說是一個挑戰，那麼微服務應用程序肯定會失敗。
- 你有一個遺留的應用程序，預計最終會棄之不用。移植遺留下來的單體應用需要大量的時間和精力，這可能並不值得。
- 如果一天只是多次擴展和佈署UI，則可以將UI部分單獨提取出來。然後將這一部分擴展並佈署到單獨的容器中，使用某種API訪問後端應用程序。再說一遍，不需要將所有的東西都放到微服務中
- 一個功能或服務似乎總是在加載和需要擴展。
如果你只需要擴展一個或很少的幾個服務，則不是使用所有的組件來擴展整個單體應用，那麼遷移到微服務可能就是一個真實可行的案例。但是，有辦法避免它。一種方法是從單體應用中提取這些服務，並將它們分別託管在不同的容器中。這不僅有助於擴展它們，而且可以幫你不會將整體遷移到微服務中。
重申一遍，這裡並不是在闡述單體應用或SOA或微服務。是在闡述合適的架構來滿足業務需求。如果不需要去處理微服務的開銷就可以增長並獲得所有的收益，那為什麼還要去考慮它？你可以根據需要慢慢添加更多的服務。在你真正需要或想要它之前，沒有人會強迫你。
結語
我們已經探討了微服務架構的各種細微差別和開銷。它絕不是這樣一種簡單的模式，如果它不生效，它不可以很容易地被採用和丟棄。在將組織推向微服務道路之前，需要考慮所有的優點和缺點。人們需要關注“為什麼是微服務”，而不是“為什麼不是微服務”。 我們還探討了各種方案。這是為了避免在絕對必要之前涉足微服務的各種複雜性。
同樣，你可能不同意我的一些或所有意見，但我很高興我們今天可以探討這個問題。
引用:
- https://www.thoughtworks.com/insights/blog/demystifying-conways-law
- https://martinfowler.com/articles/microservice-trade-offs.html
開源社區OSC「好文翻譯」欄目，旨在每天為用戶推薦並翻譯優質的外網文章。再也不用怕因為英語不過關，被擋在許多技術文章的門外。關注開源社區OSC，每日獲取翻譯好文推薦，點擊“瞭解更多”，閱讀原文章。
閱讀更多 開源社區OSC 的文章
