無狀態(tài)微服務架構(gòu)及持續(xù)集成方法應用研究

摘要：隨著大型軟件系統(tǒng)的復雜度增加，傳統(tǒng)的單體架構(gòu)面臨水平擴展困難、存在性能瓶頸、故障隔離不佳以及技術(shù)棧統(tǒng)一限制等問題，此外，單體應用構(gòu)建和部署耗時較長，不利于頻繁更新，影響了軟件快速迭代與持續(xù)交付，微服務架構(gòu)能夠有效解決這些問題。文章面向一種云測試平臺，采用領(lǐng)域驅(qū)動設(shè)計思想，設(shè)計并實現(xiàn)了基于Redis緩存的無狀態(tài)微服務架構(gòu)，應用相應的持續(xù)集成方法對該架構(gòu)進行集成和部署，顯著提升了平臺的可擴展性、故障隔離能力和性能，支持多樣化的技術(shù)棧選擇并加速了軟件的持續(xù)快速迭代和交付，取得了良好效果。

關(guān)鍵詞：單體架構(gòu)；微服務架構(gòu)；無狀態(tài)；持續(xù)集成；云測試

中圖分類號：TP311" 文獻標志碼：A

0 引言

近年來，微服務架構(gòu)（Microservice Architecture，MSA）逐漸受到越來越多人的關(guān)注。作為一種架構(gòu)模式，微服務架構(gòu)提倡將單體架構(gòu)的應用劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。

云測試平臺系統(tǒng)是一種測試調(diào)度執(zhí)行系統(tǒng)。該系統(tǒng)采用單體架構(gòu)，作為測試平臺支撐大量項目使用，存在以下主要問題：（1）各模塊之間耦合性強，功能擴展不方便，須要整體修改升級；（2）故障隔離性不好，某個模塊的故障可能會導致系統(tǒng)整體不可用；（3）只能采用單一技術(shù)棧，無法發(fā)揮各語言在不同場景下的優(yōu)勢；（4）整體構(gòu)建和部署時間比較長，不利于按需頻繁部署。

為了解決以上問題，將云測試平臺系統(tǒng)從單體架構(gòu)演進到微服務架構(gòu)。與傳統(tǒng)的單體應用架構(gòu)相比，微服務架構(gòu)具有易于開發(fā)、技術(shù)棧多樣性、擴展性強、故障可隔離性、可獨立快速部署等各種優(yōu)勢，適合應用于大型復雜軟件系統(tǒng)^［1-2］。為了進一步提升系統(tǒng)面對大規(guī)模用戶時的性能，微服務采用無狀態(tài)設(shè)計支持多實例擴展。本文詳細介紹了云測試系統(tǒng)無狀態(tài)微服務架構(gòu)的設(shè)計、實現(xiàn)以及針對微服務架構(gòu)的持續(xù)集成和部署的具體方法，極大地提高了云測試平臺的可擴展性、故障隔離性和性能，加快了軟件持續(xù)快速迭代交付的能力。

1 單體應用架構(gòu)和微服務架構(gòu)

1.1 單體應用架構(gòu)

傳統(tǒng)的單體應用架構(gòu)是將應用程序所有功能部署為一個單一的文件或者同一個目錄下的文件合集，可以是JAR、WAR等格式，而且所有應用程序代碼都運行在相同的進程中。單體應用有如下優(yōu)點：（1）為人們所熟知。現(xiàn)有大部分工具、應用服務器、框架和腳本都是這種應用程序。（2）IDE友好。Eclipse、IntelliJ等開發(fā)環(huán)境都是針對開發(fā)、部署、調(diào)試單個應用而設(shè)計的。（3）便于共享。單個打包文件即包含所有功能，便于在團隊之間以及不同的部署階段共享。（4）易于測試和部署。單體應用一旦部署，所有服務或特性就都可以使用，沒有額外依賴，每項測試都可以在部署完成后立刻開始。

