一文告訴你微服務究竟是什麼

 

微服務等於Spring Cloud？一文告訴你微服務究竟是什麼。

19天前2928

微服務初探

什麼是微服務

首先微服務並無一個官方的定義，想要直接描述微服務比較困難，咱們能夠經過對比傳統WEB應用，來理解什麼是微服務。

傳統的WEB應用核心分爲業務邏輯、適配器以及API或經過UI訪問的WEB界面。業務邏輯定義業務流程、業務規則以及領域實體。適配器包括數據庫訪問組件、消息組件以及訪問接口等。一個打車軟件的架構圖以下：

 

儘管也是遵循模塊化開發，但最終它們會打包並部署爲單體式應用。例如Java應用程序會被打包成WAR，部署在Tomcat或者Jetty上。

這種單體應用比較適合於小項目，優勢是：

1.開發簡單直接，集中式管理

2.基本不會重複開發

3.功能都在本地，沒有分佈式的管理開銷和調用開銷

固然它的缺點也十分明顯，特別對於互聯網公司來講：

1.開發效率低：全部的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷

2.代碼維護難：代碼功能耦合在一塊兒，新人不知道何從下手

3.部署不靈活：構建時間長，任何小修改必須從新構建整個項目，這個過程每每很長

4.穩定性不高：一個微不足道的小問題，能夠致使整個應用掛掉

5.擴展性不夠：沒法知足高併發狀況下的業務需求

因此，如今主流的設計通常會採用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解爲小的、互相鏈接的微服務。一個微服務完成某個特定功能，好比乘客管理和下單管理等。每一個微服務都有本身的業務邏輯和適配器。一些微服務還會提供API接口給其餘微服務和應用客戶端使用。

好比，前面描述的系統可被分解爲：

 

每一個業務邏輯都被分解爲一個微服務，微服務之間經過REST API通訊。一些微服務也會向終端用戶或客戶端開發API接口。但一般狀況下，這些客戶端並不能直接訪問後臺微服務，而是經過API Gateway來傳遞請求。API Gateway通常負責服務路由、負載均衡、緩存、訪問控制和鑑權等任務。

微服務架構的優勢

微服務架構有不少重要的優勢。首先，它解決了複雜性問題。它將單體應用分解爲一組服務。雖然功能總量不變，但應用程序已被分解爲可管理的模塊或服務。這些服務定義了明確的RPC或消息驅動的API邊界。微服務架構強化了應用模塊化的水平，而這經過單體代碼庫很難實現。所以，微服務開發的速度要快不少，更容易理解和維護。

其次，這種體系結構使得每一個服務均可以由專一於此服務的團隊獨立開發。只要符合服務API契約，開發人員能夠自由選擇開發技術。這就意味着開發人員能夠採用新技術編寫或重構服務，因爲服務相對較小，因此這並不會對總體應用形成太大影響。

第三，微服務架構可使每一個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改能夠在測試經過後當即部署。因此微服務架構也使得CI／CD成爲可能。

最後，微服務架構使得每一個服務均可獨立擴展。咱們只需定義知足服務部署要求的配置、容量、實例數量等約束條件便可。好比咱們能夠在EC2計算優化實例上部署CPU密集型服務，在EC2內存優化實例上部署內存數據庫服務。

微服務架構的缺點和挑戰

實際上並不存在silver bullets，微服務架構也會給咱們帶來新的問題和挑戰。其中一個就和它的名字相似，微服務強調了服務大小，但實際上這並無一個統一的標準。業務邏輯應該按照什麼規則劃分爲微服務，這自己就是一個經驗工程。有些開發者主張10-100行代碼就應該創建一個微服務。雖然創建小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發和持續集成部署。

微服務的另外一個主要缺點是微服務的分佈式特色帶來的複雜性。開發人員須要基於RPC或者消息實現微服務之間的調用和通訊，而這就使得服務之間的發現、服務調用鏈的跟蹤和質量問題變得的至關棘手。

