一種基于融合微服務架構的系統的制作方法

本發明涉及微服務技術領域，特別涉及一種基于融合微服務架構的系統。

背景技術：

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

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

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

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

同時，傳統的架構設計導致運維效率低。產品業務不斷新增使得整個系統的可維護性愈來愈差，產品各個功能模塊關聯孤立。當這種情況體現到整個企業管理中時，會使得所有的功能模塊運維困難。

微服務架構（Microservices Architecture）的誕生和容器（Docker）技術的流行而是互聯網時代倒逼傳統技術和架構而產生的變革。以Docker為代表的容器技術為微服務架構解決了快速部署、優化資源利用率、高適配的問題。

技術實現要素：

本發明的目的在于提供一種基于融合微服務架構的系統，整合了微服務的構架使的每個產品功能的設計粒度化，以提高系統的可調度性，為新需求的快速準確開發提供了可靠性的保障。

為達到上述目的，本發明實施例公開了一種基于融合微服務架構的系統，技術方案如下：

一種基于融合微服務架構的系統，包括：應用模塊、接口訪問模塊、業務服務模塊、公共服務模塊、資源管理模塊；

所述應用模塊發送數據請求；

所述接口訪問模塊用于接收并處理所述應用模塊發送的數據請求，并根據所述數據請求確定執行所述數據請求的微服務單元，且發送有關所述微服務單元的信息；

所述業務服務模塊用于接收所述接口訪問模塊發送的所述微服務單元信息，并根據所述微服務單元信息調用所述微服務；

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

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

其中，所述應用模塊為應用程序或web。所述接口訪問模塊為API網關；

所述微服務單元的信息，包括：所述微服務的調用接口信息。

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

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

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

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

所述系統還包括：服務管理架構，與所述業務服務模塊相連，用于對所述業務服務模塊進行展示、管理和配置；

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

應用本發明技術方案，通過應用模塊發送數據后接口訪問模塊接受并處理該數據，并確定由哪個微服務單元來執行數據請求，業務服務模塊啟動接口訪問模塊確定的執行數據請求的微服務單元，然后公共服務模塊中的服務用以執行，可以看的出本發明實施例整合了微服務的構架使的每個產品功能的設計粒度化，以提高系統的可調度性，為新需求的快速準確開發提供了可靠性的保障。

附圖說明

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

圖1為本發明實施例提供的基于融合微服務架構的系統的第一種結構圖；

圖2為本發明實施例提供的基于融合微服務架構的系統的第二種結構圖；

圖3為本發明實施例提供的基于融合微服務架構的系統的第三種結構圖；

圖4為本發明實施例提供的基于融合微服務架構的系統的第四種結構圖；

圖5為本發明實施例提供的基于融合微服務架構的系統的第五種結構圖。

具體實施方式

下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基于本發明中的實施例，本領域普通技術人員在沒有作出創造性勞動前提下所獲得的所有其他實施例，都屬于本發明保護的范圍。

為解決上述技術問題，本發明實施例提供了一種基于融合微服務架構的系統，以下分別進行詳細說明。

圖1為本發明實施例提供的基于微服務的管理系統的第一種結構圖，系統包括：應用模塊1、接口訪問模塊2、業務服務模塊3、公共服務模塊4、資源管理模塊5；

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

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

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

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

參見圖2，圖2為本發明實施例提供的基于微服務的管理系統的第二種結構圖，接口訪問模塊為API網關；微服務單元的信息，包括：微服務的調用接口信息。

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

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

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

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

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

參見圖5，圖5為本發明實施例提供的基于微服務的管理系統的第五種結構圖，該系統還包括：服務管理架構6，與業務服務模塊相連，用于對業務服務模塊進行展示、管理和配置；服務管理架構6，包括：服務展示子模塊、服務配置子模塊、服務管理子模塊。

應用本發明圖1-圖5的實施例，整合了微服務架構，對于系統中的應用服務（Application Service）通過其職責和需要實現的技術來劃分下屬微服務單元（或實例）。這樣能夠盡可能的把功能服務專一化、基礎職責明確化，方便代碼開發和維護。同時該平臺通過標準化的適配設置整合不同的功能應用接口。

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

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

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

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

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

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

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