截至目前，單體應用已經(jīng)為人們提供了很好的服務，然而，不管如何模塊化，單體應用都存在以下問題：（1）模塊擴展性差。隨著系統(tǒng)的復雜性越來越高，在單體應用中擴展業(yè)務功能模塊越來越復雜。（2）故障隔離不佳。單體應用中一個模塊的嚴重故障會導致整個應用不可用。（3）性能提升難。單體應用很難通過水平擴展來提升關(guān)鍵模塊的性能。（4）技術(shù)棧統(tǒng)一限制。每個團隊成員都必須使用相同的開發(fā)語言、持久化存儲及消息系統(tǒng)，而且要使用類似工具，無法根據(jù)具體場景做出其他選擇。（5）單體應用構(gòu)建和部署耗時較長。單體應用可能較大，構(gòu)建和部署時間也相應較長，不利于頻繁部署，阻礙持續(xù)交付。

1.2 微服務架構(gòu)

隨著業(yè)務需求的快速發(fā)展變化，敏捷性、靈活性、可擴展性和性能需求不斷增長，迫切需要一種更加快速高效的軟件交付方式。微服務架構(gòu)就是一種可以滿足這種需求的軟件架構(gòu)模式，采用多個服務間互相協(xié)作的方式構(gòu)建應用，每個服務獨立運行在不同的進程中，服務與服務之間通過輕量級通信機制交互并且每個服務可以通過自動化方式獨立部署。

1.2.1 微服務架構(gòu)的特點

（1）領(lǐng)域驅(qū)動設(shè)計^［3］。應用程序功能分解通過DDD中明確定義的規(guī)則實現(xiàn)；每個團隊負責與一個領(lǐng)域或業(yè)務功能相關(guān)的全部開發(fā)。（2）單一職責。每個服務只負責該功能的一個單獨的小的部分，也是SOLID原則之一。（3）明確發(fā)布接口。每個服務都會發(fā)布一個定義明確的接口且保持不變；服務消費者只關(guān)心接口，而對于被消費的服務沒有任何運行依賴。（4）獨立部署、升級、擴展和替換。每個服務都可以單獨部署及重新部署而不影響整個系統(tǒng)，使得服務很容易升級擴展。（5）可以采用多種異構(gòu)語言。每個服務的實現(xiàn)細節(jié)與其他服務無關(guān)，使得服務之間能夠解耦，團隊可以針對每個服務選擇最合適的開發(fā)語言、持久化存儲、工具和方法。

1.2.2 微服務架構(gòu)的優(yōu)點

（1）每個服務只須做好一件事，更加專注和簡單，易于開發(fā)、理解、擴展和維護。（2）故障隔離好，一個服務出現(xiàn)問題不會影響整個應用。（3）性能水平擴展性好，可以通過對服務進行無狀態(tài)設(shè)計，多實例化水平擴展來提升性能。（4）服務可以根據(jù)不同的要求選擇合適的技術(shù)來做開發(fā)，不會受限于任何技術(shù)棧。（5）局部修改容易部署，有利于持續(xù)集成和持續(xù)交付^［4］。

2 基于微服務架構(gòu)的云測試平臺

云測試平臺的核心是一個測試調(diào)度執(zhí)行系統(tǒng)^［5-6］，對測試環(huán)境的物理資源和用例對環(huán)境的資源需求2部分進行抽象描述，通過匹配算法達到測試用例和具體執(zhí)行物理環(huán)境解耦的目的。測試人員提交測試任務，系統(tǒng)根據(jù)測試任務中測試用例的要求進行環(huán)境資源匹配，將用例各自分發(fā)調(diào)度到合適的測試環(huán)境并行執(zhí)行，匯總結(jié)果報告輸出。

2.1 單體架構(gòu)

云測試系統(tǒng)原來的架構(gòu)是經(jīng)典的MasterSlave方式，一臺Master服務器對應多臺Slave，每個Slave管理一套測試環(huán)境，如圖1所示。

該架構(gòu)是單體架構(gòu)，作為測試平臺支撐大量項目使用時存在以下問題：（1）用戶需求不斷增加，模塊間耦合性比較強，功能擴展起來不方便，而且需要整體修改升級；（2）故障隔離性不好，某個模塊的故障可能會導致系統(tǒng)整體不可用，不滿足穩(wěn)定性的要求；（3）資源匹配算法采用Python效率較高，但是整體系統(tǒng)采用Go語言，只能通過腳本調(diào)用的方式，一些團隊成員掌握其他技術(shù)棧卻無法投入開發(fā)，浪費資源。

