微服務：更愉快還是更嘈雜？

微服務的部署規模在不斷擴大。容器架構的採用和隨後的微服務部署並不是按下一個簡單的按鈕就能完成的，這是一個持續演變的過程。這個演變過程發生在應用程式開發、架構、打包和基礎設施的各個方面。軟體的建立和交付方式在過去幾年中發生了重大轉變。

隨著團隊在這個持續演化的軟體生命週期環境中不斷地探索，他們所在組織的一些獨特方面——他們個人的集體體驗和特定的專案需求——正塑造著這個演化旅程，也就是說，並非每一條通向雲原生的道路都是相同的。應用程式和團隊將利用其中一種或一些甚至是全部方法開啟走向雲原生的道路。

在這裡，我們將專注於微服務。並非所有嘗試建立微服務的應用程式或團隊（從頭開始或拆解單體）都能夠真正意識到微服務架構的好處。通常，由於應用程式設計要求具備前所未有的監控和管理水平，團隊一般都未能取得顯著成功。從建立能夠支援分散式系統問題的環境和基礎設施，到組織和培訓團隊、培養文化和制定運營實踐，再到應用可觀察性和基礎設施即程式碼，以及融入現代DevOps監控工具，團隊的第一次微服務體驗可能是非常混亂的。然而，一旦形成了持續交付的穩定節奏，它們的好處（例如交付速度）卻是其他企業架構應用程式所無法比擬的。

微服務可以幫助團隊實現更快的交付和迭代。微服務為獨立的服務開發團隊帶來語言和技術選擇的民主化——團隊一邊迭代和持續交付軟體（通常作為服務），一邊快速地建立新功能。作為一種設計可擴充套件、可獨立交付的服務的雲原生方法，微服務讓團隊可以以最佳的方式確定服務需求的優先順序。這種提供鬆散耦合功能的做法推動了敏捷性和迭代交付，並強制實現它們所暴露的API的“契約義務”。

來自各個方面的挑戰

由於每個微服務都需要對外暴露API，微服務行為的一致性和版本控制方案的一致性就成了部署微服務時需要面臨的兩大挑戰。大量的微服務不僅加劇了在一致的環境中建立功能、注入DevOps文化和實踐的挑戰，還加劇了確保多個新服務具備互操作性的挑戰。部署的微服務越多，這些挑戰就越嚴峻。

在部署微服務時，更多的移動部件和額外的服務增加了監控的難度。想象一下：你有一個由五個服務組成的應用程式，每個服務又由大約10個容器組成。你對應用程式的物理拓撲及其服務間的邏輯互動的瞭解很快就會過時，因為它的元件會移動。與傳統監控工具支援的靜態虛擬機器不同，微服務的監控工具需要支援臨時構造和原生服務發現。如果你正在使用過時的監控工具，無異於在蒙著眼睛走鋼絲。

微服務部署還可能帶來額外的組織開銷和複雜性。專注於一個服務而不是多個服務可以實現持續交付和敏捷，同時也允許開發人員和運營團隊彼此獨立工作。因此，團隊之間必須保持持續的溝通和協作，才能確保快速迭代服務，而不是去否定DevOps文化。

考慮到所有這些因素，服務團隊應該如何避免責任和工作的擴散，以確保跨微服務的成功交付和運營？

緩解挑戰以獲得收益

雖然服務網格不是什麼銀彈，但它卻試圖解決一個眾所周知的分散式系統的核心挑戰（即沒有同質、可靠、不變的網路）。為了直接解決這些挑戰，服務網格提供了一層新的雲原生可見性、安全性和控制。

服務網格是一個新興的領域，雖然它沒有被納入雲原生應用程式，但為非容器化、非微服務工作負載提供了很多價值。這個額外的工具層為微服務提供了基於策略的網路，描述了網路在面對不斷變化的條件和網路拓撲時的行為。

最後，服務網格提供了一種服務優先的網路，將應用程式開發人員從基礎設施問題中解放出來，如果你願意，還可以通過為服務管理提供可獨立定址的工具層（Layer 5）來擴充套件服務管理職責。服務網格建立了一個網路，讓運營人員能夠定義細粒度的流量控制，在不需要與開發人員互動的情況下影響應用程式的行為。通過宣告性策略，運營人員可以重新控制流經其基礎設施的服務請求。

服務網格提供分散式應用程式服務的可見性、彈性、流量和安全控制，並提供對請求數量、分散式跟蹤和延遲的可觀測性。通過在服務網格上部署微服務，DevOps團隊可以立即獲得指標、日誌和跟蹤資訊，而無需更改應用程式程式碼。服務網格有助於瞭解應用程式執行緩慢的原因，這個問題是服務所有者面臨的最麻煩的問題之一，因為他們不知道是什麼導致應用程式執行緩慢。

DevOps團隊可以從大多數服務網格提供的增強安全性中受益。服務網格可以幫助DevOps團隊識別出不良參與者、標記並阻止使用者傳送大量的非法請求、控制經過身份驗證但沒有呼叫服務許可權的人。

在實踐時，你需要知道些什麼

有很多服務網格部署模型可用在你的微服務架構中。你可以嘗試遵循一些最佳實踐：

衡量必要性：當服務網格變成一種必需品時，這是一種進步。環境越動態，服務越複雜，服務網格的價值就越大。團隊通常先從單個節點的幾個容器開始，當需要擴充套件到幾個節點來獲得彈性時，需要進行容器編排，然後進入服務網格部署階段，因為隨著部署的增長，他們最終將面臨更加嚴峻的挑戰。
瞭解你的應用場景：瞭解對服務網格的依賴程度，以及需要讓服務網格做些什麼，這是使用服務網格的第一步。先從小規模開始，並在進一步深入之前確保它能為你提供你想要的價值。你的基礎設施型別和服務型別將有助於確定要使用哪種服務網格。

例如，某些網格更多地關注容器化環境，而其他網格則更適用於直接在虛擬機器或裸機作業系統上執行的服務。你需要知道你的環境中適合部署哪種服務網格（有些服務網格比較簡單，有些服務網格更容易部署），以及服務網格需要具備哪些功能。Layer5.io為此提供了一些有用的見解。

搞清楚你對網路和應用程式的期望是什麼：你希望從連線微服務的網路中得到什麼好處？你可能希望你的網路儘可能智慧和彈性，讓流量遠離故障以提高叢集的總體可靠性，避免不必要的開銷，如高延遲路由或具有冷快取的伺服器。你可能希望你的網路能夠確保服務之間的流量可以抵禦來自外界的攻擊。你可能希望你的網路能夠通過突顯意外的依賴關係和服務通訊故障為你提供見解。你可能希望你的網路能夠自行收集有關請求的服務級度量指標。

結論

成功部署微服務或採用容器架構並非一蹴而就的事情，大多數團隊肩負維護現有基礎設施和服務的重擔。因此，你可能是循序漸進地轉向雲原生。微服務具有顯著的優勢，並且服務網格可能是解決問題的最佳工具。在實現或考慮使用服務網格時，首先要衡量必要性。在確定有必要使用服務網格之後，請在選擇部署模型之前考慮你的應用場景。如果控制和管理得當，微服務架構會讓你變得更加愉快。

英文原文：https://containerjournal.com/2018/12/05/microservices-the-more-the-merrier-or-meshy-er/