文/曾楚之

1 前言

基于微服務(wù)的系統(tǒng)由許多小型服務(wù)組成，基于網(wǎng)絡(luò)小型服務(wù)器之間可以相互傳播通信。每個小型服務(wù)器之間都是相互依存的，而且都具有單獨的開發(fā)周期。盡管有許多關(guān)于微服務(wù)架構(gòu)的研究，但仍然存在諸如服務(wù)發(fā)現(xiàn)中的過度延遲和不準(zhǔn)確性之類的問題。并沒有將單項服務(wù)的質(zhì)量描述完全。因此無法實時調(diào)整動態(tài)環(huán)境里的操作。在研究微服務(wù)架構(gòu)的同時。不準(zhǔn)確的依賴圖構(gòu)成方案。目前的服務(wù)故障模型沒有充分考慮系統(tǒng)的實際功能。因此在服務(wù)風(fēng)險研究的時候，就沒有考慮系統(tǒng)執(zhí)行路徑的差異，因此沒有過大影響最終的計算結(jié)果?；诜?wù)風(fēng)險的錯誤，本文改進了服務(wù)風(fēng)險的錯誤恢復(fù)方案，同時頁改進了服務(wù)風(fēng)險和錯誤的解決方案，在消除風(fēng)險服務(wù)之前極大的避免了大量的故障和錯誤的發(fā)生。

2 服務(wù)網(wǎng)格為框架服務(wù)的治理意義

現(xiàn)代軟件系統(tǒng)的架構(gòu)變得越來越復(fù)雜，極其復(fù)雜的系統(tǒng)，必須提高在使用過程中的可用性。將問題的解決角度定在體系結(jié)構(gòu)方面，微服務(wù)架構(gòu)逐步成為了編程的最新示范案例。首先，通過近幾年的發(fā)展，在軟件開發(fā)的過程中，微服務(wù)架構(gòu)也是變得非常流行。微服務(wù)架構(gòu)完全是一種嶄新的軟件方面的架構(gòu)設(shè)計，軟件系統(tǒng)的設(shè)計和開發(fā)擁有極高的可維護性、擴展性。開發(fā)人員能夠非常友好的微服務(wù)架構(gòu)的設(shè)計相融合。程序完全遵循微服務(wù)架構(gòu)的設(shè)計原則，同時指導(dǎo)完成實現(xiàn)的程序設(shè)計。甚至詳細具體到每個子服務(wù)的功能。因為較低的單個服務(wù)的復(fù)雜性，所以實現(xiàn)和測試服務(wù)的功能要被開發(fā)人員重視。在傳統(tǒng)的大眾服務(wù)中，因為許多軟件工程師的代碼庫都是相同的，所以也使得部分工程師覺得出現(xiàn)的問題與自己無關(guān)，不會認(rèn)為是自己出現(xiàn)了問題。另外，因為一個單一的業(yè)務(wù)模塊都代表對應(yīng)的微服務(wù)，從而交付和更新全都可以獨立地根據(jù)自身計劃進行，而很多自治權(quán)都掌握在服務(wù)開發(fā)人員手里。通常由單個服務(wù)組成了微服務(wù)架構(gòu)設(shè)計系統(tǒng)。不同的功能擁有不同的服務(wù)，因此執(zhí)行功能是需要通過信息交互來實現(xiàn)。因為這個功能的存在，不需要重新啟動整個系統(tǒng)也可以將系統(tǒng)中的模塊進行修改，只需將相應(yīng)的服務(wù)進行正確的部署就可以了。應(yīng)用程序開發(fā)人員可以自由的開發(fā)，部署和調(diào)試。將選擇最合適的開發(fā)語言，開發(fā)框架，配置方法來提供給自己使用。

對于大型單應(yīng)用程序應(yīng)用程序，一些新技術(shù)是有限的。如果要使用新框架，則需要替換它們。這通常會帶來巨大的風(fēng)險。使用微服務(wù)架構(gòu)可以幫助降低這種風(fēng)險?；谖⒎?wù)架構(gòu)的系統(tǒng)通常是靈活的系統(tǒng)。每次出現(xiàn)失敗的服務(wù)時，系統(tǒng)依舊會繼續(xù)運行。一些功能為此可能會出現(xiàn)丟失情況，但客戶仍然可以使用剩余的功能，可以將部署的風(fēng)險大大減少，減少部署中斷的影響。