2.2 微服務架構(gòu)

為解決以上問題，本文采用微服務架構(gòu)對原有云測試系統(tǒng)進行改造。微服務架構(gòu)采用DDD領(lǐng)域驅(qū)動設(shè)計的基本思想把單個應用程序根據(jù)領(lǐng)域業(yè)務分解為多個獨立的服務，服務之間通過輕量級消息通信，形成分布式網(wǎng)絡系統(tǒng)，服務間共同協(xié)作實現(xiàn)系統(tǒng)的功能。微服務架構(gòu)主要有以下優(yōu)點：（1）每個服務關(guān)注內(nèi)容比較少，接口清晰，容易實現(xiàn)高內(nèi)聚低耦合，功能擴展可以在服務內(nèi)增加或擴展新服務，非常方便；（2）各服務的故障相互隔離，易于實現(xiàn)高可用系統(tǒng)；（3）每個服務技術(shù)選型比較靈活，只要符合消息接口即可。

本文采用DDD領(lǐng)域驅(qū)動設(shè)計的思想，經(jīng)過對云測試系統(tǒng)領(lǐng)域業(yè)務的分析，將原系統(tǒng)按領(lǐng)域分解為以下幾個主要的微服務：任務管理、用例管理、調(diào)度、匹配、環(huán)境管理、配置管理、產(chǎn)品管理、執(zhí)行Slave等，通過它們的交互協(xié)作來對外提供價值。微服務架構(gòu)如圖2所示。

其中，對提供最核心的測試調(diào)度執(zhí)行^［7］，各微服務間的流程時序如圖3所示。

各微服務間具體交互過程如下：

（1）Job服務向schedule服務發(fā)送activeJob請求；

（2）Schedule收到activeJob后，通知report服務，開始創(chuàng)建文件夾，準備接收執(zhí)行報告文件；

（3）Schedule服務通知Match服務進行用例環(huán)境匹配；

（4）Match服務接收到請求后，進行匹配并返回結(jié)果；

（5）Slave空閑時向Schedule服務請求用例；

（6）Schedule服務向Slave指派匹配的用例信息請求執(zhí)行；

（7）Slave執(zhí)行完用例后向Report服務上傳用例的報告文件；

（8）Report接收Slave傳過來的用例報告文件，將這些文件放到對應目錄下；

（9）Slave通知Schedule服務上傳報告到Report服務完成；

（10）Schedule服務通知Report合并用例報告；

（11）Schedule服務判斷Job服務中所有用例執(zhí)行完畢，通知Report生成整個任務測試報告；

（12）Schedule服務通知Job服務完成整個任務測試。

2.3 無狀態(tài)微服務設(shè)計

隨著云測試日活測試任務數(shù)和用例數(shù)的增大，調(diào)度服務越來越成為瓶頸，主要有以下方面：

（1）調(diào)度服務已經(jīng)支撐不了更大并行的測試任務調(diào)度執(zhí)行，當任務達到1000時，就會有15%左右任務調(diào)度失敗，導致任務執(zhí)行失敗，已經(jīng)嚴重不能滿足用戶增長的需要。

（2）隨著壓力的增大，某些異常情況可能導致調(diào)度服務退出，在服務被重新拉起的時間內(nèi)，系統(tǒng)核心調(diào)度不可用，云測試平臺的高可用性受到嚴峻挑戰(zhàn)。

基于上述2個主要原因，迫切須要采取相應的方法提高云測試調(diào)度服務的性能和高可用性。在對調(diào)度服務自身性能優(yōu)化和異常保護后，進一步將調(diào)度服務水平擴展。云測試采用了微服務架構(gòu)，調(diào)度服務是獨立的服務，只須將調(diào)度服務多實例化，負載均衡，一方面可以提升調(diào)度服務的性能，支撐更多的測試任務調(diào)度執(zhí)行，另一方面提升調(diào)度服務的高可用性，當一個服務異常退出后，其他服務會繼續(xù)提供服務，不至于導致調(diào)度執(zhí)行失敗。

調(diào)度服務多實例化水平擴展的關(guān)鍵是對調(diào)度服務無狀況化設(shè)計，將調(diào)度服務的狀態(tài)數(shù)據(jù)從服務中獨立出來共享存儲，如圖4所示。

