文章目錄

• 微服務
• 何為微服務
• 微服務誕生的背景
• API閘道器
• 何為API閘道器
• 市面上的API閘道器工具：
• 二者的聯絡

微服務

何為微服務

微服務架構是一種將單應用程式作為一套小型服務開發的方法，每種應用程式都在其自己的程序中執行，並與輕量級機制（通常是HTTP資源的API）進行通訊。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些服務的集中化管理已經是最少的，它們可以用不同的程式語言編寫，並使用不同的資料儲存技術。

在微服務架構風格中，一個大應用被拆分成為了多個小的服務系統提供出來，這些小的系統他們可以自成體系，也就是說這些小系統可以擁有自己的資料庫，框架甚至語言等，這些小系統通常以提供 Rest Api 風格的介面來被 H5, Android, IOS 以及第三方應用程式呼叫。

但是在UI上進行展示的時候，我們通常需要在一個介面上展示很多資料，這些資料可能來自於不同的微服務中，舉個例子。

在一個電商系統中，檢視一個商品詳情頁，這個商品詳情頁包含商品的標題，價格，庫存，評論等，這些資料對於後端來說可能是位於不同的微服務系統之中，可能我後臺的系統是這樣來拆分我的服務的：

產品服務 - 負責提供商品的標題，描述，規格等。
價格服務 - 負責對產品進行定價，價格策略計算，促銷價等。
庫存服務 - 負責產品庫存。
評價服務 - 負責使用者對商品的評論，回覆等。

微服務誕生的背景

在開始介紹微服務風格（microservice style）前，比較一下整體風格（monolithic style）是很有幫助的：一個完整應用程式（monolithic application）構建成一個單獨的單元。企業應用程式通常建立在三個主要部分中：一個客戶端使用者介面（由使用者計算機上的瀏覽器中執行的HTML頁面和JavaScript組成）資料庫（包括插入常見的通常是關係資料庫管理的多個表系統）和一個伺服器端應用程式。

單體應用程式可以比較容易地構建，而且是以更小的程式碼庫來開始。我們可以在同一個程式碼庫中構建和開發所有內容，這意味著我們不用擔心模組化以及如何把不同的元件放在一起來共同工作這些事情。而且測試起來也簡單。通常當我們測試一個單體應用時，我們一開始就只面對一個應用，然後測試我們整合的單元測試。我們只需要面對一個應用就夠了。而且，很多IDE對單體應用已經支援的非常好了。比如Eclipse圍繞著單體應用就提供了很多成熟的測試工具，包括idea也是。

但，隨著程式碼量的急劇膨脹，我們把所有的都放在一個程式碼庫裡顯然不是一種理想的選擇。隨著時間的推移，越來越多的功能需要構建進去，程式碼越來越多，在一個地方跟蹤程式碼將變得更加的困難。

由於這些原因，團隊在一個大的程式碼庫上迭代將會變慢。再來說個事情，比如我現在要更換資料庫儲存方案，或者想要使用一種新的技術。在單體應用中，這樣的改動通常是非常痛苦的。

由於上面所有的原因，你開始擴張你的組織。然後發生的事情就是團隊內部溝通成本變得更昂貴，因為理解程式碼庫裡的程式碼究竟是幹什麼的變得更加困難。

這也是微服務誕生所要解決的問題。

API閘道器

何為API閘道器

API閘道器是一個伺服器，是系統的唯一入口（也是微服務領域中重要的元件之一）。是大型分散式系統中，為了保護內部服務而設計的一道屏障，可以提供高效能、高可用的 API託管服務，從而幫助服務的開發者便捷地對外提供服務，而不用考慮安全控制、流量控制、審計日誌等問題，統一在閘道器層將安全認證，流量控制，審計日誌，黑白名單等實現。閘道器的下一層，是內部服務，內部服務只需開發和關注具體業務相關的實現。閘道器可以提供API釋出、管理、維護等主要功能。開發者只需要簡單的配置操作即可把自己開發的服務釋出出去，同時置於閘道器的保護之下。

簡單地說，API閘道器就是API們的管理者，例如能防止你要開放的API被惡意請求之類的…順便再加上了一些負載均衡、身份驗證的功能。

亞馬遜API圖：

市面上的API閘道器工具：

目前業界也有多款成熟的API閘道器可用:Kong、Tyk、Zuul、Traefik、Spring、Cloud Gateway等等

二者的聯絡

微服務閘道器。微服務的概念最早在2012年提出，在Martin Fowler的大力推廣下，微服務在2014年後得到了大力發展。 在微服務架構中，有一個元件可以說是必不可少的，那就是微服務閘道器，微服務閘道器處理了負載均衡，快取，路由，訪問控制，服務代理，監控，日誌等。API閘道器在微服務架構中正是以微服務閘道器的身份存在。

Ok，為什麼我們需要一個API閘道器呢？

如圖所示，它展示了一個樂隊，然後有個指揮家，下面一堆人（微型服務）演奏自己的樂器。這個指揮家（API閘道器）可以以某種方式來協調我們的架構如何處理請求。

API 閘道器模式意味著你要把API 閘道器放到你的微服務們的最前端，並且要讓API 閘道器變成由應用所發起的每個請求的入口。這樣就可以明顯的簡化客戶端實現和微服務應用程式之間的溝通方式。

以前的話，客戶端不得不去請求Customers，然後再到Orders，然後是Invoices。客戶端需要去知道怎麼去一起來消費這三個不同的service。使用API閘道器，我們可以抽象所有這些複雜性，並建立客戶端們可以使用的優化後的端點，並向那些模組們發出請求。

API閘道器讓我們的客戶端不用再需要知道和關心模組的地址（address）了。閘道器負責來搞這些事情，你只需要知道閘道器就好了。你可以去改變實現而且還可以改變API介面。不過通常來說，你改變介面後，會增加客戶端出問題的風險。

使用API閘道器後，你可以在單獨的層上有效地抽象，這樣你就可以更改實現和介面，同時保持現有客戶端的公共介面相同。這意味著你總是可以做一些調整的事情。

API閘道器對於那些從單體轉變到微服務的應用來說也是一個非常有幫助的工具。如果你現在維護一個單體應用，你就可以把一個API閘道器放到這個單體的最前面，然後你就慢慢地開始把單體拆分成很多的不同的微服務，在這個過程中，客戶端就一直是通過API閘道器來保持自己的運作，這樣讓你的遷移過程更優雅！

API閘道器將隨著時間的推移實現和消費後端的上游service，同時保持客戶端的正常工作。擁有一個API閘道器可以幫助我們實現這樣的過渡。