[[274932]]

【51CTO.com快譯】小巧化是軟件領域永恒的主旨：團隊越小、代碼越小、版本越小、代碼駐留和執行所在的環境(容器)越小。變小的目的是讓貴企業可以從云資源獲取最大的優勢，更快地為客戶和用戶帶來更多的價值，從而更長遠地思考。微服務是遠離龐大整體式應用程序的這股潮流的最新代表，這類應用程序在云端運行不暢。

微服務背后的想法對云端運行應用程序大有意義。通過將應用程序分解成越來越小的幾部分，你可以支持敏捷性、按需擴展和頻繁更新。改變、更新或移動應用程序的小部分要比批量轉移或改變整個應用程序容易得多，風險也低得多。這還意味著用戶很少知道你何時進行應用程序更新，因為始終以極小的方式來進行更新。干擾極少，錯誤可以迅速糾正。許多小型獨立團隊管理應用程序的各部分，這與高效的DevOps方法相一致。

最后，CIO們知道僅僅將遺留應用程序遷移到云端帶來的經濟效益有限。只有通過重新設計應用程序的架構以充分利用云的分布式彈性以及云在數據庫、存儲和分析等不同領域所帶來的眾多服務，公司才能真正省錢。這一切都很好，是不是?

好事過多反成壞事?

問題是，微服務很快變得不堪重負。突然你有了一小段代碼，它只與支持某業務流程的一小部分功能有關。這時候，開發團隊在應用程序中構建過多的微服務，而實際上越簡單越好。

編排和管理所有服務以協同運行以便應用程序可靠安全地運行頗具挑戰性。微服務仍與較龐大應用程序對基礎設施有著同樣的需求：備份和恢復、監控、網絡和日志記錄。這時候名為服務網格(service mesh)的新概念開始發揮作用。

服務網格的角色在演變

你打電話給當地市政府時，一位接線員會幫助你快速聯系上合適的部門來解答問題。服務網格以類似的方式運作：這項技術駐留在網絡上，處理微服務之間的所有聯系，并便于訪問諸多共享服務和工具，比如服務發現、故障檢測/恢復、負載均衡、加密、日志記錄、監控和驗證。這使你的開發團隊得以將時間和精力集中在服務本身上，而不是編寫代碼或邏輯以發現所有服務并與它們進行物理網絡連接。服務網格處理所有聯系。

服務網絡正迅速成為容器管理的必要技術。它可以減少開發人員的工作量，因此他們不需要擔心容器之間的所有依賴關系和聯系。開發人員只需使用智能代理或“sidecar”，即可將容器(和微服務)連接到服務網格。

今天流行且常見的服務網格是一種名為Istio的開源技術，它最初由谷歌開發。思科、VMware及其他廠商正將Istio嵌入到各自的產品中。其他可用的開源服務網格技術包括HashiCorp的Consul、Linkerd和Envoy。服務網格技術比較新，但管理它們的工具趨于成熟。

部署服務網格前要考慮什么?

如果貴企業的技術架構大體上同質，又需要對服務的聯系方式進行精細控制，那么服務網格可能不適合。你可能遇到與需要通過這個新的基礎設施層進行通信的微服務有關的延遲問題，因此如果應用程序對延遲的容忍度很低，使用服務網格可能會出問題。延遲可能帶來影響的一個例子是金融服務業;在這個行業，交易需要在幾微秒內完成;增加延遲的任何因素都可能會產生負面影響。

此外，構建和管理服務網格會帶來一定程度的復雜性。比如在Istio中，需要你針對入站請求定義復雜規則，并決定如何處理請求，還要管理遙測數據收集、運行網格的可視化、網格的安全性以及運行網格的網絡方面。企業須權衡這些任務的成本，再決定服務網格是否合理。通常來說，應用程序越復雜，對響應時間和不可預測的規模和工作負載等方面的要求越高，需要服務網格的可能性就越大。

當然，為你的基礎設施添加服務網格會在某些方面增添復雜性，不過改用繁重的微服務和云原生應用程序環境后，它會帶來重大回報，總體上減少管理和維護要求。若實施得當，服務網格技術可以為你的應用程序提升速度、性能、靈活性和經濟效益。

原文標題：Simplifying microservices with a service mesh，作者：Chris Garvey

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】