微服務的另外一個挑戰是分區的數據庫體系和分佈式事務。更新多個業務實體的業務交易至關廣泛。這些類型的事務在單體應用中實現很是簡單，由於單體應用每每只存在一個數據庫。但在微服務架構下，不一樣服務可能擁有不一樣的數據庫。CAP原理的約束，使得咱們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來講是一個挑戰。

微服務架構對測試也帶來了很大的挑戰。傳統的單體WEB應用只需測試單一的REST API便可，而對微服務進行測試，須要啓動它依賴的全部其餘服務。這種複雜性不可低估。

微服務的另外一大挑戰是跨多個服務的更改。好比在傳統單體應用中，如有A、B、C三個服務須要更改，A依賴B，B依賴C。咱們只需更改相應的模塊，而後一次性部署便可。可是在微服務架構中，咱們須要仔細規劃和協調每一個服務的變動部署。咱們須要先更新C，而後更新B，最後更新A。

部署基於微服務的應用也要複雜得多。單體應用能夠簡單的部署在一組相同的服務器上，而後前端使用負載均衡便可。每一個應用都有相同的基礎服務地址，例如數據庫和消息隊列。而微服務由不一樣的大量服務構成。每種服務可能擁有本身的配置、應用實例數量以及基礎服務地址。這裏就須要不一樣的配置、部署、擴展和監控組件。此外，咱們還須要服務發現機制，以便服務能夠發現與其通訊的其餘服務的地址。所以，成功部署微服務應用須要開發人員有更好地部署策略和高度自動化的水平。

以上問題和挑戰可大致歸納爲：

• API Gateway
• 服務間調用
• 服務發現
• 服務容錯
• 服務部署
• 數據調用

 

幸運的是，出現了不少微服務框架，能夠解決以上問題。

第一代微服務框架

Spring Cloud

Spring Cloud爲開發者提供了快速構建分佈式系統的通用模型的工具（包括配置管理，服務發現，熔斷器，智能路由，微代理，控制總線，一次性令牌，全局鎖，領導選舉，分佈式會話，集羣狀態等）。 主要項目包括：

• spring cloud config：由git存儲庫支持的集中式外部配置管理。配置資源直接映射到Spring Environment，可是若是須要能夠被非Spring應用程序使用。
• spring cloud netflix：與各類Netflix OSS組件（Eureka，Hystrix，Zuul，Archaius等）集成。
• spring cloud bus：用於將服務和服務實例與分佈式消息傳遞聯繫起來的事件總線。用於在集羣中傳播狀態更改（例如配置更改事件）
• spring cloud for cloud foundry：將您的應用程序與Pivotal Cloudfoundry集成。提供服務發現實現，還能夠輕鬆實現經過SSO和OAuth2保護資源，還能夠建立Cloudfoundry服務代理。
• spring cloud cloud foundry service broker：提供構建管理一個Cloud Foundry中服務的服務代理的起點。
• spring cloud cluster：領導選舉和通用狀態模型（基於zookeeper，redis，hazelcast，Consul的抽象和實現）
• spring cloud consul：結合Hashicorp Consul的服務發現和配置管理
• spring cloud security：在Zuul代理中爲負載平衡的OAuth2休眠客戶端和認證頭中繼提供支持。
• spring cloud sleuth：適用於Spring Cloud應用程序的分佈式跟蹤，與Zipkin，HTrace和基於日誌（例如ELK）跟蹤兼容。
• spring cloud data flow：針對現代運行時的可組合微服務應用程序的雲本地編排服務。易於使用的DSL，拖放式GUI和REST-API一塊兒簡化了基於微服務的數據管道的總體編排。
• spring cloud stream：輕量級事件驅動的微服務框架，可快速構建可鏈接到外部系統的應用程序。使用Apache Kafka或RabbitMQ在Spring Boot應用程序之間發送和接收消息的簡單聲明式模型。
• spring cloud stream app starters：Spring Cloud任務應用程序啓動器是Spring Boot應用程序，多是任何進程，包括不會永遠運行的Spring Batch做業，而且它們在有限時間的數據處理以後結束/中止。
• spring cloud zookeeper：Zookeeper的服務發現和配置管理
• spring cloud for amazon web services：輕鬆集成託管的Amazon的Web Services服務。它經過使用spring的idioms和APIs便捷集成AWS服務，例如緩存或消息API。開發人員能夠圍繞託管服務，沒必要關心基礎架構來構建應用。
• spring cloud connectors：使PaaS應用程序在各類平臺上輕鬆鏈接到後端服務，如數據庫和消息代理（之前稱爲「Spring Cloud」的項目）
• spring cloud starters：做爲基於spring boot的啓動項目，下降依賴管理（在Angel.SR2後，不在做爲獨立項目）
• spring cloud cli：插件支持基於Groovy預言快速建立spring cloud的組件應用

