相關名詞剖析

隨著互聯網的快速發展，企業的IT建設也是飛速發展的，但是在建設企業信息化時沒有統籌考慮，建設往往不成體系、重復開發、煙囪式的建設，造成了資源的冗余和浪費，為了針對這些問題逐漸誕生了SOA、ESB、微服務、API網關以及REST等技術，現針對技術點總結如下。

1API網關剖析

API 網關是一個服務器，也可以說是進入系統的唯一節點。這與面向對象設計模式中的 Facade 模式很像。API 網關封裝內部系統的架構，并且提供 API 給各個客戶端。它具備授權、監控、負載均衡、緩存、請求分片和管理、靜態響應處理等功能。

API網關負責服務請求路由、組合及協議轉換。客戶端的所有請求都首先經過 API網關，然后由它將請求路由到合適的微服務。API網關經常會通過調用多個微服務并合并來處理一個請求。它可以在 WEB協議與內部使用的非WEB協議之間相互轉換。API網關還能為每個客戶端提供一個定制的API，通常它會向移動客戶端暴露一個粗粒度的API，以產品詳情的場景為例，API網關可以提供一個端點使移動客戶端可以通過一個請求獲取所有的產品詳情。API網關通過調用各個服務（產品信息、推薦、評論等等）并合結果來處理請求。API網關主要功能如下：

使用API網關有優點也有不足，其中使用API網關的最大優點是：

1.它封裝了應用程序的內部結構。客戶端只需要同網關交互，而不必調用特定的服務。

2.API網關為每一類客戶端提供了特定的API，這減少了客戶端與應用程序間的交互次數，還簡化了客戶端代碼。

API網關的不足之處在于：

1.API網關增加了一個我們必須開發、部署和維護的高可用組件。

2.API網關變成了開發瓶頸。為了暴露每個微服務的端點，開發人員必須更新 API 網關。API網關的更新過程要盡可能地簡單，否則為了更新網關，開發人員將不得不排隊等待。

2ESB服務總線

其主要作用是作為企業信息系統的“龍骨”來集成各業務系統，實現異構系統的互聯互通，用來拉取、調度各個業務系統的數據，一般被稱為企業服務總線。ESB提供了網絡中最基本的連接中樞，是構筑企業神經系統的必要元素。

ESB提供了一種開放的、基于標準的消息機制，通過簡單的標準適配器和接口，來完成粗粒度應用和其他組件之間的互操作，能夠滿足大型異構企業環境的集成需求。

通過使用ESB，可以在幾乎不更改代碼的情況下，以一種無縫的非侵入方式使企業已有的系統具有全新的服務接口，并能夠在部署環境中支持任何標準。充當緩沖器的ESB（負責在諸多服務之間轉換業務邏輯和數據格式）與服務邏輯相分離，從而使得不同的應用程序可以同時使用同一服務，不用在應用程序或者數據發生變化時，改動服務代碼。

ESB產品作為一個產品化的產物，不僅僅是解決一些基礎的問題，產品自身還會在項目中不斷完善和發展。ESB會把各行各業的解決方案用到的內容逐漸豐富到產品中，隨著項目、行業的增多ESB的功能也越發豐富，可以應對不同行業的不同需求，隨著近期微服務的興起，ESB也進行迭代更新，我們的ESB更新了微服務的開發、編排、注冊等功能，下文則是微服務的主要介紹。

3微服務剖析

微服務是近些年被廣泛提及的一個概念，微服務產生于單體應用的擴大化，隨著信息化不斷發展，企業對軟件功能的要求越來越具體，也愈發的細致，如果通過應用程序來實現，必然是一個極其復雜而又痛苦的過程，由此誕生了微服務的概念。就是將功能發布成服務，應用程序通過調用不同的服務來實現業務，這種設計架構稱之為微服務。

一個微服務一般完成某個特定的功能，比如訂單管理、客戶管理等。每個微服務都是一個微型應用，有著自己六邊形架構，包括商業邏輯和各種接口。有的微服務通過暴露 API 被別的微服務或者應用客戶端所用；有的微服務則通過網頁 UI 實現。在運行時，每個實例通常是一個云虛擬機或者 Docker 容器。

微服務主要是經過組件分離各自擁有獨立的生命周期，并且按需進行擴展，這種方式打破了組件之間的技術依賴，允許每個服務各自選擇最合適的技術進行實現，每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。不同的服務甚至可以采用不同的編程語言來實現，一定程度上微服務使技術方案變得更加靈活，在使用過程中開發、測試、部署等環節十分便捷，整體是以松耦合高內聚的形式存在，符合IT技術思想。

4微服務架構

微服務架構MSA可以理解為一個輕量級的服務治理方案，也就是將系統的功能，通過服務的形式發布到服務器上，對服務進行組合調用，實現具體的功能，解決實際業務問題的架構風格。

微服務架構優點如下：

1.微服務架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供 API 服務。當然，許多公司試圖避免混亂，只提供某些技術選擇。然后，這種自由意味著開發者不需要被迫使用某項目開始時采用的過時技術，他們可以選擇現在的技術。甚至于，因為服務相對簡單，即使用現在技術重寫以前代碼也不是很困難的事情。