3 服務(wù)治理措施

3.1 維護成本

維護項目通常需要付出很多努力，這可能占百分之四十到八十，這會導(dǎo)致開發(fā)成本低于維護成本。在高度動態(tài)的環(huán)境中將會運行未來的軟件系統(tǒng)，這是有益的環(huán)境條件。

意外更改，用戶需求首選項等。面對這些變化，系統(tǒng)仍需要正常工作。由于微服務(wù)架構(gòu)，獨立部署的每項服務(wù)，生命周期和都擁有自己獨立的運營環(huán)境。每項服務(wù)都需要能夠應(yīng)對這些外部條件。

及如何實現(xiàn)自主自治。服務(wù)正在成為越來越受歡迎的研究方向。服務(wù)質(zhì)量已成為服務(wù)選擇越來越重要的標(biāo)準(zhǔn)。有完全可靠系統(tǒng)。系統(tǒng)在使用微服務(wù)架構(gòu)設(shè)計的時候，多種獨立服務(wù)組成系統(tǒng)，都有單獨的失效。當(dāng)失敗單獨出現(xiàn)在這些服務(wù)的時候，必須研究檢查這些故障對體系結(jié)構(gòu)中的其他服務(wù)影響，明確它們在系統(tǒng)中的傳播方式，以及影響到最終用戶的體驗情況

3.2 依賴圖

在目前的研究中，依賴圖的自動建立仍存在一些問題，如精度低，便利性低。在系統(tǒng)可靠性方面，最終目標(biāo)是防止系統(tǒng)故障。要做到這一點，必須將系統(tǒng)各個應(yīng)用程序之間的依賴關(guān)系搞清楚。執(zhí)行此操作的時候要結(jié)構(gòu)化，將故障樹建模方法使用在其中。一個邏輯圖可以被定義為故障樹，將系統(tǒng)中關(guān)鍵事件及其原因及時顯示出來。故障樹構(gòu)建的過程可以使用故障樹來進行分析。可以將故障樹定性、定量。然而，就目前情況而言，沒有考慮故障樹就建立故障樹的過程了

并且系統(tǒng)中存在多個執(zhí)行路徑，并且在系統(tǒng)的實際預(yù)測過程中，多個執(zhí)行路徑是不同的。

3.3 風(fēng)險管理分析

風(fēng)險管理分析是項目管理領(lǐng)域的常用方法，已廣泛應(yīng)用于各個領(lǐng)域。風(fēng)險概念也適用于面向服務(wù)的設(shè)計流程，用于將業(yè)務(wù)合作伙伴更好的選擇。種種跡象表明，要想有效避免損害風(fēng)險可以使用風(fēng)險管理

研究了基于微服務(wù)架構(gòu)設(shè)計的系統(tǒng)服務(wù)風(fēng)險，在服務(wù)風(fēng)險計算模型中不考慮系統(tǒng)的實際實現(xiàn)，與此同時配套的服務(wù)恢復(fù)計劃只是服務(wù)替代。

4 結(jié)束語

在自動生成服務(wù)依賴關(guān)系圖的場景中獲取系統(tǒng)中服務(wù)之間的依賴關(guān)系可以用服務(wù)的配置文件進行。要求相關(guān)聯(lián)的配置文件要被服務(wù)作者編寫。

另一種解決方案是監(jiān)視系統(tǒng)中的網(wǎng)絡(luò)請求，捕獲服務(wù)之間的數(shù)據(jù)包，以及捕獲服務(wù)之間的依賴關(guān)系。在依賴關(guān)系圖生成期間完成每個服務(wù)依賴關(guān)系的檢索的關(guān)系。服務(wù)依賴圖生成的自動化將進一步增強，并將在未來進一步研究。本文評估了微服務(wù)架構(gòu)設(shè)計對系統(tǒng)的可靠性的影響，并討論了如何提高系統(tǒng)中服務(wù)的可靠性。需要進一步研究微服務(wù)架構(gòu)的可靠性。