[發明專利]一種互聯網資源匹配系統與方法

在審

• 申請號: 202010710158.3
• 申請日: 2020-07-22
• 公開（公告）號: CN111859206A
• 公開（公告）日: 2020-10-30
• 發明（設計）人: 農怡琳;丘林城
• 申請（專利權）人: 農怡琳
• 主分類號: G06F16/955
• 分類號: G06F16/955
• 代理公司: 深圳市輝泓專利代理有限公司 44510
• 代理人: 劉海軍;孟強

本發明提出一種互聯網資源匹配系統和方法，可具體應用于布設了操作系統且需處理多種綜合管理數據和服務功能的諸如路橋、市政等需要對系統和系統內微應用、多功能進行管理和操作過程的綜合管理系統中，引入了具體處理數據匹配關系的一級匹配模塊與二級匹配模塊，用于具體處理第一維：應用對數據的關注，以及第二維：數據對應用的關注，并建立對應的關注熱點應用和數據之間的第一維映射關系以及第二維映射關系，在處理數據應用匹配的基礎上，為用戶的后續調用提供了數據間的映射關系和數據應用之間的系統邏輯對應關系。

技術領域

本發明屬于新一代計算機信息技術領域，尤其涉及一種互聯網資源匹配系統與方法。

背景技術

在諸如路橋、市政、交通綜合管理系統中，大數據的應用拓展了系統的功能涵蓋范圍，重新定義了系統中服務和應用的維度，提升了系統數據利用和處理的能力。

但由于諸如交通流量、路橋市政等應用場景下，數據的增加同時又提升了系統處理的運算難度，為系統綜合管理各種不同的信息數據，面對不同種類的數據資源提供匹配的應用處理和管控能力，提出了更高的系統訴求，并為管理員的配置提出了更高的要求。

數據資源，特別是當系統接入互聯網后，或在系統內部網絡中，數據資源具有信息的時效性、內容的廣泛性、訪問的快捷性、搜索的網絡性和資源的動態性等特點，具有成長性、自治性和多樣性等三個自然特性。

系統可以通過微服務或區分應用來處理海量的數據資源。微服務可以在“自己的程序”中運行，并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構(在現有系統中分布一個API)區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那么，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，并且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。微服務的基本思想在于考慮圍繞著業務領域組件來創建應用，這些應用可獨立地進行開發、管理和加速。在分散的組件中使用微服務云架構和平臺，使部署、管理和服務功能交付變得更加簡單。微服務是利用組織的服務投資組合，然后基于業務領域功能分解它們，在看到服務投資組合之前，它還是一個業務領域。微服務這一概念出現于2012年，是因軟件作者Martin Fowler而流行，他承認這并沒有精確地定義出這一架構形式，雖然圍繞業務能力、自動化部署、終端智能以及語言和數據的分散控制有一些常見的特性。

通過整體式架構，所有進程緊密耦合，并可作為單項服務運行。這意味著，如果應用程序的一個進程遇到需求峰值，則必須擴展整個架構。隨著代碼庫的增長，添加或改進整體式應用程序的功能變得更加復雜。這種復雜性限制了試驗的可行性，并使實施新概念變得困難。整體式架構增加了應用程序可用性的風險，因為許多依賴且緊密耦合的進程會擴大單個進程故障的影響。使用微服務架構，將應用程序構建為獨立的組件，并將每個應用程序進程作為一項服務運行。這些服務使用輕量級API通過明確定義的接口進行通信。這些服務是圍繞業務功能構建的，每項服務執行一項功能。由于它們是獨立運行的，因此可以針對各項服務進行更新、部署和擴展，以滿足對應用程序特定功能的需求。

由于系統內部服務和應用地多樣性，存在一定的服務管控需求，也存在對服務獨占或服務關注數據的匹配、整合。

數據、應用(服務)以及用戶的匹配，首要任務是數據管理。