2.微服務架構模式使得每個微服務獨立部署，開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度，譬如 UI 團隊可以采用 AB 測試并快速部署變化。微服務架構模式使得持續化部署成為可能。

3.微服務架構模式使得每個服務獨立擴展。根據每個服務的規模來部署滿足需求的實例。甚至可以使用更適合于服務資源需求的硬件。比如可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服務，而在 EC2 memory-optimized instances 上部署內存數據庫。

微服務架構有優點當然也有不足之處，比如服務調用帶來的系統復雜性，服務間的依賴關系也是難以管理的，如何構建合理的服務依賴是考驗架構師能力的重要依據；最后，微服務架構的部署以及跟蹤也是很難的。總之，微服務架構有著自身的應用場景以及特點，了解哪些場景適合微服務比掌握微服務的具體技術更為重要，適當的技術用在適當的場景，才能發揮合適的價值。

5SOA架構剖析

SOA架構：SOA架構是一種粗粒度、開放式、松耦合的服務結構，要求軟件產品在開發過程中，按照相關的標準或協議，進行分層開發。通過這種分層設計或架構體系可以使軟件產品變得更加彈性和靈活，且盡可能的與第三方軟件產品互補兼容，以達到快速擴展，滿足響應市場或客戶需求的多樣化、多變性。

SOA架構泛化來看映射的是整體企業架構，企業架構又分為業務架構和IT架構，IT架構又分為應用架構、數據架構、技術架構。在SOA項目中，借鑒企業架構之道，并通過SOA技術架構和應用架構將業務系統構建和整合，并納入整體企業IT治理體系中。SOA技術架構圖如下：

6Restful剖析

Open API即開放API，也稱開放平臺。所謂的開放API是服務型網站常見的一種應用，網站的服務商將自己的網站服務封裝成一系列API應用編程接口開放出去，供第三方開發者使用，這種行為就叫做開放網站的 API，也稱OpenAPI。隨著這幾年微服務概念的興起，另一個名詞出現在了我們面前，那就是Restful。而現在很多第三方開放平臺的API都是Restful風格的API，而作為開發人員也經常聽人說起Restful，REST這個概念是在2010年提出的，是HTTP協議的一位主要設計者提出的 Representational State Transfer（表現層狀態轉化）思想。REST概念的提出者認為改變應用的互動風格比改變互動協議對整體表現有更大的影響，這就稱之為表現層狀態轉化，即REST它只是一種架構思想。

REST代表的就是表現層狀態轉化，這個表現層狀態該如何轉化呢，Restful本質上是基于HTTP的，以不同的HTTP動詞來訪問資源，再以Json對象返回結果。我們以不同的HTTP動詞來代表不同的操作類型，如：GET（請求）、POST（創建）、PUT（更新）、DELETE（刪除），所以表現層的狀態轉化實質上靠的是HTTP動詞來實現的。

適用場景分析

1網關適用場景

API網關能夠支撐各個場景下開放 API 的需求，支持將API開放給合作伙伴、開發者，實現企業核心能力的貨幣化，建立API生態，支持將API適配多端，如：移動、互聯網、物聯，實現系統前后端分離；支持內部系統整合模塊化、微服務化。

API資產

面對用戶日益膨脹而又碎片化的需求，企業需要不斷探索新的商業模式，來解決客戶一系列的場景化問題。通過API網關提供標準的API服務，讓其他開發者將不同API服務組合整合到自己的應用中，衍生出新的服務，促進企業建立商業生態、跨界創新。

API生態

如今企業面臨更多的挑戰，企業發展需要可靠的合作伙伴。企業與合作伙伴以 API 的形式進行服務、能力和數據的交互，系統與系統直接對接，達成深度合作，建立牢固的合作關系。將API接入阿里云市場以API的形式開放能力、服務、數據供廣大開發者采購使用，產生價值，在API市場，采購第三方成熟的能力和服務，避免平鋪式開發，專注專業，借力發展。

多端兼容

隨著移動、物聯網的普及，API需要支持更多的終端設備，以擴充業務規模，但同時也帶來系統復雜性的提升。通過API網關可以使API適配多端，企業只需要在API網關調整API 定義，無需做額外工作。企業只需維護一個服務體系，面向多端輸出，只需調整API定義，即可實現對App、設備、web端等多種終端的支持，這就避免多個場景多套API，大大降低管理運維成本。

系統集成

在快速發展的過程中往往不成體系、重復開發、煙囪式建設，造成資源冗余和浪費，通過API網關對系統間接口進行規范統一，用標準化的接口實現系統集成。

通過上面四個場景可見，API網關的作用還是很大的，可以統一管理API，使用統一的API平臺來統一管理這些API接口，提供統一通信協議、API文檔以及SDK，將大大提升公司內部部門間協作的效率。

2ESB適用場景

應用集成

