本發(fā)明涉及微服務技術(shù)領(lǐng)域，特別涉及一種基于融合微服務架構(gòu)的系統(tǒng)。

背景技術(shù)：

微服務架構(gòu)是一種特定的軟件應用程序設計方式—將大型軟件拆分為多個獨立可部署服務組合而成的套件方案。雖然這種架構(gòu)風格的確切定義還存在爭議，但并不妨礙其在眾多企業(yè)的實際應用中被實踐，并體現(xiàn)出了具備通用特征的業(yè)務功能、自動化部署、端點智能化以及對語言與數(shù)據(jù)的離散化控制能力。

另外，Docker 作為一種開源的應用容器引擎，幫助開發(fā)者將他們的應用以及依賴打包到一個可移植的容器中，便于應用的部署和擴展。而隨之產(chǎn)生的微容器概念和微服務正好相輔相成，通過 Docker 封裝的應用可以輕松運行在以擴容能力見長的云計算平臺上。數(shù)人云作為專業(yè)的數(shù)據(jù)中心管理系統(tǒng)，提供了基于 Mesos 和 Docker 技術(shù)的企業(yè)級容器云生產(chǎn)環(huán)境，通過一鍵部署、橫向擴展、持續(xù)集成等特性，助力微服務架構(gòu)在企業(yè)應用環(huán)境的實踐。

微服務架構(gòu)近年來尤其受各大互聯(lián)網(wǎng)公司的追捧，比如微信、七牛云、陸金所、敦煌網(wǎng)等知名企業(yè)都在運用其來架構(gòu)自己的平臺。這些互聯(lián)網(wǎng)企業(yè)擁有龐大的用戶數(shù)據(jù)、更專業(yè)規(guī)范的企業(yè)級的PaaS服務，他們通過整合了微服務到各個功能模塊中實現(xiàn)快速處理海量數(shù)據(jù)、及時輸出產(chǎn)品、優(yōu)化產(chǎn)品體驗、提升產(chǎn)品服務質(zhì)量。在整個互聯(lián)網(wǎng)技術(shù)發(fā)展的趨勢下，快速融合微服務架構(gòu)到產(chǎn)品的研發(fā)中能夠使產(chǎn)品開發(fā)質(zhì)量、進度得到進一步的保障。

傳統(tǒng)的應用研發(fā)成本高，主要原因是：傳統(tǒng)的垂直的架構(gòu)、產(chǎn)品功能開發(fā)模式導致代碼重復率過高；代碼重復率過高導致功能需求變更困難（主要體現(xiàn)為功能修改不一致引起后續(xù)的測試、部署問題）；當代碼重復率過高及需求變更困難導致產(chǎn)品無法趕上日益變化的市場需求，不能快速上線、敏捷交付產(chǎn)品。

同時，傳統(tǒng)的架構(gòu)設計導致運維效率低。產(chǎn)品業(yè)務不斷新增使得整個系統(tǒng)的可維護性愈來愈差，產(chǎn)品各個功能模塊關(guān)聯(lián)孤立。當這種情況體現(xiàn)到整個企業(yè)管理中時，會使得所有的功能模塊運維困難。

微服務架構(gòu)（Microservices Architecture）的誕生和容器（Docker）技術(shù)的流行而是互聯(lián)網(wǎng)時代倒逼傳統(tǒng)技術(shù)和架構(gòu)而產(chǎn)生的變革。以Docker為代表的容器技術(shù)為微服務架構(gòu)解決了快速部署、優(yōu)化資源利用率、高適配的問題。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于提供一種基于融合微服務架構(gòu)的系統(tǒng)，整合了微服務的構(gòu)架使的每個產(chǎn)品功能的設計粒度化，以提高系統(tǒng)的可調(diào)度性，為新需求的快速準確開發(fā)提供了可靠性的保障。

為達到上述目的，本發(fā)明實施例公開了一種基于融合微服務架構(gòu)的系統(tǒng)，技術(shù)方案如下：

一種基于融合微服務架構(gòu)的系統(tǒng)，包括：應用模塊、接口訪問模塊、業(yè)務服務模塊、公共服務模塊、資源管理模塊；

所述應用模塊發(fā)送數(shù)據(jù)請求；

所述接口訪問模塊用于接收并處理所述應用模塊發(fā)送的數(shù)據(jù)請求，并根據(jù)所述數(shù)據(jù)請求確定執(zhí)行所述數(shù)據(jù)請求的微服務單元，且發(fā)送有關(guān)所述微服務單元的信息；

