K6：面向開發人員的現代負載測試工具
K6 是一個開源負載測試工具，可以輕松編寫、運行和分析性能測試。它建立在 Go 和 JavaScript 之上，它被設計為功能強大、可擴展且易于使用。k6 可用于測試各種應用程序，包括 Web
在2022年8月份 vivo 互聯網中間件團隊完成了互聯網在線業務的MQ引擎升級，從RabbitMQ 到 RocketMQ 的平滑升級替換。
在業務使用消息中間件的過程中，提出了開發測試環境項目多版本隔離的訴求。本文將介紹我們基于 RocketMQ 如何實現的多版本環境隔離。
在正式展開項目多版本實踐之前，先大致介紹下我們消息中間件平臺的主體架構。
由上圖可知，我們消息中間件平臺的核心組件 mq-meta、RabbitMQ-SDK、mq-proxy，以及RocketMQ集群。
主要負責平臺元數據管理，以及業務SDK啟動時的鑒權尋址操作。
業務進行topic申請時，會自動分配創建到兩個不同機房的broker上。
鑒權尋址時會根據業務接入Key找到所在 MQ 集群下的proxy節點列表，經過機房優先+分片選取+負載均衡等策略，下發業務對應的proxy節點列表。
目前業務使用的消息中間件SDK仍為原有自研的RabibitMQ SDK，通過AMQP協議收發消息。
與proxy之間的生產消費連接，遵循機房優先原則，同時亦可以人為指定優先機房策略。
消息網關組件，負責AMQP協議與RocketMQ Remoting協議之間的相互轉換，對于業務側目前僅開放了AMQP協議。
具備讀寫分離能力，可配置只代理生產、只代理消費、代理生產消費這三種角色。
與broker之間的生產消費，遵循機房優先原則。
機房優先的實現：
每個MQ集群會由多個機房的broker組成。
每個topic則至少會分配到兩個不同機房的broker上。實現業務消息發送與消費的機房級別的容災。
每個broker部署兩節點，采用主從架構部署，并基于zookeeper實現了一套自動主從切換的高可用機制。通過異步刷盤+同步雙寫來保證性能與消息的可靠性。
namesrv則為跨機房broker+mq-proxy之間的公共組件，為集群提供路由發現功能。
后端服務通常采用微服務架構，各服務之間的通信，通常是同步與異步兩種調用場景。其中同步是通過RPC調用完成，而異步則是通過MQ（RocketMQ）生產消費消息實現。
在多版本環境隔離中，同步調用場景，一些RPC框架都能有比較好的支持（如Dubbo的標簽路由）；但在異步調用場景，RocketMQ并不具備完整的版本隔離方案，需要通過組合一些功能自行實現。
最初消息中間件平臺支持的多版本環境隔離大致如下：
該方式主要存在如下兩個問題：
1、使用成本較高
2、環境維護成本較高
為解決上述問題，提升多版本開發測試過程中的研發效率，中間件團隊開始了RocketMQ多版本環境隔離方案的調研。
注釋：
1、物理隔離：即機器層面的隔離，MQ的物理隔離，則意味著使用完全不同的MQ物理集群。
2、資源邏輯隔離：屬于同一MQ物理集群，但采用不同的邏輯集群，業務側需關注不同邏輯集群下相應的topic和group資源配置。
3、基線版本：通常為當前線上環境的版本或者是當前的主開發版本，為穩定版本。
4、項目版本：即項目并行開發中的多版本，非基線版本。
5、消息回落：針對消費而言，若消費方沒有對應的項目版本，則會回落到基線版本來進行消費。
基于我們需解決的問題，并對實現成本與業務使用成本的綜合考量，我們僅考慮【基于消息維度的user-property】與【基于topic的messageQueue】這兩種方案。
又因在全鏈路的多版本環境隔離的需求中，業務使用的版本環境明確提出不做固定，故而我們最終選擇【基于消息維度的user-property】來作為我們多版本環境隔離的方案。
基于消息維度的user-property來實現項目多版本的隔離。
1. 鏈路分析
在多版本環境中，真實的業務鏈路可能如下，服務調用可能走同步RPC或異步MQ。
注釋：
1、業務請求中帶有流量標識，經過網關時，根據流量路由規則將流量染色為全鏈路染色標識v-traffic-lane。
2、流量標識為userId，流量路由規則為用戶路由到指定版本，圖中的鏈路情況：
3、在后續的整個鏈路中，都需要將請求按照流量染色標識v-traffic-lane正確路由到對應版本環境。
2. 染色標識傳遞
為了正確識別當前服務所在版本，以及流量中的染色標識進行全鏈路傳遞，需要做如下事情：
（1）啟動
其中v-traffic-lane則是服務被拉起時所在的版本環境標識（由CICD提供），這樣proxy就能知道這個客戶端連接屬于哪個版本。
（2）消息的發送與接收
消息發送：mq-proxy將AMQP消息轉化為RocketMQ消息時，將染色標識添加到RocketMQ消息的user-property中。
消息接收：mq-proxy將RocketMQ消息轉化為AMQP消息時，將染色標識再添加到AMQP消息屬性中。
注釋：
上述紅色點位，可通過改動SDK進行染色標識的傳遞，但這樣就需要業務升級SDK了。這里我們是借助調用鏈agent來統一實現。
3.生產消費邏輯
（1）生產
邏輯比較簡單，對于存在版本tag的消息，只需要將版本標識作為一個消息屬性，存儲到當前topic中即可。
（2）消費
這里其實是有兩個問題：消費的多版本隔離、消息回落。
我們先看下消費的多版本隔離應該如何實現？
通過使用不同的消費group，采用基于user-property的消息過濾機制來實現。
① 版本tag傳遞
② 項目環境消費【消費屬于自己版本的消息】
③ 基線消費【消費全部基線版本消息+不在線多版本的消息】
我們再來看下消息回落又該如何實現？
1、消息回落是基線消費需要根據多版本的在線情況，來決定是否需要消費多版本的消息。
2、上面已提到基線消費從broker是拉取所有消息進行消費。
3、我們通過在基線消費內部維護一個在線多版本tag的集合，然后進行多版本消息的選擇性過濾來支持回落。
4、但這個在線多版本tag的集合，需要及時更新，才能更好的保證消息回落的準確性。
5、起初我們采用定時任務從broker拉取所有在線多版本tag的集合，每30s拉取一次，這樣消息回落就需要30s才能生效，準確性差。
6、后面我們想到用廣播通知機制，在多版本上下線時廣播通知到所有的基線消費實例，保證了消息回落的實效性與準確性。
7、完整的基線消費實例在線多版本tag集合更新機制如下：
（3）broker側的調整
這里主要是為了配合消費多版本的實現，對broker進行了一些擴展。
1、提供在線多版本group集合的擴展接口。用以返回當前group所有在線的多版本group集合。
2、增加broker側多版本消息過濾機制。因RocketMQ原生sql92過濾表達式，無法支持帶點的屬性字段過濾；而我們的版本標識（_vh_.v-traffic-lane）是存在的。
注釋：
1、routingKey過濾機制：為基于broker的消息過濾機制的擴展，可實現RabbitMQ中的routingKey表達式相同的消息路由功能。
2、多版本生產消費邏輯，都在mq-proxy與RocketMQ-broker側完成。業務也無需升級SDK。
4. 問題定位
在多版本隔離中，平臺對用戶屏蔽了復雜的實現細節，但用戶使用時，也需要能觀測到消息的生產消費情況，便于問題跟蹤定位。
這里我們主要提供了如下功能：
① 消息查詢：可觀測消息當前的版本標識，以及消息軌跡中的生產消費情況
② 消費group的在線節點：可看到消費節點當前的版本標識
本文概述了vivo互聯網中間件團隊，在開源RocketMQ基礎之上，如何落地【測試環境項目多版本隔離】的業務訴求。其中涵蓋了vivo消息中間件主體架構現狀、業內較流行的幾種方案對比，并對我們最終選擇方案在實現層面進行了細節性的分析。希望可以給業界提供一種基于proxy來實現多版本隔離特性的案例參考。
在實現過程中遇到的問題點歸結下來則是：
1. 流量染色標識在整個生產消費過程中如何傳遞？
2. 消費客戶端版本標識如何識別？
3. 消費的多版本隔離如何實現？
4. 消息回落如何實現？如何保證消息回落的實效性與準確性？
最后，我們實現的多版本隔離特性如下：
但仍存在如下不足：
多版本消費客戶端全部下線場景：若topic中仍存在一些已下線版本的消息沒有消費，則這部分消息不保證一定能被基線版本全部消費到。因基線版本與項目版本實際上采用的是不同的消費group，在broker的消費進度是不一致的，消息回落到基線消費之后，其消費位點可能已經超過項目版本消費group下線時的位點，中間存在偏差，會導致這部分消息再無法被基線版本消費到。
建議用于開發測試環境，因其無法保證多版本消息至少會被消費一次。
未來，消息中間件也會考慮線上環境全鏈路灰度場景的支持。
本文鏈接：http://m.www897cc.com/showinfo-26-80193-0.htmlvivo 消息中間件測試環境項目多版本實踐
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 記一次 .NET某防偽驗證系統崩潰分析
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號