面向微服務(wù)軟件開發(fā)方法研究

張志國

（上海派遣人才有限公司 上海市 200070）

微服務(wù)是 SOA 架構(gòu)的一種變體，基于輕量級協(xié)議與細(xì)粒度服務(wù)進(jìn)行應(yīng)用程序構(gòu)造與軟件開發(fā)設(shè)計(jì)，可憑借其擴(kuò)展性優(yōu)勢進(jìn)行開放平臺的部署，實(shí)現(xiàn)降低成本、縮短開發(fā)周期的應(yīng)用效果。利用微服務(wù)的簡易架構(gòu)進(jìn)行開放平臺的設(shè)計(jì)與開發(fā)，能夠讓數(shù)據(jù)交流與傳輸效率更為高效，確保了信息傳送的高效性與開放性。

1 微服務(wù)架構(gòu)

微服務(wù)架構(gòu)十分輕便小巧，運(yùn)行模式十分便捷。每個(gè)微服務(wù)獨(dú)立運(yùn)行安放，各自發(fā)揮自身的功能。每個(gè)微服務(wù)單獨(dú)實(shí)現(xiàn)對應(yīng)的功能，該功能是由微服務(wù)進(jìn)行封鎖包裝。技術(shù)路線選擇各異，進(jìn)行獨(dú)自更新。面對容量十分龐大，同一時(shí)間內(nèi)執(zhí)行多個(gè)程序的情況之下，此時(shí)微服務(wù)是不二選擇。面對開發(fā)大型的系統(tǒng)時(shí)，并且有著十分龐大的項(xiàng)目團(tuán)隊(duì)，這時(shí)候就要浪費(fèi)大量的時(shí)間在更新軟件上，而且不能方便有效地維護(hù)系統(tǒng)等情況時(shí)，微服務(wù)可以從根本上解決這些問題。從而大大節(jié)約了時(shí)間，從而節(jié)約了物力人力，提高了工作效率，從而更好地將項(xiàng)目順利完成。

2 復(fù)雜服務(wù)軟件系統(tǒng)的建模

服務(wù)業(yè)務(wù)層主要是由服務(wù)消費(fèi)者，服務(wù)提供者，以及服務(wù)監(jiān)管者三部分組合而成的，如圖1所示。

Service Mesh 對服務(wù)實(shí)例所需的資源管理接口、消息路由接口、流量控制接口、監(jiān)控測量接口進(jìn)行打包封鎖,監(jiān)控日志以及流量是每個(gè)微服務(wù)必不可少的配置。感知、決斷、執(zhí)行的能力是適應(yīng)性軟件的基本能力,基于 Service Mesh 的自適應(yīng)軟件框架是具有以上功能的。如圖2所示。

3 微服務(wù)軟件開發(fā)分析設(shè)計(jì)

面對復(fù)雜的軟件開發(fā)，開發(fā)工作人員就需要專業(yè)與之匹配的專業(yè)工具來輔助更好地完成相關(guān)的開發(fā)工作。從而能更好完成軟件的開發(fā)設(shè)計(jì)和維護(hù)管理。如此一來開發(fā)出來的額軟件才更具有穩(wěn)定性和。從而滿足軟件服務(wù)的根本要求。如果想要科學(xué)精準(zhǔn)有效地保持繁雜軟件具有一定的適配能力。就需要引入先進(jìn)的創(chuàng)新的技術(shù)理念和軟件工具集，來對分析軟件，部署更新，運(yùn)行維護(hù)這三個(gè)階段來進(jìn)行監(jiān)管。

3.1 分析設(shè)計(jì)階段

3.1.1 服務(wù)需求建模

產(chǎn)生刻畫復(fù)雜服務(wù)軟件系統(tǒng)的多主體回路模型是服務(wù)需求建模的目的,從而描繪出復(fù)雜服務(wù)系統(tǒng)中關(guān)聯(lián)Agent與其他主體之間的有效交通,其中包含了一些非常紛繁復(fù)雜的社會性質(zhì)先關(guān)系統(tǒng)技術(shù)。對主要的業(yè)務(wù)指標(biāo)群集進(jìn)行有效定義。在處理 Agent時(shí),可以根據(jù)BPMN的原則來進(jìn)行有效設(shè)計(jì)系統(tǒng),定對Agent功能來進(jìn)行有效定義，確保Agent的服務(wù)和QoS 加以規(guī)范化。

3.1.2 服務(wù)語義建模

在面對大規(guī)模、多樣化、關(guān)系復(fù)雜的服務(wù)元數(shù)據(jù)時(shí)，可以采用服務(wù)語義建模,其精準(zhǔn)度高，而且能夠十分高效地表示建模服務(wù)語義，從而更好支持智能服務(wù)的應(yīng)用與匹配。融合多源數(shù)據(jù)、標(biāo)注人工語義、基于圖神經(jīng)網(wǎng)絡(luò)的語義和知識圖譜表示學(xué)習(xí)是服務(wù)語義建模的主要特點(diǎn),從大量的非結(jié)構(gòu)化的數(shù)據(jù)中，自動(dòng)構(gòu)造面向服務(wù)適配的服務(wù)圖和語義知識圖。