所述業(yè)務服務模塊用于接收所述接口訪問模塊發(fā)送的所述微服務單元信息，并根據(jù)所述微服務單元信息調(diào)用所述微服務；

所述公共服務模塊用于根據(jù)預先設置的微服務與服務的對應關(guān)系查找對應的服務，所查找到的服務用于接收所述微服務的指令；

所述資源管理模塊用于存放所述公共服務模塊中服務的數(shù)據(jù)，用于將對應的數(shù)據(jù)根據(jù)所述服務的請求回傳至所述公共服務模塊，并經(jīng)由所述微服務發(fā)送至所述業(yè)務服務模塊，所述業(yè)務服務模塊將所述數(shù)據(jù)通過所述接口訪問模塊發(fā)送至所述應用模塊。

其中，所述應用模塊為應用程序或web。所述接口訪問模塊為API網(wǎng)關(guān)；

所述微服務單元的信息，包括：所述微服務的調(diào)用接口信息。

所述公共服務模塊根據(jù)預設類別劃分為一個或多個服務組，每個服務組對應多個微服務。

所述微服務運行于Docker容器上。

所述公共服務模塊，包括：支付子模塊、消息通知子模塊、即時通訊服務子模塊、日志采集服務子模塊、任務管理子模塊。

所述資源管理模塊，包括：數(shù)據(jù)庫子模塊、緩存子模塊。

所述系統(tǒng)還包括：服務管理架構(gòu)，與所述業(yè)務服務模塊相連，用于對所述業(yè)務服務模塊進行展示、管理和配置；

所述服務管理架構(gòu)，包括：服務展示子模塊、服務配置子模塊、服務管理子模塊。

應用本發(fā)明技術(shù)方案，通過應用模塊發(fā)送數(shù)據(jù)后接口訪問模塊接受并處理該數(shù)據(jù)，并確定由哪個微服務單元來執(zhí)行數(shù)據(jù)請求，業(yè)務服務模塊啟動接口訪問模塊確定的執(zhí)行數(shù)據(jù)請求的微服務單元，然后公共服務模塊中的服務用以執(zhí)行，可以看的出本發(fā)明實施例整合了微服務的構(gòu)架使的每個產(chǎn)品功能的設計粒度化，以提高系統(tǒng)的可調(diào)度性，為新需求的快速準確開發(fā)提供了可靠性的保障。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本發(fā)明實施例提供的基于融合微服務架構(gòu)的系統(tǒng)的第一種結(jié)構(gòu)圖；

圖2為本發(fā)明實施例提供的基于融合微服務架構(gòu)的系統(tǒng)的第二種結(jié)構(gòu)圖；

圖3為本發(fā)明實施例提供的基于融合微服務架構(gòu)的系統(tǒng)的第三種結(jié)構(gòu)圖；

圖4為本發(fā)明實施例提供的基于融合微服務架構(gòu)的系統(tǒng)的第四種結(jié)構(gòu)圖；

圖5為本發(fā)明實施例提供的基于融合微服務架構(gòu)的系統(tǒng)的第五種結(jié)構(gòu)圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

為解決上述技術(shù)問題，本發(fā)明實施例提供了一種基于融合微服務架構(gòu)的系統(tǒng)，以下分別進行詳細說明。

圖1為本發(fā)明實施例提供的基于微服務的管理系統(tǒng)的第一種結(jié)構(gòu)圖，系統(tǒng)包括：應用模塊1、接口訪問模塊2、業(yè)務服務模塊3、公共服務模塊4、資源管理模塊5；

應用模塊1發(fā)送數(shù)據(jù)請求；接口訪問模塊2用于接收并處理應用模塊1發(fā)送的數(shù)據(jù)請求，并根據(jù)數(shù)據(jù)請求確定執(zhí)行數(shù)據(jù)請求的微服務單元，且發(fā)送有關(guān)微服務單元的信息；業(yè)務服務模塊3用于接收接口訪問模塊2發(fā)送的微服務單元信息，并根據(jù)微服務單元信息調(diào)用微服務；公共服務模塊4用于根據(jù)預先設置的微服務與服務的對應關(guān)系查找對應的服務，所查找到的服務用于接收微服務的指令；資源管理模塊5用于存放公共服務模塊4中服務的數(shù)據(jù)，用于將對應的數(shù)據(jù)根據(jù)服務的請求回傳至公共服務模塊4，并經(jīng)由微服務發(fā)送至業(yè)務服務模塊3，業(yè)務服務模塊3將數(shù)據(jù)通過接口訪問模塊2發(fā)送至應用模塊1。