Dubbo

Dubbo是一個阿里巴巴開源出來的一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分包含:

• 遠程通信: 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。
• 集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
• 自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

 

可是顯而易見，不管是Dubbo仍是Spring Cloud都只適用於特定的應用場景和開發環境，它們的設計目的並非爲了支持通用性和多語言性。而且它們只是Dev層的框架，缺乏DevOps的總體解決方案（這正是微服務架構須要關注的）。而隨之而來的即是Service Mesh的興起。

下一代微服務：Service Mesh？

Service Mesh

Service Mesh又譯做「服務網格」，做爲服務間通訊的基礎設施層。若是用一句話來解釋什麼是Service Mesh，能夠將它比做是應用程序或者說微服務間的TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。對於編寫應用程序來講通常無須關心TCP/IP這一層（好比經過 HTTP 協議的 RESTful 應用），一樣使用Service Mesh也就無須關係服務之間的那些原來是經過應用程序或者其餘框架實現的事情，好比Spring Cloud、OSS，如今只要交給Service Mesh就能夠了。

Service Mesh有以下幾個特色：

• 應用程序間通信的中間層
• 輕量級網絡代理
• 應用程序無感知
• 解耦應用程序的重試/超時、監控、追蹤和服務發現

Service Mesh的架構以下圖所示：

 

Service Mesh做爲Sidebar運行，對應用程序來講是透明，全部應用程序間的流量都會經過它，因此對應用程序流量的控制均可以在Service Mesh中實現。

目前流行的Service Mesh開源軟件有Linkerd、Envoy和Istio，而最近Buoyant（開源Linkerd的公司）又發佈了基於Kubernetes的Service Mesh開源項目Conduit。

Linkerd

Linkerd是開源網絡代理，設計爲以服務網格部署：用於管理，控制和監控應用程序內的服務與服務間通信的專用層。

Linkerd旨在解決Twitter，Yahoo，Google和Microsoft等公司運營大型生產系統時發現的問題。根據經驗，最複雜，使人驚奇和緊急行爲的來源一般不是服務自己，而是服務之間的通信。Linkerd解決了這些問題，不只僅是控制通信機制，而是在其上提供一個抽象層。

 

它的主要特性有：