3.1.3 服務(wù)適配組合

其具體包括以下研究內(nèi)容：

圖1：復(fù)雜服務(wù)軟件系統(tǒng)的分層架構(gòu)

圖2：基于 Service Mesh的自適應(yīng)軟件框架

服務(wù)智能組合功能需要通過構(gòu)造語義驅(qū)動(dòng)來實(shí)現(xiàn)，微服務(wù)的語義聚類是由微服務(wù)的語義畫像來完成的。遵照BPMN程序的基本特性,從而尋找到與微服務(wù)語義契合的群集。尋找一些在語言結(jié)構(gòu)以及特點(diǎn)上具有相似性質(zhì)的微服務(wù)集合。科學(xué)有效地對服務(wù)主體的建模進(jìn)行支撐。最終讓開發(fā)軟件的工作人員完成BPMN程序到微服務(wù)程序的映射。

在進(jìn)行流程的組合時(shí)，可以將微服務(wù)的適配自動(dòng)插入功能實(shí)施到整個(gè)流程的組合中來。如此一來便可以讓上下游微服務(wù)的智能承接功能得以有效實(shí)施。其次,根據(jù)服務(wù)主體中的業(yè)務(wù)核心指標(biāo)集KPIb ,把 BPMN 流程的QoS規(guī)范轉(zhuǎn)化為微服務(wù)流程的 QoS 要求,科學(xué)有效地確保部署和運(yùn)行。因此必須要對微服務(wù)流程和編排功能進(jìn)行設(shè)計(jì)。還有科學(xué)有效管理微服務(wù)的組合方案。讓集成和編排部署工作實(shí)現(xiàn)連續(xù)化。將整個(gè)業(yè)務(wù)流程和微服務(wù)的組合功能進(jìn)行動(dòng)態(tài)化的管理與維護(hù)，并且保證他們的一致性與合理性。管理持服務(wù)流程的版本、將其動(dòng)態(tài)實(shí)施與管理,并遵從流程適配的功能要求、QoS 要求、成本約束要求,優(yōu)化邏輯方案和物理方案。

3.1.4 交付更新階段

構(gòu)成智能化、有效性，精準(zhǔn)的服務(wù)代碼以及托付整個(gè)演變過程。完成審計(jì)繁瑣的服務(wù)演變流程是交付更新的首要任務(wù)。

交付更新階段一共分為三個(gè)步驟分別是持續(xù)集成、持續(xù)部署、金絲雀部署和灰度發(fā)布

（1）持續(xù)集成。最具有代表性的連續(xù)性集成工具有 Git Lab CI1)是 Git Lab 內(nèi)置的持續(xù)集成工具,通過創(chuàng)建CI 配置文件在倉庫的根目錄下，將 build 組件 Git Lab Run- ner進(jìn)行配置,從而實(shí)現(xiàn)了無論在何種場景下都能夠?qū)崿F(xiàn)自動(dòng)構(gòu)建功能。

（2）持續(xù)部署。以容器鏡像庫作為基礎(chǔ)是持續(xù)部署的主要特點(diǎn),通過YAML文件的有效引導(dǎo)，從而把 Docker 鏡像持續(xù)部署到目標(biāo)環(huán)境。最具有代表性的持續(xù)部署工具 Ar- go CD2就是依據(jù)聲明式 Git Ops 理念的持續(xù)部署工具。還能夠科學(xué)有效地控制版本,其具有完全自動(dòng)化以及可審計(jì)的應(yīng)用部署和生命周期。

（3）金絲雀發(fā)布以及灰度發(fā)表。和他有異曲同工之妙是灰度發(fā)布。系統(tǒng)單一是金絲雀策略擁有的屬性和特點(diǎn)。軟件更新方式是以舊代新，自動(dòng)替換。他們共同的具有代表性工具有 Argo Rollouts 3), Istio4)和 Flag- ger5)。Argo Rollouts 在面向K8S中是最有代表性的。對于藍(lán)綠的灰度發(fā)布和金絲雀部署支持度很高。Istio 的服務(wù)網(wǎng)格是完全具有開源特性。將透明部分與分布式應(yīng)用程序相互接入，如此一來便可以將所有的日志進(jìn)行集成，以及遠(yuǎn)距離測試策略系統(tǒng)的API接口。Flag ger 是一個(gè)開源的 Kubernetes operator,它的主要功能就是幫助解決不間斷的交付環(huán)節(jié)中如果一旦發(fā)生失敗的情況以及在系統(tǒng)無法使用的情況下等問題的產(chǎn)生。

4 未來研究方向