本領(lǐng)域技術(shù)人員可以理解的是，應用模塊為應用程序或web，示例性的，應用模塊為應用程序，例如購物軟件，購物軟件運行于客戶終端，用戶在發(fā)送購買請求后進行支付，購物軟件將支付請求發(fā)送至接口訪問模塊2。接口訪問模塊2是一個統(tǒng)計接收用戶發(fā)送請求的管理接口，以根據(jù)請求的類型發(fā)送給相應的執(zhí)行單元，如接收到購物請求以后確定由1號管理接口進行處理，1號管理接口根據(jù)數(shù)據(jù)請求確定執(zhí)行數(shù)據(jù)請求的微服務單元，將確定的微服務的信息發(fā)送至業(yè)務服務模塊3。

業(yè)務服務模塊3中由很多的微服務，假設，根據(jù)微服務的接口信息確定調(diào)用的微服務為微服務A。公共服務模塊4根據(jù)微服務A與服務的對應關(guān)系，查找到微服務A對應的為支付服務，那么由支付服務來執(zhí)行本次的數(shù)據(jù)請求。在執(zhí)行以后，支付服務再將支付的信息發(fā)送至業(yè)務服務模塊3，業(yè)務服務模塊3將數(shù)據(jù)通過接口訪問模塊2發(fā)送至應用模塊1，用以告訴客戶本次支付的執(zhí)行結(jié)果，即完成了數(shù)據(jù)的雙向過程。具體的，可以是微服務對應的接口信息，可以理解的是每個微服務都有對應的接口，在微服務被調(diào)用的時候接到有關(guān)接口的調(diào)用信息就會啟動相應的微服務。具體的，資源管理模塊5用于存放公共服務模塊4中服務的數(shù)據(jù)，用于將對應的數(shù)據(jù)根據(jù)所述服務的請求回傳至公共服務模塊4，包括：數(shù)據(jù)庫子模塊、緩存子模塊。

本發(fā)明主要是融合微服務構(gòu)架的快速平臺，其整合了當下主流的技術(shù)框架、適配第三方服務接口、獨立設計研發(fā)了自主的分布式服務框架。

參見圖2，圖2為本發(fā)明實施例提供的基于微服務的管理系統(tǒng)的第二種結(jié)構(gòu)圖，接口訪問模塊為API網(wǎng)關(guān)；微服務單元的信息，包括：微服務的調(diào)用接口信息。

具體的，當接口訪問模塊為API網(wǎng)關(guān)時，API接收并處理應用模塊1發(fā)送的數(shù)據(jù)請求，如圖2所示，根據(jù)請求確定執(zhí)行數(shù)據(jù)請求的微服務單元為：微服務1。具體的，一個API網(wǎng)關(guān)下面可以對應多個微服務，而且確定執(zhí)行數(shù)據(jù)請求的微服務可以為一個，也可以為多個，本發(fā)明實施例在此不對其進行限定。

該平臺提供根據(jù)實際應用來拆分功能的最小粒度；對于服務可以融合Dubbo構(gòu)架，規(guī)范各種服務治理提高服務的效率和高可用性；同時融合Docker技術(shù)使各個服務單元環(huán)境一致，從而提高整體系統(tǒng)性能；而且該平臺通過適配可以融合多種API接口的接入。

參見圖3，圖3為本發(fā)明實施例提供的基于微服務的管理系統(tǒng)的第三種結(jié)構(gòu)圖，公共服務模塊4根據(jù)預設類別劃分為一個或多個服務組，每個服務組對應多個微服務。公共服務模塊4，包括：支付子模塊、消息通知子模塊、即時通訊服務子模塊、日志采集服務子模塊、任務管理子模塊。本發(fā)明實施例中公共服務模塊4所包含的子模塊僅僅是示例性的，公共服務模塊4中的子模塊只要能夠滿足對業(yè)務服務模塊3、資源管理模塊5之間的數(shù)據(jù)請求和發(fā)送接口，在本領(lǐng)域就似乎人員未做出創(chuàng)造性勞動的情況下，均屬于發(fā)明的保護范圍。

