微服務等于Spring?Cloud？了解微服務架構和框架
時間：2021-10-13 14:02:50
手機看文章
掃描二維碼
隨時隨地手機看文章
[導讀]作者：TIMXU來源：https://xiaoxubeii.github.io/articles/microservices-architecture-introduction/微服務初探什么是微服務首先微服務并沒有一個官方的定義，想要直接描述微服務比較困難，我們可以通過對比傳統(tǒng)...
作者：TIM XU來源：https://xiaoxubeii.github.io/articles/microservices-architecture-introduction/微服務初探
什么是微服務
首先微服務并沒有一個官方的定義，想要直接描述微服務比較困難，我們可以通過對比傳統(tǒng)WEB應用，來理解什么是微服務。傳統(tǒng)的WEB應用核心分為業(yè)務邏輯、適配器以及API或通過UI訪問的WEB界面。業(yè)務邏輯定義業(yè)務流程、業(yè)務規(guī)則以及領域實體。適配器包括數(shù)據(jù)庫訪問組件、消息組件以及訪問接口等。一個打車軟件的架構圖如下：盡管也是遵循模塊化開發(fā)，但最終它們會打包并部署為單體式應用。例如Java應用程序會被打包成WAR，部署在Tomcat或者Jetty上。這種單體應用比較適合于小項目，優(yōu)點是：- 開發(fā)簡單直接，集中式管理
- 基本不會重復開發(fā)
- 功能都在本地，沒有分布式的管理開銷和調用開銷
- 開發(fā)效率低：所有的開發(fā)在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷
- 代碼維護難：代碼功能耦合在一起，新人不知道何從下手
- 部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長
- 穩(wěn)定性不高：一個微不足道的小問題，可以導致整個應用掛掉
- 擴展性不夠：無法滿足高并發(fā)情況下的業(yè)務需求
每個業(yè)務邏輯都被分解為一個微服務，微服務之間通過REST API通信。一些微服務也會向終端用戶或客戶端開發(fā)API接口。但通常情況下，這些客戶端并不能直接訪問后臺微服務，而是通過API Gateway來傳遞請求。API Gateway一般負責服務路由、負載均衡、緩存、訪問控制和鑒權等任務。
微服務架構的優(yōu)點
微服務架構有很多重要的優(yōu)點。首先，它解決了復雜性問題。它將單體應用分解為一組服務。雖然功能總量不變，但應用程序已被分解為可管理的模塊或服務。這些服務定義了明確的RPC或消息驅動的API邊界。微服務架構強化了應用模塊化的水平，而這通過單體代碼庫很難實現(xiàn)。因此，微服務開發(fā)的速度要快很多，更容易理解和維護。其次，這種體系結構使得每個服務都可以由專注于此服務的團隊獨立開發(fā)。只要符合服務API契約，開發(fā)人員可以自由選擇開發(fā)技術。這就意味著開發(fā)人員可以采用新技術編寫或重構服務，由于服務相對較小，所以這并不會對整體應用造成太大影響。第三，微服務架構可以使每個微服務獨立部署。開發(fā)人員無需協(xié)調對服務升級或更改的部署。這些更改可以在測試通過后立即部署。所以微服務架構也使得CI／CD成為可能。最后，微服務架構使得每個服務都可獨立擴展。我們只需定義滿足服務部署要求的配置、容量、實例數(shù)量等約束條件即可。比如我們可以在EC2計算優(yōu)化實例上部署CPU密集型服務，在EC2內存優(yōu)化實例上部署內存數(shù)據(jù)庫服務。微服務架構的缺點和挑戰(zhàn)
實際上并不存在silver bullets，微服務架構也會給我們帶來新的問題和挑戰(zhàn)。其中一個就和它的名字類似，微服務強調了服務大小，但實際上這并沒有一個統(tǒng)一的標準。業(yè)務邏輯應該按照什么規(guī)則劃分為微服務，這本身就是一個經(jīng)驗工程。有些開發(fā)者主張10-100行代碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發(fā)和持續(xù)集成部署。微服務的另一個主要缺點是微服務的分布式特點帶來的復雜性。開發(fā)人員需要基于RPC或者消息實現(xiàn)微服務之間的調用和通信，而這就使得服務之間的發(fā)現(xiàn)、服務調用鏈的跟蹤和質量問題變得的相當棘手。微服務的另一個挑戰(zhàn)是分區(qū)的數(shù)據(jù)庫體系和分布式事務。更新多個業(yè)務實體的業(yè)務交易相當普遍。這些類型的事務在單體應用中實現(xiàn)非常簡單，因為單體應用往往只存在一個數(shù)據(jù)庫。但在微服務架構下，不同服務可能擁有不同的數(shù)據(jù)庫。CAP原理的約束，使得我們不得不放棄傳統(tǒng)的強一致性，而轉而追求最終一致性，這個對開發(fā)人員來說是一個挑戰(zhàn)。微服務架構對測試也帶來了很大的挑戰(zhàn)。傳統(tǒng)的單體WEB應用只需測試單一的REST API即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種復雜性不可低估。微服務的另一大挑戰(zhàn)是跨多個服務的更改。比如在傳統(tǒng)單體應用中，若有A、B、C三個服務需要更改，A依賴B，B依賴C。我們只需更改相應的模塊，然后一次性部署即可。但是在微服務架構中，我們需要仔細規(guī)劃和協(xié)調每個服務的變更部署。我們需要先更新C，然后更新B，最后更新A。部署基于微服務的應用也要復雜得多。單體應用可以簡單的部署在一組相同的服務器上，然后前端使用負載均衡即可。每個應用都有相同的基礎服務地址，例如數(shù)據(jù)庫和消息隊列。而微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用實例數(shù)量以及基礎服務地址。這里就需要不同的配置、部署、擴展和監(jiān)控組件。此外，我們還需要服務發(fā)現(xiàn)機制，以便服務可以發(fā)現(xiàn)與其通信的其他服務的地址。因此，成功部署微服務應用需要開發(fā)人員有更好地部署策略和高度自動化的水平。以上問題和挑戰(zhàn)可大體概括為：- API Gateway
- 服務間調用
- 服務發(fā)現(xiàn)
- 服務容錯
- 服務部署
- 數(shù)據(jù)調用
幸運的是，出現(xiàn)了很多微服務框架，可以解決以上問題。第一代微服務框架
Spring Cloud
Spring Cloud為開發(fā)者提供了快速構建分布式系統(tǒng)的通用模型的工具（包括配置管理，服務發(fā)現(xiàn)，熔斷器，智能路由，微代理，控制總線，一次性令牌，全局鎖，領導選舉，分布式會話，集群狀態(tài)等）。主要項目包括：- spring cloud config：由git存儲庫支持的集中式外部配置管理。配置資源直接映射到Spring
Environment，但是如果需要可以被非Spring應用程序使用。 - spring cloud netflix：與各種Netflix OSS組件（Eureka，Hystrix，Zuul，Archaius等）集成。
- spring cloud bus：用于將服務和服務實例與分布式消息傳遞聯(lián)系起來的事件總線。用于在集群中傳播狀態(tài)更改（例如配置更改事件）
- spring cloud for cloud foundry：將您的應用程序與Pivotal Cloudfoundry集成。提供服務發(fā)現(xiàn)實現(xiàn)，還可以輕松實現(xiàn)通過SSO和OAuth2保護資源，還可以創(chuàng)建Cloudfoundry服務代理。
- spring cloud cloud foundry service broker：提供構建管理一個Cloud Foundry中服務的服務代理的起點。
- spring cloud cluster：領導選舉和通用狀態(tài)模型（基于zookeeper，redis，hazelcast，Consul的抽象和實現(xiàn)）
- spring cloud consul：結合Hashicorp Consul的服務發(fā)現(xiàn)和配置管理
- spring cloud security：在Zuul代理中為負載平衡的OAuth2休眠客戶端和認證頭中繼提供支持。
- spring cloud sleuth：適用于Spring Cloud應用程序的分布式跟蹤，與Zipkin，HTrace和基于日志（例如ELK）跟蹤兼容。
- spring cloud data flow：針對現(xiàn)代運行時的可組合微服務應用程序的云本地編排服務。易于使用的DSL，拖放式GUI和REST-API一起簡化了基于微服務的數(shù)據(jù)管道的整體編排。
- spring cloud stream：輕量級事件驅動的微服務框架，可快速構建可連接到外部系統(tǒng)的應用程序。使用Apache Kafka或RabbitMQ在Spring Boot應用程序之間發(fā)送和接收消息的簡單聲明式模型。
- spring cloud stream app starters：Spring Cloud任務應用程序啟動器是Spring Boot應用程序，可能是任何進程，包括不會永遠運行的Spring Batch作業(yè)，并且它們在有限時間的數(shù)據(jù)處理之后結束/停止。
- spring cloud zookeeper：Zookeeper的服務發(fā)現(xiàn)和配置管理
- spring cloud for amazon web services：輕松集成托管的Amazon的Web Services服務。它通過使用spring的idioms和APIs便捷集成AWS服務，例如緩存或消息API。開發(fā)人員可以圍繞托管服務，不必關心基礎架構來構建應用。
- spring cloud connectors：使PaaS應用程序在各種平臺上輕松連接到后端服務，如數(shù)據(jù)庫和消息代理（以前稱為“Spring Cloud”的項目）
- spring cloud starters：作為基于spring boot的啟動項目，降低依賴管理（在Angel.SR2后，不在作為獨立項目）
- spring cloud cli：插件支持基于Groovy預言快速創(chuàng)建spring cloud的組件應用
Dubbo
Dubbo是一個阿里巴巴開源出來的一個分布式服務框架，致力于提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分包含:- 遠程通訊: 提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
- 集群容錯: 提供基于接口方法的透明遠程過程調用，包括多協(xié)議支持，以及軟負載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。
- 自動發(fā)現(xiàn): 基于注冊中心目錄服務，使服務消費方能動態(tài)的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
但是顯而易見，無論是Dubbo還是Spring Cloud都只適用于特定的應用場景和開發(fā)環(huán)境，它們的設計目的并不是為了支持通用性和多語言性。并且它們只是Dev層的框架，缺少DevOps的整體解決方案（這正是微服務架構需要關注的）。而隨之而來的便是Service Mesh的興起。下一代微服務：Service Mesh？
Service Mesh
Service Mesh又譯作“服務網(wǎng)格”，作為服務間通信的基礎設施層。如果用一句話來解釋什么是Service Mesh，可以將它比作是應用程序或者說微服務間的TCP/IP，負責服務之間的網(wǎng)絡調用、限流、熔斷和監(jiān)控。對于編寫應用程序來說一般無須關心TCP/IP這一層（比如通過 HTTP 協(xié)議的 RESTful 應用），同樣使用Service Mesh也就無須關系服務之間的那些原來是通過應用程序或者其他框架實現(xiàn)的事情，比如Spring Cloud、OSS，現(xiàn)在只要交給Service Mesh就可以了。Service Mesh有如下幾個特點：- 應用程序間通訊的中間層
- 輕量級網(wǎng)絡代理
- 應用程序無感知
- 解耦應用程序的重試/超時、監(jiān)控、追蹤和服務發(fā)現(xiàn)
Service Mesh作為Sidebar運行，對應用程序來說是透明，所有應用程序間的流量都會通過它，所以對應用程序流量的控制都可以在Service Mesh中實現(xiàn)。目前流行的Service Mesh開源軟件有Linkerd、Envoy和Istio，而最近Buoyant（開源Linkerd的公司）又發(fā)布了基于Kubernetes的Service Mesh開源項目Conduit。Linkerd
Linkerd是開源網(wǎng)絡代理，設計為以服務網(wǎng)格部署：用于管理，控制和監(jiān)控應用程序內的服務與服務間通訊的專用層。Linkerd旨在解決Twitter，Yahoo，Google和Microsoft等公司運營大型生產(chǎn)系統(tǒng)時發(fā)現(xiàn)的問題。根據(jù)經(jīng)驗，最復雜，令人驚奇和緊急行為的來源通常不是服務本身，而是服務之間的通訊。Linkerd解決了這些問題，不僅僅是控制通訊機制，而是在其上提供一個抽象層。它的主要特性有：- 負載平衡：linkerd提供了多種負載均衡算法，它們使用實時性能指標來分配負載并減少整個應用程序的尾部延遲。
- 熔斷：linkerd包含自動熔斷，將停止將流量發(fā)送到被認為不健康的實例，從而使他們有機會恢復并避免連鎖反應故障。
- 服務發(fā)現(xiàn)：linkerd 與各種服務發(fā)現(xiàn)后端集成，通過刪除特定的(ad-hoc)服務發(fā)現(xiàn)實現(xiàn)來幫助您降低代碼的復雜性。
- 動態(tài)請求路由：linkerd 啟用動態(tài)請求路由和重新路由，允許您使用最少量的配置來設置分段服務(staging service)，金絲雀(canaries)，藍綠部署(blue-green deploy)，跨DC故障切換和黑暗流量(dark traffic)。
- 重試次數(shù)和截止日期：linkerd可以在某些故障時自動重試請求，并且可以在指定的時間段之后讓請求超時。
- TLS：linkerd 可以配置為使用 TLS 發(fā)送和接收請求，您可以使用它來加密跨主機邊界的通信，而不用修改現(xiàn)有的應用程序代碼。
- HTTP代理集成：linkerd 可以作為 HTTP 代理，幾乎所有現(xiàn)代 HTTP 客戶端都廣泛支持，使其易于集成到現(xiàn)有應用程序中。
- 透明代理：您可以在主機上使用 iptables 規(guī)則，設置通過 linkerd 的透明代理
- gRPC：linkerd 支持 HTTP/2 和 TLS，允許它路由 gRPC 請求，支持高級 RPC 機制，如雙向流，流程控制和結構化數(shù)據(jù)負載。
- 分布式跟蹤：linkerd 支持分布式跟蹤和度量儀器，可以提供跨越所有服務的統(tǒng)一的可觀察性。
- 儀器儀表: linkerd 支持分布式跟蹤和度量儀器，可以提供跨越所有服務的統(tǒng)一的可觀察性。
Envoy
Envoy 是一個面向服務架構的L7代理和通信總線而設計的，這個項目誕生是出于以下目標：對于應用程序而言，網(wǎng)絡應該是透明的，當發(fā)生網(wǎng)絡和應用程序故障時，能夠很容易定位出問題的根源。Envoy可提供以下特性：
- 外置進程架構：可與任何語言開發(fā)的應用一起工作；可快速升級
- 基于新C 11編碼：能夠提供高效的性能
- L3/L4過濾器：核心是一個L3/L4網(wǎng)絡代理，能夠作為一個可編程過濾器實現(xiàn)不同TCP代理任務，插入到主服務當中。通過編寫過濾器來支持各種任務，如原始TCP代理、HTTP代理、TLS客戶端證書身份驗證等。
- HTTP L7過濾器：支持一個額外的HTTP L7過濾層。HTTP過濾器作為一個插件，插入到HTTP鏈接管理子系統(tǒng)中，從而執(zhí)行不同的任務，如緩沖，速率限制，路由/轉發(fā)，嗅探Amazon的DynamoDB等等。
- 支持HTTP/2：在HTTP模式下，支持HTTP/1.1、HTTP/2，并且支持HTTP/1.1、HTTP/2雙向代理。這意味著HTTP/1.1和HTTP/2，在客戶機和目標服務器的任何組合都可以橋接
- HTTP L7路由：在HTTP模式下運行時，支持根據(jù)content type、runtime values等，基于path的路由和重定向?？捎糜诜盏那岸耍吘壌?/span>
- 支持gRPC：gRPC是一個來自谷歌的RPC框架，使用HTTP/2作為底層的多路傳輸。HTTP/2承載的gRPC請求和應答，都可以使用Envoy的路由和LB能力
- 支持MongoDB L7：支持獲取統(tǒng)計和連接記錄等信息
- 支持DynamoDB L7：支持獲取統(tǒng)計和連接等信息
- 服務發(fā)現(xiàn)：支持多種服務發(fā)現(xiàn)方法，包括異步DNS解析和通過REST請求服務發(fā)現(xiàn)服務
- 健康檢查：含有一個健康檢查子系統(tǒng)，可以對上游服務集群進行主動的健康檢查。也支持被動健康檢查。
- 高級LB：包括自動重試、斷路器，全局限速，阻隔請求，異常檢測。未來還計劃支持請求速率控制
- 前端代理：可作為前端代理，包括TLS、HTTP/1.1、HTTP/2，以及HTTP L7路由
- 極好的可觀察性：對所有子系統(tǒng)，提供了可靠的統(tǒng)計能力。目前支持statsd以及兼容的統(tǒng)計庫。還可以通過管理端口查看統(tǒng)計信息，還支持第三方的分布式跟蹤機制
- 動態(tài)配置：提供分層的動態(tài)配置API，用戶可以使用這些API構建復雜的集中管理部署
Istio
Istio是一個用來連接、管理和保護微服務的開放平臺。Istio提供一種簡單的方式來建立已部署服務網(wǎng)絡，具備負載均衡、服務間認證、監(jiān)控等功能，而不需要改動任何服務代碼。想要為服務增加對Istio的支持，您只需要在環(huán)境中部署一個特殊的邊車（sidecar），使用Istio控制面板功能配置和管理代理，攔截微服務之間的所有網(wǎng)絡通信。Istio目前僅支持在Kubernetes上的服務部署，但未來版本中將支持其他環(huán)境。Istio提供了一個完整的解決方案，通過為整個服務網(wǎng)格提供行為洞察和操作控制來滿足微服務應用程序的多樣化需求。它在服務網(wǎng)絡中統(tǒng)一提供了許多關鍵功能：- 流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，并使網(wǎng)絡在惡劣情況下更加健壯
- 可觀察性：了解服務之間的依賴關系，以及它們之間流量的本質和流向，從而提供快速識別問題的能力
- 策略執(zhí)行：將組織策略應用于服務之間的互動，確保訪問策略得以執(zhí)行，資源在消費者之間良好分配。策略的更改是通過配置網(wǎng)格而不是修改應用程序代碼
- 服務身份和安全：為網(wǎng)格中的服務提供可驗證身份，并提供保護服務流量的能力，使其可以在不同可信度的網(wǎng)絡上流轉
- 數(shù)據(jù)面板由一組智能代理（Envoy）組成，代理部署為邊車，調解和控制微服務之間所有的網(wǎng)絡通信
- 控制面板負責管理和配置代理來路由流量，以及在運行時執(zhí)行策略
Conduit
Conduit是為Kubernetes設計的一個超輕型服務網(wǎng)格服務，它可透明地管理在Kubernetes上運行的服務的運行時通信，使得它們更安全可靠。Conduit提供了可見性、可靠性和安全性的功能，而無需更改代碼。Conduit service mesh也是由數(shù)據(jù)面板和控制面板組成。數(shù)據(jù)面板承載應用實際的網(wǎng)絡流量?？刂泼姘弪寗訑?shù)據(jù)面板，并對外提供北向接口。對比
Linkerd和Envoy比較相似，都是一種面向服務通信的網(wǎng)絡代理，均可實現(xiàn)諸如服務發(fā)現(xiàn)、請求路由、負載均衡等功能。它們的設計目標就是為了解決服務之間的通信問題，使得應用對服務通信無感知，這也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar，多個類似Linkerd和Envoy的proxy互相連接，就組成了service mesh。而Istio則是站在了一個更高的角度，它將Service Mesh分為了Data Plane和Control Plane。Data Plane負責微服務間的所有網(wǎng)絡通信，而Control Plane負責管理Data Plane Proxy：并且Istio天生的支持Kubernetes，這也彌合了應用調度框架與Service Mesh之間的空隙。關于Conduit的資料較少，從官方介紹看它的定位和功能與Istio類似。Kubernetes Service Mesh
Kubernets已經(jīng)成為了容器調度編排的事實標準，而容器正好可以作為微服務的最小工作單元，從而發(fā)揮微服務架構的最大優(yōu)勢。所以我認為未來微服務架構會圍繞Kubernetes展開。而Istio和Conduit這類Service Mesh天生就是為了Kubernetes設計，它們的出現(xiàn)補足了Kubernetes在微服務間服務通訊上的短板。雖然Dubbo、Spring Cloud等都是成熟的微服務框架，但是它們或多或少都會和具體語言或應用場景綁定，并只解決了微服務Dev層面的問題。若想解決Ops問題，它們還需和諸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes這類資源調度框架做結合：但是這種結合又由于初始設計和生態(tài)，有很多適用性問題需要解決。Kubernetes則不同，它本身就是一個和開發(fā)語言無關的、通用的容器管理平臺，它可以支持運行云原生和傳統(tǒng)的容器化應用。并且它覆蓋了微服務的Dev和Ops階段，結合Service Mesh，它可以為用戶提供完整端到端的微服務體驗。所以我認為，未來的微服務架構和技術?？赡苁侨缦滦问剑?/span>多云平臺為微服務提供了資源能力（計算、存儲和網(wǎng)絡等），容器作為最小工作單元被Kubernetes調度和編排，Service Mesh管理微服務的服務通信，最后通過API Gateway向外暴露微服務的業(yè)務接口。我相信未來隨著以Kubernetes和Service Mesh為標準的微服務框架的盛行，將大大降低微服務實施的成本，最終為微服務落地以及大規(guī)模使用提供堅實的基礎和保障。 
下載文檔