在調(diào)度服務多實例架構(gòu)中，無論哪個調(diào)度服務收到其他業(yè)務服務的消息，如果需要讀寫狀態(tài)，均不訪問自己的服務狀態(tài)，而是訪問共享存儲中的狀態(tài)，這樣有以下優(yōu)勢：

（1）當業(yè)務需要請求調(diào)度服務處理時，可以根據(jù)負載均衡原則發(fā)給任何調(diào)度服務實例，而不須在一次業(yè)務會話中記住特定的調(diào)度服務實例，但如果調(diào)度服務存儲狀態(tài)數(shù)據(jù)，則必須保證一次業(yè)務會話中訪問相同的調(diào)度服務實例，這樣會增加系統(tǒng)的復雜度。

（2）當某個調(diào)度服務實例異常退出后，后續(xù)完全可以由其他調(diào)度服務實例完成相應的處理，對業(yè)務無任何影響。

為此，本文將調(diào)度中的主要狀態(tài)數(shù)據(jù)等待隊列移植到Redis中，以支持多個調(diào)度實例，如圖5所示。

當用戶提交測試任務執(zhí)行時，調(diào)度執(zhí)行過程如下：

（1）Job服務向調(diào)度服務請求激活測試任務，向調(diào)度實例Schd1發(fā)起；

（2）調(diào)度實例Schd1收到Active后，請求Matcher服務對用例進行預匹配；

（3）調(diào)度實例Schd1獲得預匹配結(jié)果后，將匹配用例的預匹配信息加入等待隊列并存儲到Redis中；

（4）某個Slave1空閑，向調(diào)度實例Schd1發(fā)送消息來獲取用例執(zhí)行，調(diào)度實例Schd1收到請求后，訪問Redis中等待隊列中的用例預匹配信息，找到匹配的用例；

（5）調(diào)度實例Schd1發(fā)送用例信息指派Slave1執(zhí)行；

（6）Slave1執(zhí)行完畢后根據(jù)負載情況向調(diào)度實例Schd2發(fā)送了用例執(zhí)行結(jié)果；

（7）調(diào)度實例Schd2獲得用例測試結(jié)果后，向Redis更新用例的執(zhí)行結(jié)果信息；

（8）如果Job中所有用例都執(zhí)行完成，則更新Job執(zhí)行狀態(tài)為完成；

（9）調(diào)度實例Schd2從Redis中獲取任務的執(zhí)行結(jié)果信息；

（10）調(diào)度實例Schd2將任務的執(zhí)行結(jié)果信息發(fā)送給Job服務。

從上面的流程可以看到，任何一個調(diào)度實例對所有任務數(shù)據(jù)可見，如某個Slave向調(diào)度實例Schd2上報用例執(zhí)行結(jié)果時，不會因為對應該Slave的任務是通過另一個調(diào)度實例Schd1激活的而無法處理。另外，某一個實例異常時，其他實例仍然可以繼續(xù)處理所有用例數(shù)據(jù)，僅對該異常實例正在處理中的數(shù)據(jù)有影響。

在上述流程中，等待隊列基于Go中的list實現(xiàn)，現(xiàn)在須要修改為在Redis中存儲（包括讀和寫），使用時須要現(xiàn)從Redis查詢，所有對任務、用例屬性的修改都要及時同步到Redis中，以便持久化。

3 微服務持續(xù)集成和部署

系統(tǒng)被分解為微服務架構(gòu)后，整個云測試系統(tǒng)的持續(xù)集成實施方式就要跟隨架構(gòu)而變。持續(xù)集成和部署的目的是協(xié)作高效開發(fā)，當代碼變動后盡快驗證并可一鍵式部署到生產(chǎn)環(huán)境，達到快速反饋的目的。具體實施時須要考慮微服務代碼庫和構(gòu)建部署流程2個方面。

3.1 微服務代碼庫

每個微服務放在一個獨立的代碼庫中，在Jenkins中，每個Job關(guān)注一個微服務所在的倉庫。如果某個微服務代碼有變動，則觸發(fā)相應的微服務Job運行構(gòu)建，生成本微服務的Docker鏡像^［8］。這種方式的好處是，微服務之間互不影響，可以對某個微服務進行單獨的功能測試，多個微服務之間可以并行實施。整個系統(tǒng)發(fā)布時，每個微服務可以對應不同的版本號，只須構(gòu)建有改動的微服務，保證所有微服務配合通過驗收測試用例即可，而不須要全部構(gòu)建。

