一種基于Kubernetes的輕量級PaaS微服務框架
2024-04-14 02:12:21崔華樓奕華狄坤王海
現代信息科技 2024年2期
崔華 樓奕華 狄坤 王海
DOI：10.19850/j.cnki.2096-4706.2024.02.016
收稿日期：2023-09-08
摘? 要：微服務框架主要有客戶端負載均衡和服務端負載均衡兩類設計模式。文章提出一種基于Kubernetes的輕量級PaaS微服務框架，框架采用服務端負載均衡模式，設計了自定義的ServiceRoute對象來描述服務路由需求，以ServiceRoute對象的變化來增刪服務訪問點，基于對服務訪問點的DNS名稱解析實現服務尋址，采用經LUA擴展的HAProxy實現服務路由和服務治理。框架采用標準的HTTP協議，架構簡單清晰、組件實施方便、對應用無侵入，測試結果表明，該微服務框架工作穩定、性能良好，可為受限環境下部署微服務系統提供一種合適的解決方案。
關鍵詞：微服務；PaaS；Kubernetes；負載均衡；服務尋址；服務治理
中圖分類號：TP311? 文獻標識碼：A? 文章編號：2096-4706（2024）02-0070-06
A Lightweight PaaS Microservice Framework Based on Kubernetes
CUI Hua1， LOU Yihua1，2， DI Kun1，2， WANG Hai1，2
（1.Travelsky Technology Co.， Ltd.， Beijing? 101318， China;
2.Beijing Civil Aviation Bigdata Engineering Research Center， Beijing? 101318， China）
Abstract： There are two main design patterns for microservices frameworks： client-side load balancing and server-side load balancing. This paper proposes a lightweight PaaS microservice framework based on Kubernetes. The framework adopts a server-side load balancing mode， designs a custom ServiceRoute object to describe service routing requirements， adds or removes service access points based on changes in the ServiceRoute object， implements service addressing based on DNS name resolution of service access points， and implements service routing and governance using LUA extended HAProxy. The framework adopts the standard HTTP protocol， with a simple and clear architecture， convenient component implementation， and non-invasive application. Test results show that the microservices framework works stably and performs well， providing a suitable solution for deploying microservices systems in restricted environments.
Keywords： microservice; PaaS; Kubernetes; load balance; service addressing; service governance
0? 引? 言
傳統的業務系統通常為單架構，然而隨著業務增長引發的可擴展性需求逐漸緊迫，單體應用的局限性愈發明顯，因此近年來業務系統逐步向微服務模式進行轉變。和單體架構不同，微服務架構是由一系列職責單一的細粒度服務構成的分布式網絡，服務間通過微服務框架的路由機制進行通信。
主流的微服務框架通常有兩類設計模式[1]：一類是以SpringCloud [2]、Istio [3]為代表的主流微服務框架所采用的客戶端負載均衡模式，即服務網格[4]，在這種模式下每個微服務都有一個開放的端口，請求方通過構建服務名和端口的映射關系表可以直接向微服務對應的實例發送請求；另一類則是服務端負載均衡模式[5]，在這種模式下，請求方并不直接與微服務的實例通信，而是先將請求發送給統一的微服務路由組件，再由該組件負責向實際的微服務實例轉發請求。
一般而言，客戶端負載均衡模式由于采用了服務間直接通信的方式，具有跳數少、故障點少的優勢，但通常要求需要使用方進行代碼級適配；而服務端負載均衡模式由于采用了增加路由節點轉發請求的模式，一般不需要使用方進行特殊適配，但增長了調用鏈路、增加了故障點。兩類微服務設計模式雖各有優劣，但隨著系統復雜度的提升，尤其是微服務數量的增長，在客戶端負載均衡模式下所有請求方都會面臨著維護大量微服務配置與映射關系的壓力。為此，本文提出了一種采用服務端負載均衡模式的基于Kubernetes[6]的輕量級PaaS微服務框架，采用基于Kubernetes原生名字解析[7]的服務尋址機制和基于HAProxy[8]的服務路由機制，可滿足受限環境下客戶端無修改接入微服務框架的需求。
1 系統設計
1.1? 系統設計方案與組成
本文提出的基于Kubernetes的輕量級PaaS微服務框架，所有的組件都運行于同一個Kubernetes集群中，其整體的邏輯架構如圖1所示。
系統具體包含如下組件：
API Server：負責管理微服務框架在Kubernetes中注冊的ServiceRoute自定義資源對象，具體實現時既可以采用自定義擴展APIServer的方式，也可以將ServiceRoute對象作為CustomResourceDefinition注冊到集群中，由Kubernetes原生的APIServer承擔此功能；
服務路由組件：負責根據配置好的策略將調用方發起的服務調用請求轉發給相應服務版本的某個實例Pod，在服務路由組件的每個實例中，都會運行一個負責本實例策略配置更新的主進程和一個負責請求轉發的HAProxy進程。
控制組件：負責根據ServiceRoute對象的定義，在集群中創建/修改/刪除與此對象關聯的Kubernetes原生的Service對象。
與Kubernetes原生的服務路由機制[9]相比，由于Kubernetes原生的服務路由機制是通過直接訪問的（Service IP， Service Port）并依賴NAT[10]技術實現（Service IP， Service Port） -> （Pod IP， PodPort）的映射，故服務調用僅能實現簡單的4層負載均衡。而本文提出的方案由于增加了HAProxy作為服務路由組件，可在實現4層負載均衡的基礎上進一步做到7層負載均衡及更多的服務治理能力（如熔斷、多版本灰度等）。
1.2? 實現原理
1.2.1? 服務尋址原理
在本文所述的微服務框架中，每一個服務的不同版本都有一個對應的Service對象存在于Kubernetes集群中。為了能夠使用統一的訪問點訪問服務，并支持通過自定義的規則進行版本選擇和服務治理，微服務框架使用了自定義的ServiceRoute資源對象用于保存這些規則。微服務框架的控制組件會采用List & Watch機制跟蹤監視集群中所有ServiceRoute資源對象的變化。在一個ServiceRoute資源對象創建后，控制組件就會根據此ServiceRoute資源對象的描述，在指定的Namespace中創建一個與該資源對象同名的、用作服務訪問入口點的Service對象。該Service對象的類型為ExternalName，其指向的是一個位于特定Namespace中的Service對象，該Service對象代表了一個服務于本Namespace的服務路由組件。
當調用方通過目標服務的服務名發起HTTP調用請求時，首先需要對服務名進行地址解析，微服務框架通過在合適的名稱空間中創建與服務名同名的別名服務方式，巧妙地將對服務名的域名解析最終轉換成為對某個服務路由組件IP地址的解析。一次具體的服務尋址流程如圖2所示。
由于在服務尋址的過程中，服務名的DNS解析需要交由Kubernetes集群來執行，因此其命名規則對尋址結果會產生影響。理論上說，在執行服務調用時，調用方可以在<服務名>和<服務名>.
1.2.2? 服務路由原理
調用方在獲取到服務路由組件的IP地址后，就可以構造HTTP請求發送到該IP地址。由于該IP地址為Kubernetes中的ServiceIP，因此該請求會經過集群節點上的IPTables的NAT映射后轉換為服務路由組件的某個實例Pod的IP，并由操作系統路由于對應的Pod中。在請求在到達Pod后，該請求會進入已在Pod中運行且偵聽了當前端口的HAProxy進程中，由HAProxy根據灰度配置及請求信息為請求選擇一個合適的目標服務版本（HAProxy的配置由服務路由組件的主進程偵聽其所負責的Namespace中所有ServiceRoute對象的變更后動態生成并更新），并經負載均衡策略將該請求最終轉發給該具體版本的某個Pod，這一過程的實例如圖3所示。
1.2.3? 服務治理原理
由于微服務框架引入了HAProxy作為服務路由的轉發核心，因此服務路由組件可充分利用HAProxy的能力實現對服務的7層治理，包括但不限于：
多版本治理：在由Service Router生成的HAProxy配置中，每個服務的具體版本實例對應于HAProxy配置的一個后端，因此某一個特定的HTTP訪問點可能會對應一個后端（單版本情形）或多個后端（多版本情形），在后一種情況下，微服務框架通過嵌入在HAProxy配置文件中的LUA腳本解析每一個HTTP請求頭，并根據請求頭中的字段或者規定的百分比為該請求選擇一個后端。如果找不到合適的后端用于處理，則會將請求路由到一個特定的后端，該后端會直接向客戶端返回錯誤碼503。
熔斷治理：在微服務框架中，可以為服務的每一個版本實例都配置熔斷規則，指定在什么樣的條件下對該版本實例的訪問會被拒絕。熔斷的實現是通過在HAProxy的后端中通過LUA腳本增加了一組統計規則，當一定時間窗口內的統計結果符合預先配置的熔斷閾值時，后續一段時間內所有路由到該后端的請求都會被直接拒絕而不轉發。
訪問授權治理：微服務框架允許為每個可被調用的服務設置訪問授權規則，并要求每個調用請求中攜帶一個特定的HTTP請求頭，其中包含一串可以在容器中獲得的、用于標識調用方身份的隨機串碼。在該請求到達HAProxy時，其中的LUA腳本會將該串碼與預先生成的黑白名單列表進行匹配，并阻止那些根據規則不得發起調用的請求。
基于HAProxy實現服務治理的原理如圖4所示，其核心在于通過在HAProxy的配置文件置入包含了治理規則的LUA腳本，使這些LUA腳本在Backend選擇、Server選擇等HAProxy請求轉發過程的重要節點中得到執行，從而達到根據請求特征實現服務治理的目的。
1.3? 實施方式
本文提出的微服務框架實施方式包括：制定一個可用于描述服務路由規則的ServiceRoute資源對象，提供一個可管理該資源對象的APIServer（可選），實現一個可偵聽該資源對象變化并制作相應動作的控制器，為每一個需要加入微服務框架的Namespace部署一組服務路由器。
ServiceRoute資源對象的定義如下：
apiVersion： paas.io/v1
kind： ServiceRoute
metadata：
name： <名字，必須>
namespace： <命名空間（項目名），必須>
spec：
rule：
type： <灰度策略，必須，可在“Percentage”
“Header”中選擇，也可置為空字符串（無策略）>
header： <如果灰度策略為“Header”，此處必填，表示需要對請求頭中哪個字段的值執行正則匹配；否則可以省略>
prefer： <在策略不匹配時的優選版本>
global：
acl：
entries：
- name：
namespace： <如果 SA/Svc 與 svcroute 不在同一命名空間，此處需要寫；否則可以不寫>
- name：
namespace： <如果 SA/Svc 與 svcroute 不在同一命名空間，此處需要寫；否則可以不寫>
defaultAllow：
to：
- kind： Service
name： <服務名1，必須>
balance：
rule： <整數或字符串，可選：當采用百分比策略時，這里可以設置為整數或百分數；當采用Header正則策略時，這里設置用于匹配的正則表達式>
breaker：（此項可選，如果 threshold大于0，則啟用基于錯誤統計的熔斷）
threshold： <整數>
window： <整數>
breakTime： <整數>
connLimit： <整數，如果 connLimit 大于 0，則啟用基于最大連接數的熔斷>
port： （此項可選，如果服務對外暴露了多個端口，這里只選擇其中一個端口進行導出）
targetPort： <端口，類似于“80-tcp”，參見Route對象的port字段>
由于目前的Kubernetes已經支持了功能較為完備的CRD，故實施此微服務框架時已不必采用獨立的APIServer，而只需要將ServiceRoute資源對象注冊為CRD即可。
控制器則可使用任意能夠訪問Kubernetes API的語言實現，并將其作為一個普通的Pod部署于集群當中即可。
服務路由器原則上應當按Namespace實施部署以實現不同Namespace間的隔離，同時額外為全局命名空間部署一組實例。一個服務路由器的Pod應當包括一個用任意能夠訪問Kubernetes API的語言實現的配置管理主進程和一個HAProxy進程。主進程負責偵聽ServiceRoute的變化并據此生成HAProxy所需的haproxy.cfg文件，然后對HAProxy實施熱重啟以生效新的配置。
2? 系統驗證
本節基于上述方案進行了系統功能和性能的測試與驗證，測試驗證環境為一組由3臺虛擬機作為master節點和3臺物理機作為node節點組成的Kubernetes集群，Kubernetes的版本為Openshift Container Platform 3.11，虛擬機的主要配置如表1所示，物理機的主要配置如表2所示。
在功能測試階段，對系統進行了4類不同場景的功能測試與驗證，并針對異常恢復與長期穩定性兩個場景進行了非功能測試與驗證，涉及測試用例100余個，整個測試歷經3天共計26萬余次請求調用，系統功能正常。圖5展示了功能測試中一個組合場景的測試結果：在該場景中涉及了①在相同Namespace中通過svc2級聯調用svc11、②在相同Namespace中直接調用svc11、③跨Namespace調用svc11和④跨Namespace調用svc21四個場景，其中svc21部署了a和b兩個版本且按1：1的比例分流、svc11部署了一個d版本，每次調用均會返回最終進入的服務實例名。從圖5的結果可以看出，框架在四種場景下均可正常路由至正確的服務實例，其中場景④的返回結果也體現了1：1分流的特征。
此外，測試驗證中還針對常見的路由場景進行了性能測試，主要測試了在使用不同數量的服務路由器實例數的條件下用相同的10 KB報文調用同一服務的性能差異，測試結果如圖6所示。可以看到，當服務路由器實例數增加時，TPS的增長也近似于線性，結果顯示系統具備較好的水平擴展能力。
3? 結? 論
本文提出了一種基于Kubernetes的輕量級PaaS微服務框架。該微服務框架采用了服務端負載均衡模式，以注冊自定義資源對象控制Kubernetes中服務訪問入口點的方式，充分利用了Kubernetes原生的DNS解析能力。微服務框架將基于DNS的服務尋址和基于HAProxy轉發的服務路由相結合，在保持對應用零侵入的前提下實現了對負載均衡與服務治理能力的有效組合，架構簡單清晰，組件實施方便，經測試證明該微服務框架工作穩定、性能良好，可為受限環境下部署的微服務系統提供一種輕量級、非侵入、高兼容的微服務框架解決方案。
參考文獻：
[1] RABIU S，YONG CH，MOHAMAD SMS. A Cloud-Based Container Microservices： A Review on Load-Balancing and Auto-Scaling Issues [J]. A Cloud-Based Container Microservices： A Review on Load-Balancing and Auto-Scaling Issues， 2022（3）： 2， 80-92.
[2] COSMINA I. Pivotal Certified Professional Spring Developer Exam [M]. [S.I.]：Apress，2017.
[3] SHARMA R， SINGH A .Getting Started with Istio Service Mesh [M].[S.I.]：Apress，2020.
[4] LI W B，LEMIEUX Y，GAO J. Service Mesh： Challenges， State of the Art， and Future Research Opportunities [C]. 2019 IEEE International Conference on Service-Oriented System Engineering （SOSE）.San Francisco：IEEE，2019：122-1225.
[5] ZHENG B P，YIN J W，PANG S Y，ZHENG T，et al. A Zone Routing Algorithm for Service Network [C]. 2020 International Conference on Service Science.Xining：IEEE， 123-128.
[6] CARRI?N C. Kubernetes scheduling：Taxonomy， ongoing issues and challenges [J]. ACM Computing Surveys， 2022，55（7）：1-37.
[7] ERDENEBAT B，BUD B，KOZSIK T. Challenges in service discovery for microservices deployed in a Kubernetes cluster – a case study [J]. Infocommunications Journal，2023：69-75.
[8] PRASETIJO A B，WIDIANTO E D， HIDAYATULLAH E T. Performance comparisons of web server load balancing algorithms on HAProxy and Heartbeat [C]//2016 3rd International Conference on Information Technology， Computer，and Electrical Engineering（ICITACEE）.Semarang：IEEE， 2016：393-396.
[9] NGUYEN N，KIM T. Toward Highly Scalable Load Balancing in Kubernetes Clusters [J]. IEEE Communications Magazine， 2020，58（7）： 78-83.
[10] KHATOUNI A S，ZHANG L，AZIZ K，et al. Exploring NAT Detection and Host Identification Using Machine Learning [C]//2019 15th International Conference on Network and Service Management （CNSM）. Halifax：IEEE， 2019：1-8.
作者簡介：崔華（1977—），男，漢族，湖北宜昌人，高級工程師，碩士，主要研究方向：數據庫、中間件、云計算分布式技術；樓奕華（1984—），男，漢族，浙江金華人，高級工程師，博士，研究方向：云計算、DevOps；狄坤（1981—），男，漢族，北京人，工程師，碩士，研究方向：云計算、DevOps；王海（1979—），男，漢族，河南新鄉人，高級工程師，碩士，研究方向：中間件、云計算分布式技術。