• 負載平衡：linkerd提供了多種負載均衡算法，它們使用實時性能指標來分配負載並減小整個應用程序的尾部延遲。
• 熔斷：linkerd包含自動熔斷，將中止將流量發送到被認爲不健康的實例，從而使他們有機會恢復並避免連鎖反應故障。
• 服務發現：linkerd 與各類服務發現後端集成，經過刪除特定的(ad-hoc)服務發現實現來幫助您下降代碼的複雜性。
• 動態請求路由：linkerd 啓用動態請求路由和從新路由，容許您使用最少許的配置來設置分段服務(staging service)，金絲雀(canaries)，藍綠部署(blue-green deploy)，跨DC故障切換和黑暗流量(dark traffic)。
• 重試次數和截止日期：linkerd能夠在某些故障時自動重試請求，而且能夠在指定的時間段以後讓請求超時。
• TLS：linkerd 能夠配置爲使用 TLS 發送和接收請求，您可使用它來加密跨主機邊界的通訊，而不用修改現有的應用程序代碼。
• HTTP代理集成：linkerd 能夠做爲 HTTP 代理，幾乎全部現代 HTTP 客戶端都普遍支持，使其易於集成到現有應用程序中。
• 透明代理：您能夠在主機上使用 iptables 規則，設置經過 linkerd 的透明代理
• gRPC：linkerd 支持 HTTP/2 和 TLS，容許它路由 gRPC 請求，支持高級 RPC 機制，如雙向流，流程控制和結構化數據負載。
• 分佈式跟蹤：linkerd 支持分佈式跟蹤和度量儀器，能夠提供跨越全部服務的統一的可觀察性。
• 儀器儀表: linkerd 支持分佈式跟蹤和度量儀器，能夠提供跨越全部服務的統一的可觀察性。

Envoy

Envoy 是一個面向服務架構的L7代理和通訊總線而設計的，這個項目誕生是出於如下目標：

對於應用程序而言，網絡應該是透明的，當發生網絡和應用程序故障時，可以很容易定位出問題的根源。

Envoy可提供如下特性：

• 外置進程架構：可與任何語言開發的應用一塊兒工做；可快速升級
• 基於新C++11編碼：可以提供高效的性能
• L3/L4過濾器：核心是一個L3/L4網絡代理，可以做爲一個可編程過濾器實現不一樣TCP代理任務，插入到主服務當中。經過編寫過濾器來支持各類任務，如原始TCP代理、HTTP代理、TLS客戶端證書身份驗證等。
• HTTP L7過濾器：支持一個額外的HTTP L7過濾層。HTTP過濾器做爲一個插件，插入到HTTP連接管理子系統中，從而執行不一樣的任務，如緩衝，速率限制，路由/轉發，嗅探Amazon的DynamoDB等等。
• 支持HTTP/2：在HTTP模式下，支持HTTP/1.一、HTTP/2，而且支持HTTP/1.一、HTTP/2雙向代理。這意味着HTTP/1.1和HTTP/2，在客戶機和目標服務器的任何組合均可以橋接
• HTTP L7路由：在HTTP模式下運行時，支持根據content type、runtime values等，基於path的路由和重定向。可用於服務的前端／邊緣代理
• 支持gRPC：gRPC是一個來自谷歌的RPC框架，使用HTTP/2做爲底層的多路傳輸。HTTP/2承載的gRPC請求和應答，均可以使用Envoy的路由和LB能力
• 支持MongoDB L7：支持獲取統計和鏈接記錄等信息
• 支持DynamoDB L7：支持獲取統計和鏈接等信息
• 服務發現：支持多種服務發現方法，包括異步DNS解析和經過REST請求服務發現服務
• 健康檢查：含有一個健康檢查子系統，能夠對上游服務集羣進行主動的健康檢查。也支持被動健康檢查。
• 高級LB：包括自動重試、斷路器，全侷限速，阻隔請求，異常檢測。將來還計劃支持請求速率控制
• 前端代理：可做爲前端代理，包括TLS、HTTP/1.一、HTTP/2，以及HTTP L7路由
• 極好的可觀察性：對全部子系統，提供了可靠的統計能力。目前支持statsd以及兼容的統計庫。還能夠經過管理端口查看統計信息，還支持第三方的分佈式跟蹤機制
• 動態配置：提供分層的動態配置API，用戶可使用這些API構建複雜的集中管理部署

Istio

Istio是一個用來鏈接、管理和保護微服務的開放平臺。Istio提供一種簡單的方式來創建已部署服務網絡，具有負載均衡、服務間認證、監控等功能，而不須要改動任何服務代碼。想要爲服務增長對Istio的支持，您只須要在環境中部署一個特殊的邊車（sidecar），使用Istio控制面板功能配置和管理代理，攔截微服務之間的全部網絡通訊。