云測試的多個微服務在GitLab中被分解為獨立的倉庫，每個倉庫中有對應的腳本，可以將本微服務制作成獨立的Docker鏡像。

3.2 微服務構(gòu)建部署流程

從開發(fā)人員本地驗證合入代碼到微服務Docker鏡像被部署到生產(chǎn)環(huán)境，須經(jīng)過以下步驟^［9-10］：

（1）本地在git分支上開發(fā)代碼，運行驗收用例通過；（2）合入相關(guān)微服務代碼至相應的GitLab倉庫并提交合并請求；（3）GitLab觸發(fā)對應Jenkins Job進行代碼編譯、鏡像構(gòu)建；（4）Jenkins上運行驗收測試用例，通過后推送到Docker私有倉庫；（5）運行Jenkins一鍵部署Job，調(diào)用部署腳本，將鏡像部署到私有云中。

云測試系統(tǒng)已經(jīng)基于Redis集群共享狀態(tài)實現(xiàn)了多實例的無狀態(tài)微服務滾動升級，因此，在替換鏡像過程中服務不會中斷，能夠做到不停服升級。

4 應用實例

4.1 系統(tǒng)實現(xiàn)

4.1.1 微服務架構(gòu)實現(xiàn)

根據(jù)業(yè)務領(lǐng)域，微服務架構(gòu)具體拆分為如下11項微服務，如：任務調(diào)度Scheduler、資源匹配Matcher、產(chǎn)品管理Product、任務管理Job、用例管理Testcase，版本管理Version等。每個服務獨立運行部署，按需單獨配置DB，服務之間基于RESTful接口通信，如圖6所示，箭頭表示服務間有依賴關(guān)系。

4.1.2 無狀態(tài)調(diào)度微服務實現(xiàn)

Redis是一個開源的高性能鍵值對數(shù)據(jù)庫，通過提供不同的鍵值數(shù)據(jù)類型來滿足不同場景下的存儲需求，借助高層級的接口可以勝任如存儲、隊列系統(tǒng)以及緩存系統(tǒng)等不同角色。Redis的所有內(nèi)容都存儲在內(nèi)存中，因此，讀寫速度較其他基于硬盤的數(shù)據(jù)庫有明顯的優(yōu)勢。將數(shù)據(jù)存在內(nèi)存中也有問題，比如當程序退出后內(nèi)存中的數(shù)據(jù)將會丟失，因此，Redis提供了對持久化的支持，即可以將內(nèi)存中的數(shù)據(jù)異步寫入硬盤，同時不影響繼續(xù)提供服務。Redis是單線程模式，而Memcache支持多線程，然而Redis在大部分情況下性能不會成為其瓶頸。如果需要復雜的數(shù)據(jù)類型或持久化等功能時，Redis將會成為Memcache很好的代替品。

Redis采用內(nèi)存存儲，讀寫速度快，提供持久化支持，單線程模式共享不會沖突，且在大部分情況下性能不會成為瓶頸，因此，采用Redis作為服務狀態(tài)共享存儲，將調(diào)度服務的核心狀態(tài)數(shù)據(jù)“用例等待調(diào)度隊列”放到Redis中并對調(diào)度服務讀寫狀態(tài)的處理做相應的修改。

云測試調(diào)度服務多實例化的關(guān)鍵是采用Redis存儲狀態(tài)數(shù)據(jù)，因此，Redis的高可用性就成為關(guān)鍵。Redis高可用有2種架構(gòu)模式：集群和哨兵模式。本文采用了哨兵模式。Redis 的 Sentinel 系統(tǒng)用于管理多個 Redis 服務器，Sentinel 會不斷地檢查主服務器和從服務器是否運作正常。當被監(jiān)控的某個 Redis 服務器出現(xiàn)問題時，Sentinel 可以通過 API 向管理員或者其他應用程序發(fā)送通知。當一個主服務器不能正常工作時，Sentinel 會開始一次自動故障遷移操作，將失效主服務器的其中一個從服務器升級為新的主服務器，讓失效主服務器的其他從服務器改為復制新的主服務器；當客戶端試圖連接失效的主服務器時，集群也會向客戶端返回新主服務器的地址，使得集群可以使用新主服務器代替失效服務器，從而極大地提高了高可用性。

