微服務架構中API網關的角色

【上海尚學堂的話】：本文主要講述了Mashape的首席技術執行官Palladino對API網關的詳細介紹，以及API網關在微服務中所起的做用，同時介紹了Mashape的一款開源API網關Kong。

API網關提供商Mashape的首席技術執行官Marco Palladino預測，儘管它們在命名方面存在差別，但新出現的服務網格並不徹底不一樣於API網關，二者之間的類似性會隨着時間的推移而不斷增加。

Palladino指出，這兩種技術實際上提供了至關相似的功能。API網關,好比Amazon Web Services的API網關或Mashape的開源API網關Kong,已經在過去的十年左右的時間主要用於映射外部流量到內部資源,而最近開發了服務網格——好比Lyft’s Envoy或Uber’s Catylist——主要是在微服務架構中代理內部資源。

「當你想到網關的時候，你一般會想到一個集中的層，一個額外的跳在網絡上處理附加的功能。但這並不必定是真的，」Palladino上週在洛杉磯舉行的2017年MesosCon上發表的講話。網關還能夠提供一種有效的方式來處理跨微服務之間的通訊。他說：「你也能夠在現有的微服務上運行Kong，擺脫額外的跳躍，減小延遲。」

在過去的10年裏，API一直是一種受歡迎的通訊交互方式，Docker使其易於設置微服務架構，其中應用程序和服務是由較小的可交換組件組成。但這些組件之間須要一種方式進行發現與調用。這就是API網關的做用。

API網關「能夠成爲一個抽象層它位於這些微服務中每一個請求的訪問路徑上，」Palladino說道。

網關鞏固了通往系統經常使用功能的全部路徑，好比身份驗證或者服務發現，經過插件都能被網關識別。「插件是一種有效的中間件功能你能動態應用於全部的微服務上，」他講到。

API網關能夠聚合服務請求和這些特性。客戶端能夠作出一個響應，網關能夠將其分解爲多個請求，節省了客戶端自身調用的帶寬。網關一樣還能夠跟蹤這些請求。

從單體應用中改造微服務就像從雞身上製做炸雞塊，還要讓雞保持活着。—@thefosk #MesosCon — The New Stack (@thenewstack) 2017年9月14號

當一個組織開始把一個單體應用拆分爲微服務時，網關能夠將對客戶端的影響最小化。「網關就像裝載單體應用前的一個窗簾。客戶端只會處理網關，而你能夠在窗簾後面解耦你的單體應用，沒必要擔憂更新你的客戶端，」他說道。

他說：「當你沒掌控你的客戶端的時候這個特別有用」。

傳統上，API網關在組織網絡的邊緣上被使用，處理的流量大部分來自於單體應用和外部客戶端之間的交互。然而微服務架構將大部分的流量轉移到內部網絡，由於不一樣的微服務之間要進行交互。「你能夠有外部的客戶端使用案例，但這成爲了當前消費微服務的衆多客戶端之一。」

構建在Nginx這高性能的服務器上，Mashape的Kong是使用最普遍的開源API網關，一個月超過20W運行實例，Palladino講到。使用Kong，Nginx被擴展到中間件上，可以動態提供被一個JSON RESTful調用。(上海尚學堂java培訓原做，請多多支持關注，陸續發佈java相關技術文章）