參見圖4，圖4為本發(fā)明實施例提供的基于微服務的管理系統(tǒng)的第四種結(jié)構(gòu)圖，微服務運行于Docker容器上。示例性的，圖4中，為一組微服務1-微服務5，具體的，微服務1運行在容器1上、微服務2運行在容器2上、微服務3運行在容器3上、微服務4運行在容器4上、微服務5運行在容器5上。實際應用中，一組微服務的數(shù)量可以為10、50、100、200等，本發(fā)明實施例僅僅是示例性的，不構(gòu)成對本發(fā)明的限定。

本領(lǐng)域技術(shù)人員可以理解的是，容器為應用程序提供了隔離的運行空間：每個容器內(nèi)都包含一個獨享的完整用戶環(huán)境空間，并且一個容器內(nèi)的變動不會影響其他容器的運行環(huán)境。為了能達 到這種效果，容器技術(shù)使用了一系列的系統(tǒng)級別的機制諸如利用Linux namespaces來進行空間隔離，通過文件系統(tǒng)的掛載點來決定容器可以訪問哪些文件，通過cgroups來確定每個容器可以利用多少資源。此外容器之 間共享同一個系統(tǒng)內(nèi)核，這樣當同一個庫被多個容器使用時，內(nèi)存的使用效率會得到提升。對于系統(tǒng)虛擬化技術(shù)來說，虛擬層為用戶提供了一個完整的虛擬機：包括內(nèi)核在內(nèi)的一個完整的系統(tǒng)鏡像。CPU虛擬化技術(shù)可以為每個用戶提供一個獨享且和其他用戶隔離的系統(tǒng)環(huán)境，虛擬層可以為每個用戶分配虛擬化后的CPU、內(nèi)存和IO設備資源。因此，將微服務運行于容器之上，能夠提高微服務的響應速度，提高數(shù)據(jù)的傳輸。對于用戶而言，提高了用戶的體驗。

參見圖5，圖5為本發(fā)明實施例提供的基于微服務的管理系統(tǒng)的第五種結(jié)構(gòu)圖，該系統(tǒng)還包括：服務管理架構(gòu)6，與業(yè)務服務模塊相連，用于對業(yè)務服務模塊進行展示、管理和配置；服務管理架構(gòu)6，包括：服務展示子模塊、服務配置子模塊、服務管理子模塊。

應用本發(fā)明圖1-圖5的實施例，整合了微服務架構(gòu)，對于系統(tǒng)中的應用服務（Application Service）通過其職責和需要實現(xiàn)的技術(shù)來劃分下屬微服務單元（或?qū)嵗?。這樣能夠盡可能的把功能服務專一化、基礎(chǔ)職責明確化，方便代碼開發(fā)和維護。同時該平臺通過標準化的適配設置整合不同的功能應用接口。

通過功能的詳細業(yè)務劃分清晰的微服務單元，可以使一個涉及業(yè)務比較多的大功能細化，然后通過若干個自服務的調(diào)度來完成一個大功能的開發(fā)實現(xiàn)。在功能開發(fā)過程中對于如果有同類相似的功能點就可以通過適配來實現(xiàn)功能服務的接口來快速完成開發(fā)。每一個小的服務單元開發(fā)完成后就可以從前端界面到后臺數(shù)據(jù)庫自成一個微服務單元，它們都服務于某一個大的功能點。

微服務單元通過服務元數(shù)據(jù)來實現(xiàn)與它同級的微服務單元業(yè)務交換處理，互相提供服務和消費服務，當數(shù)據(jù)交換處理完成后變形成了一個完整的業(yè)務功能流程。

同時分布式的服務框架可以實現(xiàn)服務的負載均衡，在數(shù)據(jù)請求方面使用SEDA（Staged Event Driven Architecture）使得事件同步模式異步化，把不同的業(yè)務操作類型隔離區(qū)別對待從而提高海量、突發(fā)數(shù)據(jù)請求。

需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。

本說明書中的各個實施例均采用相關(guān)的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于裝置實施例而言，由于其基本相似于方法實施例，所以描述的比較簡單，相關(guān)之處參見方法實施例的部分說明即可。

本領(lǐng)域普通技術(shù)人員可以理解實現(xiàn)上述方法實施方式中的全部或部分步驟是可以通過程序來指令相關(guān)的硬件來完成，所述的程序可以存儲于計算機可讀取存儲介質(zhì)中，這里所稱得的存儲介質(zhì)，如：ROM/RAM、磁碟、光盤等。

以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內(nèi)所作的任何修改、等同替換、改進等，均包含在本發(fā)明的保護范圍內(nèi)。