4.1.3 微服務持續(xù)集成實現(xiàn)

為了實現(xiàn)以微服務為單位的快速持續(xù)集成和部署發(fā)布，本文主要實現(xiàn)了以下步驟腳本：

（1）本地編譯代碼、制作鏡像的腳本。

①build_me.sh

該腳本的作用是編譯微服務代碼，檢驗其是否可以編譯通過，生成可執(zhí)行文件。

②make_image.sh

該腳本的作用是制作某個微服務的Docker鏡像。首先從私有倉庫下載Docker鏡像，該鏡像預先安裝了Go語言環(huán)境。接著把微服務的目錄掛載到Go鏡像中使用build_me.sh腳本進行編譯。這樣做的好處在于，在其他機器上（比如CI機器）就不須再安裝Go語言環(huán)境。最后制作完整的Docker鏡像。

（2）合入相關(guān)微服務代碼至相應的GitLab倉庫并提交合并請求。

開發(fā)人員提交合并請求后，GitLab會觸發(fā)對應的Jenkins Job進行代碼編譯、鏡像構(gòu)建。其中Jenkins Job用到的腳本有：

①make_image.sh

該腳本和本地校驗腳本是同一個腳本，Jenkins Job中引用它是為了在CI機器上生成鏡像。

②run_ut.sh

該腳本可選，可以在這里進行該微服務的單元或功能測試。

（3）運行驗收測試用例，通過后推送到Docker私有倉庫，完成生產(chǎn)環(huán)境部署。

①start_at.sh

該腳本的作用是啟動所有微服務鏡像，包括仿真Slave鏡像和驗收用例鏡像。讓驗收用例鏡像中的Robot向云測試系統(tǒng)的Web發(fā)送請求的方式對系統(tǒng)進行驗收測試。

②push.sh

如果驗收測試通過，可以通過此腳本將鏡像推送到Docker私有倉庫。

③depoy.sh

運行Jenkins一鍵部署Job，將生產(chǎn)環(huán)境鏡像替換為新版本。

4.2 效果評價

4.2.1 微服務架構(gòu)實現(xiàn)效果

采用無狀態(tài)微服務架構(gòu)實現(xiàn)云測試平臺系統(tǒng)后，取得了以下明顯效果：

（1）系統(tǒng)的可擴展性得到顯著增強，可以根據(jù)各種產(chǎn)品的測試需求增加相應的服務實現(xiàn)，比如針對不同的測試環(huán)境模型提供不同的資源匹配服務（MatcherXXX），針對不同的測試框架（如Robot和其他自研測試框架）開發(fā)不同的測試用例解析服務（TestcaseXXX）等。

（2）由于各個微服務都是在獨立的進程中運行，故障隔離性好，例如用例管理TestCase服務發(fā)生嚴重異常退出，僅僅無法刷新用例，但對任務管理Job服務和任務調(diào)度Scheduler服務無任何影響，因此，測試調(diào)度執(zhí)行仍然能夠正常進行。

（3）各個服務采用的編程技術(shù)也可以不同，只要能滿足RESTful通信接口即可。本系統(tǒng)中大多數(shù)業(yè)務模塊采用Go實現(xiàn)，資源匹配服務Matcher涉及算法設(shè)計，則采用Python開發(fā)。

4.2.2 無狀態(tài)微服務實現(xiàn)效果

云測試平臺調(diào)度服務完成多實例改造后，系統(tǒng)調(diào)度的性能和可用性均大幅提升，本文用32C 64G的機器進行性能測試，預置條件：單任務設(shè)置50個用例，分別部署1個調(diào)度服務，2個調(diào)度服務，3個調(diào)度服務進行測試，在測試沒有基本問題后，線上部署了3個調(diào)度服務實例提供正式服務，測試和線上驗證結(jié)果如下：

（1）隨著調(diào)度服務的擴容，系統(tǒng)支持的任務并行調(diào)度數(shù)也會明顯增長，如表1所示。