Istio目前僅支持在Kubernetes上的服務部署，但將來版本中將支持其餘環境。

Istio提供了一個完整的解決方案，經過爲整個服務網格提供行爲洞察和操做控制來知足微服務應用程序的多樣化需求。它在服務網絡中統一提供了許多關鍵功能：

• 流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，並使網絡在惡劣狀況下更加健壯
• 可觀察性：瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從而提供快速識別問題的能力
• 策略執行：將組織策略應用於服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是經過配置網格而不是修改應用程序代碼
• 服務身份和安全：爲網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其能夠在不一樣可信度的網絡上流轉

Istio服務網格邏輯上分爲數據面板和控制面板：

• 數據面板由一組智能代理（Envoy）組成，代理部署爲邊車，調解和控制微服務之間全部的網絡通訊
• 控制面板負責管理和配置代理來路由流量，以及在運行時執行策略

下圖顯示了構成每一個面板的不一樣組件：

 

Conduit

Conduit是爲Kubernetes設計的一個超輕型服務網格服務，它可透明地管理在Kubernetes上運行的服務的運行時通訊，使得它們更安全可靠。Conduit提供了可見性、可靠性和安全性的功能，而無需更改代碼。

Conduit service mesh也是由數據面板和控制面板組成。數據面板承載應用實際的網絡流量。控制面板驅動數據面板，並對外提供北向接口。

對比

Linkerd和Envoy比較類似，都是一種面向服務通訊的網絡代理，都可實現諸如服務發現、請求路由、負載均衡等功能。它們的設計目標就是爲了解決服務之間的通訊問題，使得應用對服務通訊無感知，這也是Service Mesh的核心理念。Linkerd和Envoy像是分佈式的Sidebar，多個相似Linkerd和Envoy的proxy互相鏈接，就組成了service mesh。

而Istio則是站在了一個更高的角度，它將Service Mesh分爲了Data Plane和Control Plane。Data Plane負責微服務間的全部網絡通訊，而Control Plane負責管理Data Plane Proxy：

 

而且Istio天生的支持Kubernetes，這也彌合了應用調度框架與Service Mesh之間的空隙。

關於Conduit的資料較少，從官方介紹看它的定位和功能與Istio相似。

Kubernetes + Service Mesh

Kubernets已經成爲了容器調度編排的事實標準，而容器正好能夠做爲微服務的最小工做單元，從而發揮微服務架構的最大優點。因此我認爲將來微服務架構會圍繞Kubernetes展開。而Istio和Conduit這類Service Mesh天生就是爲了Kubernetes設計，它們的出現補足了Kubernetes在微服務間服務通信上的短板。雖然Dubbo、Spring Cloud等都是成熟的微服務框架，可是它們或多或少都會和具體語言或應用場景綁定，並只解決了微服務Dev層面的問題。若想解決Ops問題，它們還需和諸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes這類資源調度框架作結合：

 

可是這種結合又因爲初始設計和生態，有不少適用性問題須要解決。

Kubernetes則不一樣，它自己就是一個和開發語言無關的、通用的容器管理平臺，它能夠支持運行雲原生和傳統的容器化應用。而且它覆蓋了微服務的Dev和Ops階段，結合Service Mesh，它能夠爲用戶提供完整端到端的微服務體驗。

因此我認爲，將來的微服務架構和技術棧多是以下形式：

 

多雲平臺爲微服務提供了資源能力（計算、存儲和網絡等），容器做爲最小工做單元被Kubernetes調度和編排，Service Mesh管理微服務的服務通訊，最後經過API Gateway向外暴露微服務的業務接口。

我相信將來隨着以Kubernetes和Service Mesh爲標準的微服務框架的盛行，將大大下降微服務實施的成本，最終爲微服務落地以及大規模使用提供堅實的基礎和保障。