01
微服務架構的演進
微服務架構⾸先要⾯對分散式架構的內⽣複雜性，即：服務通訊和服務治理的複雜性，例如：服務發現、熔斷、限流、全鏈路追蹤等挑戰。
⼀個完整的微服務系統底座的基本功能應該包含：
API ⽹關：
微服務 API 託管、認證和鑑權、負載均衡等。
資源管理：
計算、儲存、⽹絡資源的管理。
編排（解決服務部署問題）：
排程、部署和升級。
熔斷、服務降級、限流（解決服務容錯問題）。
訊息匯流排（解決服務間調⽤問題）：
輕量級的 MQ 或 HTTP。
服務中⼼（解決服務發現問題）：
服務註冊、發現、訂閱。
監控和告警：
監控每個服務的狀態，必要時產⽣告警。
⽇志和審計：
⽇志的彙總，分類和查詢。
調⽤鏈跟蹤：
問題跟蹤除錯框架。
01第一代微服務框架
第⼀代微服務框架，如 Dubbo 或 Spring Cloud 以程式碼庫的⽅式來封裝這些能⼒。這些程式碼庫被構建在應⽤程式本身中，隨著應⽤⼀起釋出和維護。顯⽽易⻅的，兩者都是隻適⽤於特定的應⽤場景和開發環境，它們的設計⽬的並不是為了⽀持通⽤性和多語⾔性。並且它們只是 Dev 層的框架，缺少 DevOps 的整體解決⽅案（這正是微服務架構需要關注的）。
Spring Cloud
Spring Cloud 為開發者提供了快速構建分散式系統的通⽤模型的⼯具，包括：配置管理、服務發現、熔斷器、智慧路由、微代理、控制匯流排、⼀次性令牌、全域性鎖、領導選舉、分散式會話、叢集狀態等。
主要項⽬有：
Spring Cloud Config：
由 Git 儲存庫⽀持的集中式外部配置管理。配置資源直接對映到 Spring Environment。
Spring Cloud Netflix：
與各種 Netflix OSS 元件（Eureka，Hystrix，Zuul，Archaius 等）成。
Spring Cloud Bus：
⽤於將服務和服務例項與分散式訊息傳遞聯絡起來的事件匯流排。⽤於在叢集中傳播狀態更改，例如：配置更改事件。
Spring Cloud for Cloudfoundry：
將您的應⽤程式與 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 Application 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 Starters：
作為基於 Spring Boot 的啟動項⽬，降低依賴管理（在 Angel。SR2 後，不在作為獨⽴項⽬）。
Spring Cloud CLI：
外掛⽀持基於 Groovy ⾔快速建立 Spring Cloud 的元件應⽤。
Dubbo
Dubbo 是⼀個阿⾥巴巴開源出來的⼀個分散式服務框架，致⼒於提供⾼效能和透明化的 RPC 遠端服務調⽤⽅案，以及 SOA 服務治理⽅案。
其核⼼部分包含：
遠端通訊：
提供對多種基於⻓連線的 NIO 框架抽象封裝，包括多種執行緒模型，序列化，以及 “請求-響應” 模式的資訊交換⽅式。
叢集容錯：
提供基於接⼝⽅法的透明遠端過程調⽤，包括多協議⽀持，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集⽀持。
叢集容錯：
基於註冊中⼼⽬錄服務，使服務消費⽅能動態的查詢服務提供⽅，使地址透明，使服務提供⽅可以平滑增加或減少機器。
02下一代微服務框架-Service Mesh
Service Mesh 作為服務間通訊的基礎設施層，可以簡單理解為：Service Mesh 是微服務之間的 TCP 和 IP 協議，負責服務之間的⽹絡調⽤、限流、熔斷和監控。
對於應⽤程式開發⽽⾔，開發者通常不需要關⼼ L3、L4 層的⽹絡通訊協議。同樣的，使⽤ Service Mesh 之後，微服務之間就⽆須關⼼服務之間的通訊那些，原來使⽤ Spring Cloud 或 Dubbo 框架來實現的通訊程式碼邏輯了。
在 CaaS 中，Service Mesh 作為 Sidecar 運⾏，對微服務來說是透明，但所有微服務之間的流量都會透過它，所以對微服務的流量控制都可以在 Service Mesh 中實現。可⻅ Service Mesh 是雲原⽣理念中“容器設計模式” 的典範。⽬前流⾏的 Service Mesh 開源軟體有 Linkerd、Envoy 和 Istio。
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
Istio 提供了⼀個完整的解決⽅案，透過為整個 Service Mesh 提供⾏為洞察和操作控制來滿⾜微服務應⽤程式的多樣化需求，且不需要改動任何微服務的業務程式碼。
Istio 提供了許多 Service Mesh 的關鍵功能：
流量管理：
控制服務之間的流量和 API 調⽤的流向，使得調⽤更可靠，並使⽹絡在惡劣情況下更加健壯。
可觀察性：
瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從⽽提供快速識別問題的能⼒。
策略執⾏：
將組織策略應⽤於服務之間的互動，確保訪問策略得以執⾏，資源在消費者之間良好分配。策略的更改是透過配置⽹格⽽不是修改應⽤程式程式碼。
服務身份和安全：
為⽹格中的服務提供可驗證身份，並提供保護服務流量的能⼒，使其可以在不同可信度的⽹絡上流轉。
Istio 提供了⼀種簡單的⽅式來構建 Service Mesh，只需要在 Pod 中部署⼀個特殊的 Sidecar Container，然後使⽤ Istio 的控制⾯來配置和管理代理，攔截微服務之間的所有⽹絡通訊。
Istio 的軟體架構從邏輯上分為資料⾯和控制⾯：
資料⾯：
由⼀組智慧代理（Envoy）組成，代理邏輯部署為 Sidecar，調解和控制微服務之間所有的⽹絡通訊。
控制⾯：
負責管理和配置代理來路由流量，以及在運⾏時執⾏策略。
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。1、HTTP/2，並且⽀持 HTTP/1。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。1、HTTP/2，以及 HTTP L7 路由。
極好的可觀察性：
對所有⼦系統，提供了可靠的統計能⼒。⽬前⽀持 statsd 以及相容的統計庫。還可以透過管理端⼝檢視統計資訊，還⽀持第三⽅的分散式跟蹤機制。
動態配置：
提供分層的動態配置 API，⽤戶可以使⽤這些 API 構建複雜的集中管理部署。
Kubernetes + Service Mesh = 完整的微服務框架
Kubernetes 是容器排程編排的事實標準，並且 Istio 天⽣的⽀持 Kubernetes，這就彌合了應⽤編排框架與 Service Mesh 之間的空隙。Istio 等 Service Mesh 元件的出現補⾜了 Kubernetes 在微服務間服務通訊上的短板。
雖然 Dubbo、Spring Cloud 等都是成熟的微服務框架，但是它們或多或少都會和具體語⾔或應⽤場景繫結，並只解決了微服務 Dev（開發）層⾯的問題。若想解決 Ops（運維）問題，它們還需和諸如 Cloud Foundry、Mesos、Docker Swarm 或 Kubernetes 這類資源排程框架做結合。但是這種結合⼜由於初始設計和⽣態，有很多適⽤性問題需要解決。
Kubernetes 則不同，它本身就是⼀個 “不可變基礎設施”，與開發語⾔⽆關的、通⽤的容器管理平臺，它可以⽀持運⾏雲原⽣和傳統的容器化應⽤。並且它覆蓋了微服務的 Dev 和 Ops 階段，結合Service Mesh，它可以為⽤戶提供完整端到端的微服務體驗。
在未來，⼀個趨近於 PaaS 形態的微服務框架技術棧應該是如下形式：
IaaS：
提供了資源能⼒（計算、儲存、⽹絡）。
CaaS：
提供容器編排能⼒。
Service Mesh：
提供微服務間東⻄向通訊的能⼒。
APIGW：
對外暴露微服務的南北向業務⼊⼝。
02
微服務架構的內涵
01容器之於微服務架構
不同微服務之間可能存在⼀些異構，為了讓每⼀個團隊在微服務體系下發揮最⼤效能，需要允許不同團隊採⽤不同的程式設計語⾔，甚⾄不同的運⾏環境來去運⾏這些微服務。因此，在運維和管理微服務時，最初其實並沒有⼀套統⼀的標準去處理的異構環境，這也是為什麼後來容器技術變得流⾏起來，它的⼀重要作⽤就是透過⼀層標準的封裝以及標準的運⾏時，來標準化微服務部署。這樣從⽣命週期管理的⻆度來看，每⼀個微服務之間的差異就會變少，共同點變多。所以容器也被稱為 “不可變基礎設施”。
02Kubernetes之於微服務架構
Kubernetes 的作⽤是幫助把已經標準化的微服務最便捷地運⾏到底層資源上⾯。我們講到的儲存、計算、⽹絡都透過 Kubernetes 這層進⾏了統⼀抽象和封裝，讓已經被容器統⼀的微服務能夠直接運⾏到Kubernetes 平臺。因此，運維⼈員不⽤再苦惱如何去把某個微服務分配到具體的某⼀個資源或計算單元上去。透過容器和容器平臺，⼤⼤簡化了微服務本身的⽣命週期管理，簡化了微服務⾃身的運維管理問題，也促進了微服務更多地被企業所採⽤。
Kubernetes 具有⼀個 Pod 的概念。⼀個 Pod 實際上是⼀組容器的集合，在⼀個 Pod 中可以運⾏⼀個或多個容器。⼀般來講，當我們採⽤微服務架構時，會把微服務的主體運⾏在主容器中，主容器的⽣命週期跟 Pod ⾃身的⽣命週期是⼀個耦合的狀態。除了主容器之外，在同⼀個 Pod 中還會運⾏⼀些邊⻋容器（Sidecar 容器），為主容器提供⼀些輔助功能，⽐如：⽇志採集、⽹絡代理、身份鑑權等，這樣微服務除了⾃身提供的核⼼業務服務以外，透過 Kubernetes 我們還可以動態新增⼀些額外的輔助能⼒，讓微服務管理變得更健壯。
這種微服務應⽤的設計思想被稱為 “容器設計模式”。
03DevOps 之於微服務架構
當我們將⼤型的單體應⽤拆解為多個微服務，也⼀定會增加 IT 系統研發協同、交付、運維的複雜性。雲原⽣就在於幫助微服務解決⽣命週期管理以及運維管理難題。
因為微服務的數量⾮常多，部署、管理的⼯作量很⼤。
開發⽅⾯：
如何保證各個服務在持續開發的情況下仍然保持協同合作。
開發⽅⾯：
服務拆分後，⼏乎所有功能都會涉及多個服務。原本單個程式的測試變為服務間調⽤的測試。測試變得更加複雜。
⽽隨著 CI/CD 概念推⼴以及容器技術普及，微服務將這兩種理念和技術結合起來，形成新的：“微服務 +API + 平臺” 的開發模式，提出了容器化微服務的持續交付概念。傳統單體架構 DevOps 開發⽅式，要求產品隊伍橫跨產品管理、開發、QA、DBA 以及系統運維管理。
在測試⽅⾯，微服務架構下的測試分為三個層次：
1. 端到端（整合）測試：
覆蓋整個系統，⼀般在⽤戶界⾯進⾏測試。由於端到端測試實施難度較⼤，⼀般只對核⼼功能做端到端測試。⼀旦端到端測試失敗，則需要將其分解到單元測試，分析失敗原因，然後編寫單元測試來重現這個問題，這樣未來我們便可以更快地捕獲同樣的錯誤。
2. 服務（功能）測試：
針對服務接⼝進⾏測試。服務測試的難度在於服務會經常依賴⼀些其他服務。這個問題可以透過 Mock Server 解決。
3. 單元測試：
針對程式碼單元進⾏測試。我們⼀般會編寫⼤量的單元測試（包括迴歸測試）儘量覆蓋所有程式碼。
三種測試從上到下實施的容易程度遞增，但是測試效果遞減。
端到端測試最費時費⼒，但是透過測試後我們對系統最有信⼼。單元測試最容易實施，效率也最⾼，但是測試後不能保證整個系統沒有問題。
03
雲原生的微服務架構-雲原生應用架構
綜上，我們可以感受到微服務架構與容器、Kubernetes、DevOps 等雲原⽣關鍵技術⾃然地⾛到了⼀起，構成了雲原⽣應⽤架構的雛形。
雲原⽣應⽤架構具有下述特點：
1. 平臺化：
利⽤雲作為⼀個平臺，為微服務架構進⾏更多的賦能。
2. 標準化：
微服務本身的部署、運維，微服務之間與其它服務之間的通訊都能做到標準化，讓服務與服務之間的互聯互通變得更容易，服務能夠跨到不同的平臺上，做到⼀次編寫、⼀次定義、多處運⾏。
3. 輕量化：
讓研發⼈員關⼼核⼼業務程式碼、業務邏輯的研發，⽽不是複雜的微服務治理相關的邏輯研發。
4. 產品化：
希望能構建微服務相關的產品，以產品化的⽅式⽀持⼤家使⽤微服務架構，讓它變得更好⽤、更易⽤。