（2）系統(tǒng)通過長時間穩(wěn)定性測試，多實例同時出現(xiàn)異常退出服務的概率幾乎為0，經(jīng)過長時間驗證，未發(fā)生調(diào)度服務異常退出導致的系統(tǒng)調(diào)度不可用情況，保證了云測試平臺核心調(diào)度能力的高可用性。

（3）Redis采用高可用方案部署，發(fā)現(xiàn)曾經(jīng)出現(xiàn)過主Redis切換的情況，但是系統(tǒng)的Redis對調(diào)度服務仍然是可用的，未造成影響。

4.2.3 微服務持續(xù)集成實現(xiàn)效果

采用容器技術(shù)針對各個微服務進行持續(xù)集成和部署，極大地提高了云測試平臺持續(xù)快速迭代交付的能力。持續(xù)集成平均時間比原有時間下降了72%，集成頻率由原來的每天1次大幅度提升到平均12次左右，做到了按需集成。

5 結(jié)語

云測試平臺采用無狀態(tài)微服務架構(gòu)，具有高可擴展性、故障隔離性和高性能，選擇適合的技術(shù)棧，可快速響應用戶的需求。對各個微服務進行持續(xù)集成和部署，極大地提高了云測試平臺持續(xù)快速迭代交付的能力。隨著微服務架構(gòu)及持續(xù)集成技術(shù)的不斷深入應用，基于微服務的組裝式應用和相應的持續(xù)集成方法是值得進一步研究的方向，從而持續(xù)提升軟件系統(tǒng)的靈活性與敏捷性，提升研發(fā)效率和質(zhì)量，降低成本。

參考文獻

［1］洪華軍，吳建波，冷文浩．一種基于微服務架構(gòu)的業(yè)務系統(tǒng)設(shè)計與實現(xiàn)［J］.計算機與數(shù)字工程，2018（1）：149-154.

［2］張晶，黃小鋒．一種基于微服務的應用框架［J］.計算機系統(tǒng)應用，2016（9）：265-270.

［3］埃里克·埃文斯.領(lǐng)域驅(qū)動設(shè)計［M］.北京：人民郵電出版社，2010.

［4］楊宇，焦麗琴.基于微服務的企業(yè)應用設(shè)計與實現(xiàn)［J］.電子科學技術(shù)，2016（5）：623-625.

［5］李喬，柯棟梁，王小林.云測試研究現(xiàn)狀綜述［J］.計算機應用研究，2012（12）：4401-4406.

［6］李喬，鄭嘯.云計算研究現(xiàn)狀綜述［J］.計算機科學，2011（4）：32-37.

［7］左利云，曹志波.云計算中調(diào)度問題研究綜述［J］.計算機應用研究，2012（11）：4023-4027.

［8］SAM N.Building microservices［M］.California：O’Reilly Media，2014.

［9］林新黨，穆加艷.基于Jenkins的持續(xù)集成系統(tǒng)研究［J］.雷達與對抗，2014（1）：58-61.

［10］陳剛，羌鈴鈴.軟件項目開發(fā)中的持續(xù)集成研究［J］.項目管理技術(shù)，2011（12）：103-106.

（編輯 王雪芬）

Research on the application of stateless microservice architecture and continuous integration methods

JU" Weigang， WANG" Jia

（ZTE Corporation， Nanjing 210012， China）

Abstract： "As the complexity of largescale software systems increases， traditional monolithic architectures face challenges such as difficulty in horizontal scaling， performance bottlenecks， poor fault isolation， and limitations due to a unified technology stack. Additionally， the lengthy build and deployment processes of monolithic applications are not conducive to frequent updates， which hinders rapid iteration and continuous delivery of software. Microservice architecture can effectively address these issues. This paper focuses on a cloud testing platform and adopts the principles of domaindriven design to research， design， and implement a stateless microservice architecture based on Redis caching. It also applies appropriate continuous integration methods for the integration and deployment of this architecture. These improvements have significantly enhanced the scalability， fault isolation， and performance of the platform， supported a diversified selection of technology stacks， and accelerated the continuous and rapid iteration and delivery of software， achieving excellent results.

Key words： singleunit architecture; microservice architecture; stateless; continuous integration; cloud test