微服務(wù)架構(gòu)優(yōu)缺點及其可靠性分析目錄3734_WPSOffice_Level11.微服務(wù)架構(gòu)相關(guān)理論概述 325910_WPSOffice_Level21.1微服務(wù)架構(gòu)的概念 331969_WPSOffice_Level21.2微服務(wù)架構(gòu)的發(fā)展及其優(yōu)缺點 325910_WPSOffice_Level31.2.1微服務(wù)架構(gòu)的發(fā)展 331969_WPSOffice_Level31.2.2為服務(wù)架構(gòu)的特點 4859_WPSOffice_Level31.2.3微服務(wù)架構(gòu)優(yōu)勢。 428586_WPSOffice_Level31.2.4微服務(wù)架構(gòu)不足。 525910_WPSOffice_Level12.微服務(wù)系統(tǒng)的可靠性分析 5859_WPSOffice_Level22.1服務(wù)組合流程技術(shù) 528586_WPSOffice_Level22.2微服務(wù)系統(tǒng)的故障診斷方法 631969_WPSOffice_Level13.微服務(wù)系統(tǒng)的關(guān)鍵問題和微服務(wù)架構(gòu)實現(xiàn) 713050_WPSOffice_Level23.1目前微服務(wù)系統(tǒng)存在三個方面的問題有待解決： 731232_WPSOffice_Level23.2微服務(wù)架構(gòu)實現(xiàn) 813050_WPSOffice_Level31.加速互聯(lián)網(wǎng)信息服務(wù)繁榮。 1031232_WPSOffice_Level32.微服務(wù)商店的興起。 1013570_WPSOffice_Level33.加速創(chuàng)業(yè)項目的成形。 111.微服務(wù)架構(gòu)相關(guān)理論概述1.1微服務(wù)架構(gòu)的概念微服務(wù)的“微”是微小的意思，“服務(wù)”區(qū)別于系統(tǒng)是指用戶所能感知到的最小工作單位，是一個獨立的功能單元。微服務(wù)系統(tǒng)是一種熱門的軟件架構(gòu)，可以將復雜的軟件應(yīng)用工程分解為一個個小的子任務(wù)即微服務(wù)，從而實現(xiàn)按需擴展、靈活構(gòu)建軟件。微服務(wù)系統(tǒng)和軟件工程密不可分，自1968年提出以來，軟件工程的概念就被提出來了，并且已經(jīng)發(fā)展出來一系列的研究工具、實現(xiàn)語言、方法和較為完善的理論了。但是因為軟件存在著的不可見性、不穩(wěn)定性和復雜性，急需要有工具可以實現(xiàn)系統(tǒng)需求與系統(tǒng)詳細設(shè)計之間的過渡與交接，這時候軟件體系結(jié)構(gòu)就出現(xiàn)了。最早的時候計算機資源是集中分布在一臺機器上，這奠定了單體架構(gòu)的基調(diào)。單體架構(gòu)是有多個子服務(wù)組成，多個子服務(wù)則是一個整體，由于不能將每個子服務(wù)單獨進行擴展，從而限制了計算機資源的利用率。時代的選擇孕育了微服務(wù)架構(gòu)，獨立的微服務(wù)可以有機地組合為微服務(wù)架構(gòu)，每個微服務(wù)各司其職、互相交流、自動獨立部署、可以單獨被擴展。1.2微服務(wù)架構(gòu)的發(fā)展及其優(yōu)缺點1.2.1微服務(wù)架構(gòu)的發(fā)展在微服務(wù)出現(xiàn)之前，網(wǎng)站服務(wù)（web、接口服務(wù)（移動端）的服務(wù)架構(gòu)通常是“一站式”的。一個服務(wù)應(yīng)用中通常包含多個模塊和接口，傳統(tǒng)的開發(fā)模式和設(shè)計風格是將所有功能、接口統(tǒng)一設(shè)計，分層設(shè)計，逐層開發(fā)實現(xiàn)。以一個典型的web網(wǎng)站為例。它至少包含表示層（UI、業(yè)務(wù)層（邏輯控制、服務(wù)層（services、數(shù)據(jù)訪問層（DAO、持久層（數(shù)據(jù)庫）5層。在這5層的幾十上百個模塊中，若有任何一處沒有完成開發(fā)或編譯成功，都可能影響整個站點的部署。針對上述問題，20世紀90年代末，SOA（Service?Oriented?Architecture）面向服務(wù)架構(gòu)被提出，SOA首次提出了在軟件架構(gòu)設(shè)計時，使用低耦合并面向服務(wù)流程的思想。將流程分解為步驟，而每個步驟的實現(xiàn)都可以定義為一個服務(wù)。但SOA的架構(gòu)中，復雜的ESB企業(yè)服務(wù)總線依然處于微服務(wù)架構(gòu)的發(fā)展在大眾創(chuàng)業(yè)、萬眾創(chuàng)新的今天，各行業(yè)都以“互聯(lián)網(wǎng)+”相關(guān)應(yīng)用作為增加自身行業(yè)優(yōu)勢，加快服務(wù)效率的重要途徑。面對需求的瞬息萬變、以及跨行業(yè)的特殊要求，使自身信息服務(wù)的軟件架構(gòu)成本可控、擴展性強、易于維護成為非常迫切的要求。在微服務(wù)（Microservices）架構(gòu)風格被提出之前，在服務(wù)端構(gòu)建、開發(fā)并部署信息服務(wù)時，通常需要以統(tǒng)一的、完整的開發(fā)框架作為實現(xiàn)基礎(chǔ)。然而，面對業(yè)務(wù)不斷更變，尤其是在企業(yè)面對新需求，需要在舊系統(tǒng)和框架上作調(diào)整時，“一站式”的信息服務(wù)軟件架構(gòu)顯得越來越力不從心。微服務(wù)的提出和應(yīng)用無疑為這類企業(yè)和項目帶來了曙光。它使得信息服務(wù)的軟件架構(gòu)在演化和產(chǎn)生變動時的維護成大大降低，并顯著提高了穩(wěn)定性。1.2.2為服務(wù)架構(gòu)的特點微服務(wù)是一種軟件架構(gòu)的設(shè)計風格，整個軟件服務(wù)架構(gòu)由多個微服務(wù)構(gòu)成，它并沒有一成不變的規(guī)定，而是需要根據(jù)業(yè)務(wù)需求來做設(shè)計。微服務(wù)架構(gòu)原理。在微服務(wù)架構(gòu)中，每個微服務(wù)只負責非常明確、獨立、簡單的任務(wù)處理，并將處理結(jié)果以?API?的形式返回給外部。從實踐的角度看，微服務(wù)即是對整個軟件平臺或項目的細?；鸱郑鸱趾蟮乃形⒎?wù)獨立運行，互不干擾，每個微服務(wù)都運行在獨立的容器中。在以往的架構(gòu)設(shè)計中，服務(wù)層是以參數(shù)或?qū)ο髠鬟f的方式實現(xiàn)細?；^程的使用，這一過程在內(nèi)存中完成。而微服務(wù)將其搬到了“外部”。例如，在用戶的登錄過程，傳統(tǒng)的接口或動作（Action）中需要經(jīng)歷黑白名單檢查、密碼口令比對、登錄日志記錄三個過程。而在微服務(wù)架構(gòu)中，可將這三個過程都以微服務(wù)方式構(gòu)件，獨立工作，進而使微服務(wù)的代碼成為組件。微服務(wù)架構(gòu)使用一種服務(wù)管控模塊的思想來代替ESB總線，根據(jù)業(yè)務(wù)要求的不同，服務(wù)控制模塊至少需要包含服務(wù)的注冊、代理、發(fā)布、路由功能。1.2.3微服務(wù)架構(gòu)優(yōu)勢。微服務(wù)架構(gòu)的主要優(yōu)點取決于它可以使軟件架構(gòu)變得靈活，經(jīng)過低耦拆分的微服務(wù)在開發(fā)、測試、部署、更新階段都帶來了非常高的效率，業(yè)務(wù)的變更變得低成本和低風險。尤其在規(guī)模龐大的軟件項目中，微服務(wù)架構(gòu)的優(yōu)勢會更加的明顯。從企業(yè)角度來看，由于微服務(wù)架構(gòu)只與API相關(guān)，這使得不同服務(wù)可以通過使用不同的語言和開發(fā)框架進行開發(fā)，這極大地擴大了企業(yè)對人才招聘的限定范圍。從工程實現(xiàn)的角度來看，微服務(wù)架構(gòu)能將以往開發(fā)中的代碼、對象和模塊的復用轉(zhuǎn)變?yōu)榉?wù)復用，這樣很大程度上降低了項目在開發(fā)過程的管理成本，這對于一些需要基于基礎(chǔ)版的軟件功能進行個性化開發(fā)場景的幫助是巨大的。在實際應(yīng)用中，不同的微服務(wù)通常以Docker作為獨立容器部署，Docker容器可以共享一臺主機的內(nèi)核代碼部分，相比獨立的資源消耗較大的虛擬機而言更加小巧。同時它在進程級別是相互隔離的，使微服務(wù)的代碼執(zhí)行可以完全獨立出來，即便其中某些微服務(wù)因故障出現(xiàn)無法工作的情況，也不影響其它微服務(wù)的運行，從而使整個軟件服務(wù)的健壯性得到很大程度上提升。Docker的這種恰到好處的“半隔離半虛擬化”特點為微服務(wù)的應(yīng)用提供了強有力的支撐。1.2.4微服務(wù)架構(gòu)不足。微服務(wù)架構(gòu)誠然也有它的短處。首先，微服務(wù)架構(gòu)的設(shè)計并不是將所有操作都服務(wù)化、組建件，比如一些數(shù)據(jù)庫層的底層操作是不推薦服務(wù)化的。架構(gòu)設(shè)計者需要根據(jù)業(yè)務(wù)具體情況進行合理的劃分。此外，微服務(wù)架構(gòu)的目的是解決軟件開發(fā)和迭代過程中的效率問題，由于將本應(yīng)該在內(nèi)部使用的服務(wù)性功能以?API?的方式暴露出來，使得軟件平臺的一次對外數(shù)據(jù)服務(wù)過程中，需要增加數(shù)次基于HTTP?協(xié)議的內(nèi)部數(shù)據(jù)傳輸。雖然傳輸在內(nèi)就可以完成，但相比內(nèi)存中函數(shù)接口的調(diào)用上會慢幾個數(shù)量級。這對于后期服務(wù)用量增加，軟件平臺服務(wù)器的設(shè)計和部署會是一個不小的挑戰(zhàn)。最后，由于API在內(nèi)網(wǎng)的暴露下，設(shè)計者還需要對關(guān)鍵微服務(wù)進行鑒權(quán)保護，以保證一些敏感微服務(wù)不被濫用。2.微服務(wù)系統(tǒng)的可靠性分析就目前而言，網(wǎng)絡(luò)軟件它主要是由為服務(wù)系統(tǒng)來展現(xiàn)和表達的，可以實現(xiàn)網(wǎng)絡(luò)資源的共享和集成，比較符合現(xiàn)在計算機網(wǎng)絡(luò)的分布式特點，但是異構(gòu)，協(xié)同動態(tài)的網(wǎng)絡(luò)可能會隨時出現(xiàn)各種各樣的異常情況。這會使為服務(wù)系統(tǒng)的可靠性大大降低，網(wǎng)絡(luò)服務(wù)質(zhì)量也隨之會打折扣。如果要想解決微信服務(wù)的可靠性問題，我們可以借助“自適應(yīng)”調(diào)整的概念與應(yīng)用。當網(wǎng)絡(luò)已經(jīng)超出軟件設(shè)計的可控制范圍時，這是需要系統(tǒng)自己具有適應(yīng)動態(tài)調(diào)整的能力，從而能夠迅速，高效率的解決出現(xiàn)的各種異常問題。其實就是通過數(shù)學模型、統(tǒng)計方法、動態(tài)數(shù)據(jù)以及依賴關(guān)系等進行的綜合計算與預測評估，來進行可靠性的控制。2.1服務(wù)組合流程技術(shù)服務(wù)組合是把已有的相對簡單的服務(wù)，按一定的業(yè)務(wù)流程邏輯合并在一起，構(gòu)成相比較復雜的服務(wù)組合，從而提供更強大，更完整的商業(yè)功能。基于松散的服務(wù)組合，可以實現(xiàn)業(yè)務(wù)流程的定制，為用戶提供個性化的服務(wù)，從而使業(yè)務(wù)能夠做到隨機應(yīng)變。在業(yè)務(wù)流程發(fā)生改變時，只需要通過重新組織構(gòu)成業(yè)務(wù)流程的服務(wù)或動態(tài)調(diào)整組成業(yè)務(wù)流程的組件服務(wù)，快速響應(yīng)業(yè)務(wù)流程的變化。在由服務(wù)組合實現(xiàn)的業(yè)務(wù)流程中，無論是開發(fā)人員還是終端用戶，都可以將已有的服務(wù)進行組合，從而得到新的，又或者是較為復雜的服務(wù)體系，形成新的動態(tài)的業(yè)務(wù)流程。這推動了服務(wù)的使用率，提高了服務(wù)的重用性，并且加速了應(yīng)用項目的開發(fā)。我們可以從太網(wǎng)中存在小粒度服務(wù)和大粒度服務(wù)為例，一個小粒度服務(wù)是實現(xiàn)一個服務(wù)模型描述的需求規(guī)則約定，一個大粒度服務(wù)能夠?qū)崿F(xiàn)多個服務(wù)模型描述的眾多需求規(guī)則約定。互聯(lián)網(wǎng)中服務(wù)流程的目標是實現(xiàn)可靠性最優(yōu)，小粒度服務(wù)在同粒度的服務(wù)組合中比較容易實現(xiàn)目標，而大粒度服務(wù)模型則是通過構(gòu)建最優(yōu)大粒度服務(wù)流程模型來有效地解決問題，最優(yōu)大粒度服務(wù)流程建模是一個NPC的問題，其它的求解過程是十分復雜的。從目前的研究中，可以了解到已經(jīng)有大量基于某具體服務(wù)質(zhì)量最優(yōu)的服務(wù)流程組合方法，但是條件是基于同一類型的小粒度服務(wù)。然而大家看待問題時，普遍都是從不同的角度來觀察并且分析的，自然也會從很不一樣的粒度上來觀察和分析同一個問題。這種需求就需要根據(jù)大粒度服務(wù)模型來解析問題，由于有大粒度服務(wù)流程組合解決多個服務(wù)模型，可以大大地節(jié)省提供商的溝通成本、減少候選的服務(wù)集合的數(shù)量從而也可以降低了提供商的技術(shù)差別問題率等等。結(jié)合啟發(fā)式求解算法、云計算技術(shù)可以得到建立最優(yōu)大粒度服務(wù)流程組合模型問題的參考定義。2.2微服務(wù)系統(tǒng)的故障診斷方法微服務(wù)將傳統(tǒng)單體架構(gòu)的所有組件獨立的分開來，得到許多組件，組件的關(guān)系較為復雜，各軟件更新率比較高，這樣很大程度上增加了故障發(fā)生的概率以及診斷的難度。而且由于組件的依賴關(guān)系十分緊密，如果一個服務(wù)組件出故障時，就會影響到其他服務(wù)組件，出現(xiàn)泛洪現(xiàn)象，最后服務(wù)質(zhì)量也會下降。因此，找到有效的故障診斷方法、及時定位出錯原由，是微服務(wù)系統(tǒng)的關(guān)鍵問題之一。故障出現(xiàn)的原因有很多，僅僅設(shè)置人工報警準則是無法適應(yīng)復雜的組件依賴關(guān)系的，針對這一問題，提出一種基于執(zhí)行軌跡監(jiān)視測量的微服務(wù)故障診斷方法。可以利用樹形結(jié)構(gòu)的形式，算出差異的數(shù)值，針對差異值即異常數(shù)值，可以調(diào)用主成分分析法來診斷出結(jié)果。針對為服務(wù)系統(tǒng)提出一種面向微服務(wù)的高效故障診斷方法.研究思路主要包含執(zhí)行軌跡監(jiān)測、執(zhí)行軌跡構(gòu)建和故障診斷這三個環(huán)節(jié).(1)執(zhí)行軌跡監(jiān)測:利用動態(tài)插樁的方式，在微服務(wù)方法調(diào)用處插入監(jiān)測代碼，收集方法的執(zhí)行信息，包括方法唯一標識、處理時間、服務(wù)組件唯一標識等.由于請求通常是由多個服務(wù)組件協(xié)同處理，在遠程調(diào)用協(xié)議中加入了方法調(diào)用關(guān)系，以實現(xiàn)跨組件的請求軌跡的監(jiān)測.根據(jù)以上監(jiān)測信息，利用調(diào)用樹對執(zhí)行軌跡進行刻畫。(2)執(zhí)行軌跡構(gòu)建:由于程序的分支判斷等，同一個服務(wù)可能存在幾種不同的執(zhí)行軌跡.在覆蓋測試階段與運行階段搜集監(jiān)測數(shù)據(jù)時，可以對請求處理的執(zhí)行軌跡進行刻畫，從而盡可能全面地獲取每類請求的所有正常執(zhí)行軌跡，并保存在執(zhí)行軌跡庫中作為參考的基準.同時，為了消除遞歸、循環(huán)調(diào)用等對執(zhí)行軌跡的影響，增加了相應(yīng)的約簡規(guī)則。(3)故障診斷:引起執(zhí)行軌跡偏離的故障通常分為系統(tǒng)錯誤和性能異常，主要表現(xiàn)為執(zhí)行軌跡結(jié)構(gòu)和執(zhí)行時間的變化.前者故障通常導致了不同的執(zhí)行軌跡,采用樹的編輯距離來評估請求的異常程度，通過對比分析定位引起故障的方法調(diào)用;后者故障通常是資源競爭導致性能衰減，表現(xiàn)為服務(wù)響應(yīng)時間較為延遲.由于執(zhí)行軌跡通常包含上百個方法調(diào)用，可以通過主成分來分析對監(jiān)測數(shù)據(jù)進行降維，從而來提取關(guān)鍵的方法調(diào)用，縮小性能定位范圍。研究方向是微服務(wù)架構(gòu)的發(fā)展及其優(yōu)缺點，與單體應(yīng)用便于開發(fā)測試部署相比微服務(wù)架構(gòu)引入能夠解決單體哪些硬傷。微服務(wù)更加適合敏捷開發(fā)，易于開發(fā)維護和更強的系統(tǒng)伸縮性的研究。3.微服務(wù)系統(tǒng)的關(guān)鍵問題和微服務(wù)架構(gòu)實現(xiàn)3.1目前微服務(wù)系統(tǒng)存在三個方面的問題有待解決：（1）早期針對單體架構(gòu)的多實例部署的可靠性分析方法并不適用于微服務(wù)系統(tǒng)，仍然急需研究出解決微服務(wù)系統(tǒng)的多實例部署的可靠性方法。（2）隨著微服務(wù)系統(tǒng)的快速發(fā)展，針對單一的服務(wù)流程的可靠性分析方法已經(jīng)完全無法滿足網(wǎng)絡(luò)服務(wù)了，所以預估多業(yè)務(wù)流交互的微服務(wù)系統(tǒng)的可靠性也是一個關(guān)鍵性的問題。（3）實現(xiàn)自適應(yīng)調(diào)整的最直接的有效方法之一就是將服務(wù)流程重組。根據(jù)服務(wù)流程負載均模型和大力度服務(wù)候選集合的基礎(chǔ)組合服務(wù)流程也是一大難題。微服務(wù)是一種軟件架構(gòu)的設(shè)計風格，整個軟件服務(wù)架構(gòu)則是由多個微服務(wù)構(gòu)成，把并不是一成不變的，而是需要根據(jù)業(yè)務(wù)需求來做設(shè)計。3.2微服務(wù)架構(gòu)實現(xiàn)3.2.1微服務(wù)的概念微服務(wù)的概念是2014年3月由MartinFowler在他的文章《Microservices》中首次提出，作為一種先進的架構(gòu)模式，其核心思想就是：應(yīng)用是由多個小的、相互獨立的、可采用分布式部署的服務(wù)組成，服務(wù)的開發(fā)、部署在各自獨立的進程中，不同服務(wù)通過一些輕量級交互機制來通信，例如RPC、HTTP等，服務(wù)可獨立擴展伸縮，每個服務(wù)定義了明確的邊界，不同的服務(wù)可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護。目前，隨著互聯(lián)網(wǎng)思維和云平臺部署越來趨勢化，微服務(wù)架構(gòu)在應(yīng)用系統(tǒng)的建設(shè)中所體現(xiàn)出的價值越來越大。所謂微服務(wù)，就是將應(yīng)用程序內(nèi)的功能盡可能的進行劃分，并將每個細小的功能作為一個獨立的服務(wù)。每個微小的服務(wù)間通常情況下是使用HTTPAPI的方式來進行通信的，而且他們都專注于具體的業(yè)務(wù)功能，擁有強壯的模塊邊界，可以進行獨立部署。每個服務(wù)都進行協(xié)調(diào)與配合，最終為用戶提供相應(yīng)的功能需求。微服務(wù)框架目前，業(yè)界流行的微服務(wù)框架主要有兩個:SpringBoot和Dropwizard.SpringBoot繼承了原有Spring框架的優(yōu)秀基因,簡化了開發(fā)、配置、部署和監(jiān)控過程,幫助開發(fā)者快速啟動一個Web容器.Dropwizard從前端網(wǎng)頁、核心服務(wù)、資料庫存取到資源監(jiān)控,提供了一個輕量級的開發(fā)架構(gòu),幫助開發(fā)者快速的打造一個Rest風格的后臺服務(wù),同時集成hibernate4、log4j、slf4j、jackson等開源組件.微服務(wù)框架設(shè)計基于微服務(wù)架構(gòu)的應(yīng)用是分布式系統(tǒng),增加了系統(tǒng)設(shè)計和實現(xiàn)的難度,主要體現(xiàn)在以下幾個方面:①在運行環(huán)境中,微服務(wù)實例的網(wǎng)絡(luò)地址是動態(tài)分配的,微服務(wù)運行的實例數(shù)量也是動態(tài)變化的,因此,需要一套服務(wù)發(fā)現(xiàn)機制,使服務(wù)調(diào)用者可以獲取正確的服務(wù)地址,同時服務(wù)提供者一般以集群方式提供服務(wù),也引入了負載均衡和健康檢查問題.②在微服務(wù)架構(gòu)中,服務(wù)之間存在著復雜的相互依賴關(guān)系,在高并發(fā)訪問下,依賴的穩(wěn)定性直接會影響系統(tǒng)的可用性及性能.因此需要提供服務(wù)容錯機制,當依賴的服務(wù)發(fā)送故障時,不會使調(diào)用方線程被長時間占用不釋放,避免故障在系統(tǒng)中蔓延.③每個服務(wù)獨立部署運行,服務(wù)之間的通信是進程間通信,需要有一個高效的進程間通信機制支撐微服務(wù)之間的交互。④每個微服務(wù)可以有多個不同的實例,這使得服務(wù)按需動態(tài)伸縮成為一種可能,在高并發(fā)時可以啟動同一服務(wù)的多個實例,以提高響應(yīng)的速度.但服務(wù)實例的啟停及流量的調(diào)度和分發(fā)需要一套負載監(jiān)控和負載均衡組件來進行管理.⑤一個微服務(wù)應(yīng)用可能會由上百個服務(wù)來構(gòu)成,服務(wù)可以采用不同語言和框架。每個服務(wù)都有自己的部署、資源、擴展和監(jiān)控需求。因此需要提供版本管理和部署組件,來實現(xiàn)微服務(wù)的動態(tài)部署和無縫升級。微服務(wù)架構(gòu)具有如下優(yōu)勢：（1）微服務(wù)架構(gòu)將業(yè)務(wù)系統(tǒng)徹底的組件化、服務(wù)化，微服務(wù)專注于業(yè)務(wù)邏輯，服務(wù)功能簡單，邊界清晰，復雜度低，接口明確，服務(wù)利于開發(fā)、部署。（2）服務(wù)耦合度低，每個服務(wù)是一個微型的應(yīng)用，有完整的架構(gòu)，可獨立部署。（3）微服務(wù)架構(gòu)允許根據(jù)服務(wù)的功能和團隊的自身條件選擇不同的技術(shù)路線，允許服務(wù)由不同的開發(fā)團隊開發(fā)。（4）優(yōu)良的容錯機制和熔斷機制，保障微服務(wù)之間交互的友好性。微服務(wù)架構(gòu)雖是一種先進的架構(gòu)模式，但仍有它的不足：（1）微服務(wù)架構(gòu)的應(yīng)用是分布式系統(tǒng)，相較于單體架構(gòu)的應(yīng)用系統(tǒng)具有較大的復雜性，尤其是需要在RPC或者消息傳遞之間選擇并完成進程間的通訊機制；此外，消息傳遞、服務(wù)調(diào)用的性能相對于單體應(yīng)用會有所下降。（2）分布式系統(tǒng)帶來的數(shù)據(jù)庫數(shù)據(jù)的一致性問題對開發(fā)者提出更大的挑戰(zhàn)。3.2.2微服務(wù)構(gòu)架特點復雜度可控：微服務(wù)讓應(yīng)用被分解為多個可管理的分支或服務(wù)，通過微服務(wù)架構(gòu)模式，讓比較復雜的功能，可以通過模塊化的方式呈現(xiàn)出來，讓單個服務(wù)更容易開發(fā)和維護；靈活可擴展：微服務(wù)架構(gòu)模式讓每個服務(wù)得到獨立的擴展，每個服務(wù)可以進行單獨的增減功能，使得整體變得更加靈活；獨立部署：微服務(wù)具備獨立的運行進程，所以每個微服務(wù)也可以獨立部署。使用相同的部署環(huán)境可以實現(xiàn)批量快速部署微服務(wù)。在微服務(wù)架構(gòu)中，每個微服務(wù)只負責非常明確、獨立、簡單的任務(wù)處理，并將處理結(jié)果以API的形式返回給外部。從實踐的角度來看，微服務(wù)即是對整個軟件平臺或項目的細?；鸱?，拆分后的所有微服務(wù)可以獨立運行，互不干擾，每個微服務(wù)都運行在獨立的容器中。在以往的架構(gòu)設(shè)計中，服務(wù)層是以參數(shù)或?qū)ο髠鬟f的方式實現(xiàn)細?；^程的使用，這一過程在內(nèi)存中完成。而微服務(wù)將其轉(zhuǎn)移到了“外部”。例如，用戶的登錄過程，傳統(tǒng)的接口或動作（Action）中則需要經(jīng)歷黑白名單檢查、密碼口令比對、登錄日志記錄這三個過程。而在微服務(wù)架構(gòu)中，可以將這三個過程都以微服務(wù)的方式來構(gòu)件，獨立工作，進而使微服務(wù)的代碼轉(zhuǎn)變成為組件。微服務(wù)架構(gòu)使用一種服務(wù)管控模塊的思想來代替ESB總線，根據(jù)不同的業(yè)務(wù)要求，服務(wù)控制模塊需要包含服務(wù)的注冊、代理、發(fā)布、路由功能。3.2.3微服務(wù)架構(gòu)的影響目前微服務(wù)架構(gòu)僅僅是在一些中大型公司得到了實踐，還沒有完全被中小型企業(yè)接受。由于微服務(wù)架構(gòu)的優(yōu)勢，給相關(guān)行業(yè)帶來的將不止是軟件開發(fā)管理上的影響。1.加速互聯(lián)網(wǎng)信息服務(wù)繁榮。微服務(wù)架構(gòu)的靈活性可以使項目的開發(fā)過程更易于管理，從而大幅度提升項目開發(fā)團隊的開發(fā)效率。微服務(wù)獨立性、分外分割的設(shè)計思想可以使開發(fā)人員更加關(guān)心組件內(nèi)部的構(gòu)造，從而提高軟件代碼的質(zhì)量。同時，服務(wù)的復用使開發(fā)人員從以往的代碼、對象、模塊復用中解脫出來。服務(wù)復用的優(yōu)勢在于開發(fā)人員不需要在工程中去關(guān)心代碼級別的構(gòu)件和測試工作，僅需要依據(jù)定義好的?REST?API?向相應(yīng)地址發(fā)送請求即可，真正實現(xiàn)“一次部署，無限使用”。這將使企業(yè)或項目團隊在構(gòu)建后續(xù)功能時，時間和人力成本大幅降低，從而整個行業(yè)將有更多時間基于已有微服務(wù)開發(fā)更多新的微服務(wù)，也可將一個項目過程中的某些微服務(wù)對外開放調(diào)用，獲得收益。2.微服務(wù)商店的興起。隨著微服務(wù)開發(fā)者的增多，越來越多開發(fā)者愿意將自己開發(fā)的微服務(wù)開放給全網(wǎng)的用戶使用，甚至已有開發(fā)者專門開發(fā)微服務(wù)為職業(yè)。SAP公司于2016年下半年推出了Yaas平臺，專門為微服務(wù)進行銷售，Yaas?平臺類似于手機端的應(yīng)用商城、App?Store，它是基于微服務(wù)架構(gòu)實現(xiàn)的服務(wù)管理整臺。Yaas開放全世界的開發(fā)者接入他們自己開發(fā)的微服務(wù)應(yīng)用并以服務(wù)調(diào)用次數(shù)作為計費依據(jù)，為開發(fā)者獲取收益。目前Yaas平臺中已經(jīng)集成了眾多與電子商務(wù)相關(guān)的微服務(wù),如訂單管理、支付管理、商品管理等。未來隨著微服務(wù)開發(fā)者的增加，Yaas?平臺的微服務(wù)應(yīng)用將更加豐富。3.加速創(chuàng)業(yè)項目的成形。2014年以來，隨著國家創(chuàng)新創(chuàng)業(yè)政策的支持，越來越多的行業(yè)與互聯(lián)網(wǎng)行業(yè)跨界融合，創(chuàng)業(yè)項目以井噴式涌現(xiàn)。通常創(chuàng)業(yè)項目中的信息服務(wù)平臺開發(fā)和外包式的軟件開發(fā)的過程有其極大的不同。創(chuàng)業(yè)項目中很多業(yè)務(wù)和商業(yè)模式都是試探性和實驗性的，這導致其需求變化更為頻繁。傳統(tǒng)的統(tǒng)一式、整體式的服務(wù)開發(fā)框架難以適應(yīng)，若創(chuàng)業(yè)團隊不能把握好需求變更和生產(chǎn)環(huán)境的節(jié)奏，很容易造成服務(wù)整體性不可用。微服務(wù)架構(gòu)的出現(xiàn)使得初創(chuàng)項目的軟件開發(fā)可以遵循由中心到外圍，由重要到次要的微服務(wù)開發(fā)次序，降低因需求臨時變動帶來的對項目整體性的沖擊，從而加速項目的成形。結(jié)論提出了一種軟件系統(tǒng)服務(wù)質(zhì)量分析任務(wù)劃分的框架；基于此框架介紹了四類常用的服務(wù)質(zhì)量分析技術(shù)以及相應(yīng)的方法，并調(diào)查了使用這些技術(shù)和分法分析軟件系統(tǒng)的服務(wù)質(zhì)量的研究進展，發(fā)現(xiàn)每種服務(wù)質(zhì)量分析任務(wù)與相應(yīng)的技術(shù)、方法之間的關(guān)聯(lián)；在此基礎(chǔ)上，本文重點關(guān)注了基于概率模型檢驗的服務(wù)質(zhì)量分析方法以及這類分析方法的應(yīng)用場景，討論了概率模型檢驗方法在分析表現(xiàn)出隨機特性的系統(tǒng)服務(wù)質(zhì)量時所具有的優(yōu)勢，并給出了一個通用的基于概率模型檢驗的軟件可靠性分析平臺。微服務(wù)系統(tǒng)是軟件系統(tǒng)的其中一種形式，可靠性對服務(wù)系統(tǒng)來講也是一項重要的質(zhì)量屬性，對微服務(wù)系統(tǒng)可靠性的分析這對基于服務(wù)質(zhì)量的服務(wù)發(fā)現(xiàn)、服務(wù)推薦、服務(wù)組合以及基于服務(wù)質(zhì)量的服務(wù)系統(tǒng)的動態(tài)配置等工作都有很重要的意義。本文對在軟件可靠性分析方法現(xiàn)狀調(diào)查研究的基礎(chǔ)上，指出微服務(wù)系統(tǒng)可靠性分析中存在的問題，為微服務(wù)系統(tǒng)可靠性研究指明了方向。微服務(wù)架構(gòu)的發(fā)展已過走了幾年多的歷程，從最初的概念到一些大企業(yè)的積極實踐。盡管實際應(yīng)用中各家設(shè)計的細節(jié)不盡相同，但它引領(lǐng)了一種全新的大規(guī)模軟件平臺的設(shè)計樣式。從行業(yè)的反應(yīng)來看，微服務(wù)架構(gòu)將在未來幾年中更加深刻地影響軟件行業(yè)和其它與“互聯(lián)網(wǎng)+”相關(guān)行業(yè)。未來，隨著市場的快速發(fā)展，業(yè)務(wù)的不斷壯大，單塊架構(gòu)應(yīng)用面臨著越來越多的挑戰(zhàn)，而微服務(wù)架構(gòu)的誕生，這無疑是互聯(lián)網(wǎng)的高速發(fā)展，微服務(wù)系統(tǒng)定會應(yīng)用于生活的各種網(wǎng)絡(luò)業(yè)務(wù)中，我們必須認識到微服務(wù)系統(tǒng)強大的優(yōu)越性，也需要了解目前該系統(tǒng)遇到的關(guān)鍵問題：可靠性較低、故障診段與問題定位、系統(tǒng)流程組合難題等。將來在微服務(wù)這一系統(tǒng)上面還會有許多工作需要突破、完善，這會使得微服務(wù)系統(tǒng)一步步走向理想化的道路。隨著用戶個性化的不同需求，產(chǎn)品的生命周期會越來越短，然而微服務(wù)架構(gòu)則會是未來軟件架構(gòu)朝著靈活性，擴展性，伸縮性以及可用性發(fā)展的一個必然方向。希望本文對微服務(wù)系統(tǒng)的簡析可以對下一步工作起到推動作用。致謝時光荏苒，光陰似箭。我們曾經(jīng)以為極其漫長的讀書旅途，轉(zhuǎn)眼之間就要接近尾聲了。在四年短暫的時光里，我們體驗了最美好，最真誠，最難以忘懷的讀書生涯。我們在這里學習掌握科學文化知識，提升個人綜合能力、道德修養(yǎng)，培養(yǎng)無私奉獻的精神與博大的胸懷。在我們收獲