在微服務架構的系列文章中，前面已經通過文章《架構設計之「服務註冊 」》介紹過了服務註冊的原理和應用，今天這篇文章我們來聊一聊「 api閘道器 」。
「 api閘道器 」是任何微服務架構的重要組成部分。有了它我們可以在乙個獨立的模組上方便的處理一些非業務邏輯，可以讓微服務本身專注在自身特定的功能上，使得每個微服務的開發更容易和更快速。
後面還會有文章繼續介紹 配置中心、服務框架、服務監控、服務追蹤、服務治理等。還是那句話，只有將這些基礎設施弄清楚了，微服務實踐的道路才能走的穩、走的遠。
一、為什麼需要「 api閘道器 」？
為什麼做微服務的需要「 api閘道器 」呢？「 api閘道器 」到底有些啥功能呢？我們以前專案結構比較簡單的時候有用到過「 api閘道器 」概念的模組嗎？
其實在我們的專案曾經還是單體應用的時候，雖然沒有「 api閘道器 」的概念，但是一般在專案中都會用到filter/過濾器之類的東西，filter的作用就是把專案中的一些非業務邏輯的功能抽離出來獨立處理，避免與業務邏輯混在一起增加**複雜度。比如 鑑權認證功能、session處理、安全檢查、日誌處理等等。
現在我們採用微服務架構了，在乙個專案中微服務節點很多，如果讓每乙個節點都去處理上面這些 「鑑權認證功能、session處理、安全檢查、日誌處理等」 會多出很多冗餘的**，也會給增加業務**的複雜度，因此我們就需要有乙個「 api閘道器 」把這些公共的功能獨立出來成為乙個服務來統一的處理這些事情。
我們看一下下面這個微服務架構示意圖：
「 api閘道器 」就像是微服務的大門守衛一樣，是連通外部客戶端與內部微服務之間的乙個橋梁。
其主要功能有：
二、「 api閘道器 」原理與應用？
上面聊完了「為什麼需要api閘道器」，我們再來看一下在實際專案中應該如何去應用。雖然我們可以自己去開發一套「api閘道器」，但是如果沒有特殊需求，還是不建議重複造輪子了，市面上有很多成熟的方案可以直接使用，下面簡單介紹一下 zuul、tyk、kong三個比較熱門的開源元件。
以上，就是對微服務架構中「 服務閘道器」的一些思考。
碼字不易啊，喜歡的話不妨**朋友吧。
微服務API閘道器
微服務api閘道器 api閘道器是乙個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。api閘道器封裝了系統內部架構，為每個客戶端提供乙個定製的api。它可能還具有其它職責，如身份驗證 監控 負載均衡 快取 請求分片與管理 靜態響應處理。api閘道器方式的核心要點是，所有的客戶端...
微服務架構中API閘道器的角色
編者的話 本文主要講述了mashape的首席技術執行官palladino對api閘道器的詳細介紹，以及api閘道器在微服務中所起的作用，同時介紹了mashape的一款開源api閘道器kong。本文講的是微服務架構中api閘道器的角色api閘道器提供商 mashape 的首席技術執行官 marco p...
微服務 API閘道器 限流
我們在api閘道器中已經介紹了，限流是保護閘道器的手段之一，和身份認證以及鑑權一起組成安全防禦大閘。其目的是對併發請求進行限速或限制乙個時間視窗內請求的數量，一旦達到閾值就排隊等待或降級甚至拒絕服務。根據上面列出的原因，我們自然知道限流該怎麼限制法，但是具體要怎麼實現呢？也就是該怎麼設計演算法來實現...