雲原生時代下微服務架構演進之路 (9)

透過本篇文章您可以瞭解到以下內容：

Spring Cloud簡介
Spring Cloud的前世今生
Spring Cloud & Kubernetes最佳實踐
總結

Spring Cloud簡介

談到Spring Cloud相信大家都不會陌生，在本文的開篇，首先讓我們來看看關於Spring Cloud的官方介紹（部分截取）：

英文部分：

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems

(e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).

透過介紹我們可以看出，Spring Cloud主要特點是提供了一系列開箱即用的元件，這些元件可以幫助開發人員快速解決微服務架構系統建構過程中所遇到的問題。

如上圖所示，在分散式微服務架構系統下，我們面臨需要解決的問題可能包括如下幾大方面：

註冊中心是怎樣建構的？
監控的解決方案又是什麼？
閘道的技術選型？
微服務級別的高可用？
微服務之間的負載均衡？
配置中心的解決方案？

那麼對於上述提出的問題，Spring Cloud給出的解決方案又是什麼呢？接下來讓我們深入瞭解下Spring Cloud包含哪些元件，這些元件的又是幹什麼的？以及哪些元件又做了替換和升級。

Spring Cloud的前世今生

眾所周知，傳統意義上的Spring Cloud是集成了Netflix的一些元件，透過Spring的代碼黏合，使得開發人員透過簡單的註解方式以及yaml的配置就可以快速建構出一整套微服務架構的解決方案。這裡面包括閘道、註冊中心、配置中心、監控、應用層面的高可用（熔斷、降級、限流），負載均衡等。如下圖所示：

Zuul

這裡談到的Zuul指的是Zuul1.0，底層原理本質是Servlet。透過前置、後置的Filter完成在路由過程中的額外操作，比如鑒權、統一日誌處理等功能。同時也支援Groovy語言，透過定時任務掃描在指定位置的Groovy檔，完成動態載入的功能。值得注意的是後續Netflix開發出了Zuul2.0是基於非阻塞模型的，Spring Cloud並沒有進行集成，而是採用大家所熟知的 Spring Cloud Gateway作為閘道首選的解決方案。

Eureka

作為註冊中心，在CAP理論模型中屬於AP。分為Eureka Server以及Eureka Client兩部分，對於Eureka Server而言，提供了一些了的 Rest API從而完成服務註冊、心跳保持、驅除服務實例等功能，同時本身包含多級緩存，以及包括自我保護機制等。

Ribbon

相比服務端負載均衡，Ribbon是用戶端負載均衡的實現。通常結合OpenFeign使用，本身提供了多種用戶端負載均衡的策略，同時也可以自定義負載均衡的策略。目前Ribbon項目處於maintenance狀態。

Hystrix

本質是透過SDK的方式實現熔斷、降級、限流等功能。透過yaml方式可以進行配置，另一方面也可以透過編寫Java代碼方式實現。需要值得注意的是，目前Hystrix項目處於maintenance狀態。

OpenFeign

簡化HTTP調用，相比傳統代碼編寫完成一次HTTP調用，OpenFeign大大簡化了代碼的複雜度。同時可以結合Ribbon以及Hystrix完成一次請求過程中涉及到的負載均衡以及熔斷、降級、限流操作。 OpenFeign底層支援三種方式，分別是URLconnection、HttpClient以及OK Http。

Config Server

統一配置中心，分為Config Server以及Config Client兩部分，可以結合訊息元件完成每一個微服務的配置更新。

Zipkin

監控解決方案，無論是同步還是異步調用可以展現。主要目的是完成整個微服務系統中監控模組，包括微服務之間調用關係、耗時、問題定位等功能。

說到這裡，相信大家已經發現了，傳統的Spring Cloud所集成的一些元件已經處於maintenance的狀態，例如（Hystrix、Ribbon 等）所以Spring Cloud在此基礎上，做了一些元件的升級工作，接下來會向大家做一一介紹：

Spring Cloud Gateway

閘道的解決方案，替換原有的Zuul1.0。相比Zuul1.0這種傳統Servlet方式，Spring Cloud Gateway採用非阻塞方式，基於Spring Boot2.0以及Spring Framework5。

Spring Cloud LoadBalancer

對於傳統Ribbon元件的升級和替換。同時增加對WebFlux的支援。

Spring Cloud Circuit breaker

對於傳統Hystrix元件的升級和替換，採用整合整合Resilience4j的方式完成熔斷、降級、限流等功能。

對於上面提到的三個元件的詳細資訊，可以參考以下連結：

透過上面的介紹可以瞭解到目前的Spring Cloud對原有的一些元件進行了升級替換。這裡原有的含義指的是集成Netflix的一些元件。

Spring Cloud & Kubernetes最佳實踐

我們知道Spring Cloud的本質是透過SDK的方式（引入SDK、並且透過簡單的註解和yaml的配置），幫助開發人員快速建構微服務架構中所必須的元素。那麼如果當Spring Cloud遇到上Kubernetes時又會發生什麼呢？

第一種方案

相對比較粗暴的方式，使用Spring Boot作為基石來開發每一個微服務，這裡面並不使用Spring Cloud任何元件，依託於Kubernetes的特性來建構微服務架構。比如註冊中心我們不採用Eureka（亦或者zookeeper、consul等）而是直接採用Kubernetes服務發現機制。對於負載均衡、熔斷降級限流等功能我們可以結合Service Mesh來實現。所以如果用一句話概括，那麼第一種方案就是： Spring Boot + Kubernetes + Service Mesh。

第二種方案

相比第一種解決方案，第二種的方式相對中和一些，我們可以對Spring Cloud的元件進行取捨，比如註冊中心的解決方案我們可以不使用Eureka而是採用Kubernetes的服務發現機制，對於閘道可以採用Spring Cloud Gateway，應用高可用層面我們可以採用Spring Cloud Circuit breaker。所以如果用一句話概括，那麼第二種方案就是： Spring Cloud（部分元件） + Kubernetes

第三種方案

對於第三種解決方案，我們可以使用全家桶似的Spring Cloud作為微服務開發的解決方案。也就是說可以理解為將所有Spring Cloud技術元件平移到Kubernetes之上。

總結

回顧全篇內容，整體包括以下內容：

首先在開篇我們簡單瞭解到了Spring Cloud。
其次對Spring Cloud包含元件的功能以及元件升級替換進行了詳細的介紹。
最後對Spring Cloud在Kubernetes上的最佳實踐給出了三種方案。

在下一章節中我們會繼續深入瞭解Spring Cloud對於訊息中間件的解決方案，Spring Cloud Stream。敬請期待！

參考連結：

作者簡介

雲原生時代下微服務架構演進之路 (9)

Comments