使用 api 閘道器作為內部服務面向客戶端的單一入口，是一種普遍採用的架構模式。企業組織通過良好定義的 api 將內部系統向內部和外部使用者公開，通常都會採用 api 閘道器來處理橫向的關注點，包括訪問控制、速率限制、負載均衡等等，來實現安全可控的 api 開放。而被廣泛實踐的微服務架構在提供高度靈活性和彈性的同時，也給 api 閘道器帶來了更多的挑戰。
阿里云云服務匯流排（cloud service bus）新推出微服務閘道器服務（csb micro gateway），針對微服務架構下 api 開放的特點，提供能與微服務環境的治理策略無縫銜接的閘道器服務，實現高效的微服務 api 開放。
相信許多人都熟悉 api 閘道器的概念。作為內部服務面向客戶端的單一入口，api 閘道器有兩個最典型的作用：
1、內外解耦：對客戶端遮蔽內部服務的動態多樣化實現細節，如技術框架、拆分粒度、介面結構、例項狀態等
2、切面控制：讓內部服務能專注在業務邏輯上，集中處理橫向的關注點，如路由、安全、限流、日誌、監控等
實際使用中，對應 api 閘道器所在位置和針對場景的不同，可分成兩種型別：
1、企業級閘道器：位於企業組織的外圍，面對外部的 api 消費者或服務提供者。通常將企業自身的資料和能力 api 化，對外開放，也有允許外部服務入駐的情況。總的來說，以支撐服務入駐、服務運營和服務門戶場景為主，側重解決管理和運營挑戰。
2、微閘道器：位於企業組織內部，面對內部的 api 消費者，可以看做是內部服務之前的最後一道防線。通常按內部服務的業務劃分、物理環境以及技術形態的差異，設立多個微閘道器來分別負責。總的來說，以提供快捷開放、策略控制、服務適配能力為主，側重提公升開發和運維效率。
實際上，企業級閘道器和微閘道器只是兩種使用型別，在關注的閘道器特性上有不同側重，實踐上並非一定需要不同的產品或兩套獨立的部署。
api 閘道器流量特徵
企業級閘道器處理的一定是 api 消費方和後端服務之間的流量，也稱為南北流量；微閘道器一般也只是處理南北流量，當負責的服務本身缺乏註冊發現機制，例如執行在傳統應用伺服器上的不同應用，當相互呼叫需要乙個切面管控時，可以用微閘道器來統一處理服務間流量，也稱為東西流量。
在這裡我們做個定義：用於微服務環境的微閘道器，稱作微服務閘道器。開源產品中，kong、netflix zuul、spring cloud gateway、ambassador 等都可以用來作為微服務閘道器，其中 ambassador 是基於 envoy 構建的，屬於 k8s 原生微服務閘道器。那麼，微服務閘道器有什麼特別的地方，需要解決什麼問題呢？
在微服務架構模式下，小型化、自包含、相對隔離、隨時可執行的應用形態，帶來了極大的靈活性和彈性。但是微服務架構高度動態的服務分布和複雜依賴的特點也帶來了很多挑戰：鏈路複雜，定位故障點困難；乙個服務的故障可能帶來雪崩效應；端到端的測試難以實施等等。對應這些問題，出現了一系列典型的服務治理手段：
在實現上，這些橫向的治理能力大都需要微服務應用配合對接，這些公共機制的實現可以通過微服務框架（例如 spring cloud、dubbo）來提供，讓應用開發能專注在業務邏輯上。或者採用服務網格（service mesh）模式，從應用實現解耦，付出一定效能代價，在應用本地的反向**元件（sidecar）中**流量並處理所有這些邏輯。
由於微服務的呼叫方可能在微服務環境內部，也可能在微服務環境外部，這些橫向的治理能力，有時也需要同時作用到微服務環境與外部之間的南北流量上。這時就需要閘道器的配合。
以服務發現和流量管理這兩個策略為例，考察兩個非常普遍的典型場景：
場景一：流量正確路由到可用的微服務例項
場景二：同步在閘道器上執行金絲雀發布灰度規則
當乙個微服務的例項增加、減少，或者不可用時，閘道器要能把流量正確地路由到可用的微服務例項上；
當微服務更新版本，採用金絲雀發布的時候，灰度策略不但需要在微服務環境內的東西流量上生效，在閘道器上也要執行相同的灰度策略。
很明顯，閘道器進行這樣的配合，如果採用人工操作的方式的話，會帶來很多問題：
首先是實時性差，導致閘道器流量路由的失效和錯誤機率增大；
其次是運維和管理的壓力，對應關係容易錯亂，操作可能失誤錯漏，帶來很大風險。
設想一下，要校對例項的可用狀態，然後在閘道器或閘道器後的負載上掛載、解除安裝對應端點；或在金絲雀發布、中斷、回滾時，在閘道器上進行對應的灰度判定和路由配置。如果微服務稍微多些，運維和管理的難度、風險都是顯而易見的。
因此，微服務的閘道器，需要能夠和微服務環境的治理能力自動化聯動。對應上面的例子，就是要求：
能夠自動基於微服務環境的服務發現策略，將服務請求動態地路由到可用的微服務例項上；
能夠在微服務環境進行金絲雀發布時，自動同步配合執行對應的灰度策略。
也就是說，需要微服務閘道器和微服務環境在服務治理策略上能夠無縫銜接，自動配合生效。對這個要求的支援，也正是新發布的微服務閘道器服務（csb micro gateway）的核心特性之一。
使用阿里云云服務匯流排（cloud service bus）新發布的微服務閘道器服務（csb micro gateway），使用者可以為目標微服務環境快速建立微服務閘道器。指定註冊中心後，微服務閘道器就可以動態感知微服務節點的變更，將 api 請求動態路由到後端微服務。通過控制台可以基於註冊中心的服務列表快速發布 api，支援服務路由規則的動態變更生效，可以方便地管理限流、鑑權、後端負載均衡等控制策略，提供完整的 api 訪問日誌和統計報告，並且支援和後端微服務治理策略的聯動，例如配合微服務應用的公升級發布自動執行灰度路由策略。
新發布的微服務閘道器服務：
微服務閘道器服務（csb micro gateway）是阿里雲上的託管式微服務閘道器服務，提供高度的可用性和穩定性，基於開源引擎，支援開源配置方式。將陸續提供多種微服務閘道器引擎的託管服務，以滿足不同場景的側重需求和使用偏好。
公測首先推出基於 zuul 的服務版本，支援 eureka 註冊中心以及 spring cloud 微服務框架。
將很快支援基於 kong、ambassador 等引擎的託管服務
將很快推出 nacos 等多種微服務註冊中心的支援，將陸續支援 dubbo、gprc 等多種微服務框架
將陸續提供豐富的控制策略，包括各種鑑權方式、流量控制、安全防護、服務組裝變換等等，以及支援使用者自定義實現的策略
將陸續補充企業級閘道器所側重的一些開放管控能力，例如 api 標準規範定義、api 文件、api 測試呼叫、多版本管理等
微服務架構 去中心化的微服務閘道器
這篇文章主要還是想談如果僅僅是內部多個微服務模組間的介面服務整合，是否能夠實現一種去中心化的微服務閘道器，或者也可以理解為實現一種去中心化的輕量服務匯流排能力。要知道，在微服務模組間的介面服務呼叫中，涉及到安全，日誌，路由，監控，限流等能力，我們還是希望有乙個統一的微服務閘道器來處理。在前面的文章裡...
對微服務API服務閘道器的理解
目錄 微服務專字段址 目錄1.簡介 2.什麼是api閘道器 3.為什麼需要api閘道器 4.api閘道器在微服務架構體系中處於什麼位置 4.1 呼叫者眼中的api閘道器 4.2 所處的位置 5.閘道器技術實現有哪些 6.zuul閘道器工作原理是什麼樣的 6.1 整體處理流程圖 6.2 請求生命週期 ...
微服務閘道器的功能簡介說明
微服務閘道器作為微服務後端服務的統一入口 entry point 它可以統籌管理後端服務，主要分為資料平面 data plane 和控制平面 control plane 資料平面的主要功能是接入使用者的http請求和微服務被拆分後的聚合。使用微服務閘道器統一對外暴露後端服務的api和契約，路由和過濾...