實現異構系統的對接，連接現有各孤立的應用系統。包括服務之間的信息交換，協調各種應用和數據之間的服務傳輸協議，轉換應用數據和服務之間的消息/數據格式，任何的應用系統都是通過應用集成平臺與其它系統交互的。

典型場景：

1.費用報銷與薪資對接；

2.生產系統與ERP系統對接；

3.業務和財務一體化，應用系統跟財務系統憑證對接。

數據集成

負責業務數據上傳、匯聚，基礎數據（主數據）的下發、分發。AEAI ESB應用集成平臺作為數據交換平臺支持應用間批量數據交換和數據庫間的數據交互，包括數據的抽取、轉換和導入操作。同時MDM不需要向不同的業務系統請求主數據的獲取、同步，只需要通過AEAI ESB進行數據分發、下發等操作即可獲取這些數據。

典型場景：

1.企業數據整合或數據中心建設；

2.數據交換平臺項目，輔助主數據管理項目做基礎數據分發。

服務平臺

用于微服務體系架構中的Rest服務開發、API網關、服務代理、服務監控、服務統計、服務超市。具體表現為分布式部署的ESB（可以放置于Docker容器中），實現微服務體系架構下的Rest服務開發、Rest服務組合、Rest服務代理，通過管理控制臺注冊代理其它系統提供的Rest服務，提供對Rest服務的運行監控、服務的啟停功能、對代理服務每次調用情況的監控等。

典型場景：

1.前后端分離技術架構下，做為Rest服務的開發平臺；

2.OpenAPI運作模式下的服務治理、監控、統計、流量控制。

平臺協同

從業務系統實時獲取相關數據，為Portal提供數據服務、BPM提供數據回寫，協作MDM、IDM做數據分發，為其它平臺提供數據基礎和服務注冊查詢。ESB企業服務總線對SOA整合架構的實現起到支撐作用，數據門戶中，ESB從業務系統實時獲取相關數據以XML或者JSON格式為門戶平臺中各圖表組件、表格組件提供數據服務；業務流程重組中，ESB負責從各異構系統中動態獲取表單數據，以JSON方式為BPM提供業務數據，在流程審批操作時，實現業務數據狀態的回寫等。

典型場景：

1.企業業務流程重組項目支撐BPM實現應用對接機制；

2.統一門戶中為圖表、列表、表格等前端展現組件提供數據服務；

3.SOA綜合集成項目，支撐各個平臺，為其提供服務。

區別聯系分析

1ESB與API網關聯系

SOA是一種理念，它的主要特性是面向服務的分布式計算，服務間松散耦合，支持服務的封裝，服務注冊和自動發現，以服務契約方式定義服務交互方式。但是SOA并沒有定義出具體的實現方式，目前有兩套SOA理念的實現方式：中心化和去中心化，這兩套架構并沒有優劣之分，還是要針對企業的根本訴求。

SOA中心化的實現方式就是ESB，ESB的根本訴求是為了解決異構系統之間的連通性，通過協議轉換、消息解析、消息路由把服務提供者的數據傳送給服務消費者。AEAI ESB企業服務總線不但可以解決異構系統的集成難題，隨著微服務的興起，ESB還可以開發微服務，設計微服務接口的限流、代理、轉發以及安全等功能，但是ESB并不是微服務中的API網關，微服務可以理解為是ESB中重要的一部分。

SOA去中心化實現方式的根本訴求是擴展性，實現方式就是微服務。分布式服務框架，主要有dubbox、spring cloud，實現后端服務治理的功能。

2ESB與API網關區別

現從ESB和API網關的使用場景、傳輸對象、服務契約、實現方式、交互性以及安全層次進行區別分析。

使用場景在2模塊已經詳細介紹，在此不做過多贅述，從傳輸對象上講ESN傳輸的是XML、JSON以及消息格式，而網關是傳遞JSON對象格式。ESB是將自己服務和接口契約發布到服務注冊中心，一邊服務使用者可以發現和訪問該服務，網關則是通過文檔進行約束。

在其實現方式上二者也是有很大區別的，ESN可以通過Http、WS、MQ、Restful等方式實現，而網關是通過Http及Restful實現，較為單一。

在功能上二者的區別如下。

ESB提供了服務總線的基礎架構，提供系統一致性、安全性、可靠性，以及性能和擴展能力保障的基礎技術手段。ESB提供了基礎的集成服務，包含了應用集成、數據集成。提供內置的各種公用服務。例如渠道認證服務，日志服務等公用服務。ESB提供了服務配置管理的前臺工具集合，并提供行業的服務規約標準。ESB提供了多角度的系統實時監控與交易報表，提供用戶定制的告警。提供了多種安全機制并支持和第三方安全系統的有效集成，提供有效的安全監控機制。

在功能上API網關有API的全生命周期的管理，包括API的創建、發布、下線和刪除等生命周期管理功能。其調試工具使用頁面調試工具驗證API的連通。在限流上用于管控API的請求頻率、用戶的請求頻率和應用的請求頻率，流量控制的時間單位可以是秒、分鐘、小時或天，并且允許設置特殊的應用。在監控功能上可以監控API請求次數、API調用延遲和API錯誤信息。