為了能夠讓微服務(wù)軟件設(shè)計(jì)能夠有效實(shí)現(xiàn)，在工業(yè)方面相關(guān)人員已經(jīng)開發(fā)出了很多微服務(wù)框架（如Spring Cloud等）和開源解決方案（如Netlix開源組件、服務(wù)網(wǎng)格Istio.Docker等），并且大大得到普及，在整個(gè)學(xué)術(shù)界也有相關(guān)的專業(yè)人士表述了關(guān)于如何實(shí)現(xiàn)面向微服務(wù)軟件設(shè)計(jì)的方式方法。但是同時(shí)需要對其進(jìn)行有效驗(yàn)證，看它是否具備一定的大規(guī)模系統(tǒng)開發(fā)需求。除此之外，在對微服務(wù)軟件展開有效設(shè)計(jì)時(shí)，此過程受到很多外部因素和內(nèi)部因素的制約與影響。從而給開發(fā)設(shè)計(jì)工作帶來了嚴(yán)重的挑戰(zhàn)和困境。

為了能有有效實(shí)現(xiàn)微服務(wù)軟件的設(shè)計(jì)與開發(fā)，相關(guān)的工作人員應(yīng)該深入全面了解剖析已有的實(shí)戰(zhàn)經(jīng)驗(yàn)。在已有的基礎(chǔ)之上對當(dāng)前存在的缺陷和弊端展開游戲哦啊分析。與此同時(shí)，大力引入汲取最新的科學(xué)和學(xué)術(shù)研究成果，充分驗(yàn)證這些學(xué)術(shù)成果，另外，還要科學(xué)有效合理地評估并研究微服務(wù)的設(shè)計(jì)質(zhì)量。科學(xué)全面評估整體的質(zhì)量功效。從而有效促進(jìn)并且?guī)椭嚓P(guān)的開發(fā)人員更好地完成設(shè)計(jì)工作。

通過展開對微服務(wù)軟件的有效測試，我們發(fā)現(xiàn)目前僅有的測試方式有組件測試、端到端測試、回歸測試、驗(yàn)收測試、變異測試和軟件調(diào)試幾種類型。但是由于相關(guān)的工作人員技術(shù)有限，能力有限，導(dǎo)致了到目前為止仍然沒有完備的測試方法來針對于微服務(wù)內(nèi)部邏輯結(jié)構(gòu)。此外,目前僅僅擁有關(guān)注自動(dòng)化測試框架的構(gòu)建，沒有進(jìn)行深入考究對面向微服務(wù)的測試建模、測試用例生成、測試預(yù)期輸出判定以及故障定位等。

如果想要對微服務(wù)軟件展開科學(xué)合理有效測試。就需要相關(guān)的工作人員通過引入傳統(tǒng)測試技術(shù)的基礎(chǔ)之上加以優(yōu)化和創(chuàng)新。期間要保持測試具有有效性，創(chuàng)新性，準(zhǔn)確性，全面性，高效性穩(wěn)定性等等。除此之外，通過在微服務(wù)測試的測試建模、測試用例生成、測試預(yù)期輸出判定以及故障定位等各個(gè)階段開發(fā)相應(yīng)的自動(dòng)化測試方法和工具，形成系統(tǒng)的微服務(wù)測試方法體系。

對于微服務(wù)重構(gòu)來說,迄今為止有較多的研究數(shù)量，相關(guān)的工作人員和學(xué)者探索了重構(gòu)程序和重構(gòu)方法。同時(shí)還闡述了大量的將單體應(yīng)用遷移為微服務(wù)的方法,而且通過實(shí)證研究予以證實(shí)。但是,已有的重構(gòu)方法能否和現(xiàn)代的大規(guī)模系統(tǒng)相互適應(yīng)依然需要相關(guān)人員進(jìn)一步展開驗(yàn)證。通過對比不同重構(gòu)方法和評估上相關(guān)工作人員應(yīng)該不斷創(chuàng)新思維，積極探索開辟新的經(jīng)驗(yàn)研究途徑。通過已有的研究基礎(chǔ)，選擇適用于不同重構(gòu)場景的標(biāo)準(zhǔn)化、規(guī)范化方法。

5 結(jié)語

隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，互聯(lián)網(wǎng)用戶表也是日益加贈。傳統(tǒng)互聯(lián)網(wǎng)業(yè)務(wù)的單體式應(yīng)用模式已經(jīng)無法滿足差異化用戶的個(gè)體需要，引入微服務(wù)能夠根據(jù)用戶邏輯進(jìn)行需求拆分，基于簡單運(yùn)行邏輯進(jìn)行微服務(wù)功能的實(shí)現(xiàn)微服務(wù)是 SOA 架構(gòu)的一種變體，基于輕量級協(xié)議與細(xì)粒度服務(wù)進(jìn)行應(yīng)用程序構(gòu)造與軟件開發(fā)設(shè)計(jì)，可憑借其擴(kuò)展性優(yōu)勢進(jìn)行開放平臺的部署，能夠有效降低成本、縮短開發(fā)周期的應(yīng)用效果。