本系列內容是來自Mashape.com的Marco在nginx.conf上的一次演講。

本系列第一部分（上集）主要介紹了單體和微服務之間的差別，以及為什麼我們需要一個API閘道器等等。

本系列的第二部分（也就是本集）主要關注Mashape.com的API閘道器，Kong，這個框架。我們來看看怎麼使用這個框架。

ok，開始吧。

目錄

23:52 API閘道器和Kong能為你做些什麼（API Gateways and Kong Can Help）

API 閘道器可以通過實現一些中介軟體來解決一些問題，這些中介軟體的功能你就不用再到每個service中實現了。你也是知道的，不同的團隊使用不同的方式來實現了不同的微服務。

如果你不去做一些中心化和抽象化的事情，你將會死於不同的認證方式以及不同的速率限制實現，五花八門。你肯定希望避免這樣的糟糕局面。

API閘道器不僅可以幫你解決API的管理部分，而且還可以解決下面兩件事情：

·分析（Analytics） –  API閘道器可以和你的分析基礎設施保持透明的互動和通訊，因為API閘道器是每個請求（request）的入口，必經地。API閘道器可以看到所有的資料，可以知道經過你的service的流量。這就相當於你有一個集中的地方，你可以把所有的這些資訊push到你的監控或分析工具，比如Kibana或者Splunk。

·自動化（Automation） –閘道器還有助於自動化部署，還可以幫助你實現自動化登入驗證（on boarding）。 什麼是登入（on boarding）呢？ 如果你有API，並且你希望有身份驗證，你可能需要一些功能可以允許使用者為該API建立登入憑據（credentials）然後開始使用（消費）API。 開發人員入口網站或你的文件中心等都可以與閘道器整合來配置這些憑據（credentials），這樣你就不用從頭開始構建一些功能了。

25:49 What is Kong?

那麼，Kong是一個什麼東東呢？它是一個開源的API閘道器，或者你可以認為它是一個針對API的一個管理工具。你可以在那些上游service之上，額外去實現一些功能。Kong是開源的，所以你可以在Github找到它，你現在就可以下載使用。

26:09 Kong能為我們做什麼？（What Does Kong Do?）

你可以通過Kong把所有的通用功能集中到了一個地方。就像我之前說的那樣，碎片散落在很多個不同的service裡，針對一個重複（通用）的功能實現了不同的版本，糟糕至極。

API閘道器（比如Kong）可以把所有的這些都集中到一個地方，這就讓service的開發變得更加的輕鬆簡單，你只需要安心的關注和業務緊相關的事情。

26:35 Kong的一些外掛（Kong Plug‑ins）

外掛是個什麼概念呢？Plugins。外掛其實就是Kong提供的一些中介軟體，你可以新增到這些上游的service之上。這些外掛可以是安全認證（authentication）、流量控制（traffic control）、日誌（logging）或者是其他轉換功能。

假設你現在有一個SOAP service，你想要暴露一個RESTful介面。API閘道器比如Kong就可以實現這樣的轉換。你不需要告訴你的團隊去改變API的實現來做這樣的轉換。API閘道器可以為你實現這樣的轉換。

27:22 Kong = OpenResty +NGINX

從技術的角度講，Kong可以認為是一個OpenResty應用程式。 你知道，OpenResty執行在NGINX之上，使用Lua擴充套件了NGINX。 Lua是一種非常容易使用的指令碼語言，可以讓你在NGINX中編寫一些可以執行的操作。

OpenResty針對一次API 請求-響應（request‑and‑response） 生命週期中的不同的事件提供了鉤子，所以你可以編寫Lua指令碼程式碼，然後把這些程式碼掛載到那些事件上-比如，一個新的請求（request）正在進入的時候，一個新的請求（request）將要被代理的時候，一個響應返回了的時候。你可以為每個事件編寫定製的程式碼而且你還可以動態的改變請求的內容（requests）和響應的內容（responses）。

【在架構上】我們底層是使用NGINX為Kong提供底層的支援。所有的代理都是由NGINX來完成-這是一個非常強大的能力。而OpenResty則是Kong的核心的核心。它通過這些新功能擴充套件了NGINX，而在這兩種技術之上，Kong實現了叢集(clustering)，外掛(plugins)和可用於管理API閘道器的RESTful API。

像Elasticsearch，你就可以通過API來做一些和資料庫有關的你想要做的事情，Kong也暴露了API，你完全可以通過這些API去操作到Kong的內部，只需要傳送一次HTTP呼叫，然後把響應回來的JSON解析就可以使用了。

這意味著你可以整合Kong到這個連結中（href=https://www.nginx.com/resources/glossary/devops/）Devops以及自動化工具中去。你也可以整合Kong到第三方service中去，以及一些開發者門戶（developer portals）以及其他一些入口工具中。Kong支援把所有的資訊儲存到PostgreSQL或者Cassandra，當然這取決於你要哪一種儲存方案。

Cassandra是最終一致的資料庫。 這意味著如果你有一個由多個節點組成的Cassandra叢集，你儲存資料的話，則最終該資料將傳播到所有其他節點 – 但不是同時[或“立即”]到達每個節點。

Ok，假設現在一個三節點的Cassandra叢集位於DC[data center]1，另一個三節點的Cassandra叢集位於DC2，然後你把這兩個叢集又連線到了一起，保持同步。這種情況下，你在一個數據中心做的任何操作最終都會被複制到另外那個資料中心去。

PostgreSQL使用起來更加簡單。它支援master和slave，但不支援跨DC的多資料中心複製（就是不支援那種masterless架構）。不過，也有一些工具可以幫你實現跨資料中心複製。

30:26 NGINX 配置（Configuration）

由於Kong是建立在NGINX之上的，所以你可以訪問到Kong上的NGINX的配置，而且還可以輕鬆替換現有的NGINX的一些實現，並且還依然能在Kong上執行那些老的功能。

這就它的工作原理：我們有NGINX的配置，然後我們可以修改。

然後，Kong自帶的配置可以包含在NGINX配置內。

在Kong的配置中，它會使用一些OpenResty的指令，比如… access_by_lua_block and header_filter_by_lua這些。

當你建立了一個基於Kong的外掛，你都可以掛載到在請求-響應一個生命週期中的那些事件上。

Kong也支援一些商業外掛以及Mashape已經構建好的一些外掛。這些可用的外掛你也可以在getkong.com中找到，或者去github倉庫裡也有。此外，社群一些人也使用他們自己的外掛擴充套件了Kong。

如果你在GitHub上搜索“Kong plug‑ins [或 plugins]”，你還可以找到一些其他的外掛供你使用。

在網站上，我們一般會列舉一些我們認為足夠穩定的可用於生產的外掛，當然了你也可以在GitHub上找到一些成熟的外掛。如果你有計劃要使用Kong,我還是鼓勵你們多去擁抱社群，拿社群已經成熟的外掛，這樣你就不用重複生產輪子了。

如果你需要做一些非常定製化的開發，你當然可以擴充套件Kong，你可以建立你自己的外掛，這樣你可以設計成你想要的。這些外掛將會去訪問OpenResty上那些事件，這樣你就可以動態（實時）地改變請求（request）和響應（response）。

你也可以通過Kong傳送請求去第三方的service。假設現在你有一個遺留的認證系統，你想要整合到API閘道器。你可以建立一個外掛，可以讓每個請求都路由到那個認證系統。然後在外掛中處理[認證（authentication）]請求，然後返回響應，這樣的話，客戶端就只需向API發出請求。

32:53 Kong的入口（Kong Entry Points）

Kong有兩個關鍵入口。第一個叫做Proxy入口，就是消費者和客戶端想要去消費上游的service們，可以訪問預設的8000埠（或者SSL是8443，）來消費；第二個重要入口就是Admin API，是執行在8001埠上的，這個埠提供了你想要對Kong進行所有操作的API。

33:30 核心的實體（Core Entities）

演講結束後，我們會快速的演示一下如何通過終端來使用Kong。在這之前，我希望你們能知道，Kong有三個核心的實體，這三個實體是你在API閘道器中總會用到的三個實體。這些實體是一些API，表示你想要嘗試在Kong之後去請求的上游service。

你在Kong之後擁有成千上百的不同的service，我們叫這些service為apis（api們）。

然後，你得有消費者（consumers），其實就是客戶端或者個人開發者，根據你具體的情況 — 總之就是那些想要去消費APIs的傢伙。

消費者（consumer）可以是客戶端app，可以是內部的（只針對團隊內部的）也可以是公開的，也可以是合作伙伴。第三個實體就是外掛（plugins），外掛可以應用於API和消費者之上，來改變中介軟體的運作。

 34:34 外掛配置矩陣（Plug‑ins Configuration Matrix）

舉例來說，你可以讓外掛應用到每個API以及每個消費者（consumer）。如果你希望速率控制應用到每個service，並且速率限制為每秒每個service 200個請求。

或者你讓外掛應用於每個API，但只應用於特定的消費者。比如，你希望外部的每人每秒只能傳送200個請求，但內部app沒有任何的限制。你可以針對一個消費者，或者你可以針對每個API並且每個消費者。你可以靈活的配置這一切。

35:18 多資料中心部署（Multi‑DC Deployment）

這是一個多資料中心部署的使用場景。Kong作為客戶端所有請求的入口。Kong接受請求（request），然後挑選出你想要訪問的上游服務，並嘗試執行與該API相關聯的中介軟體。

舉箇中間件的例子，比如認證外掛，假設它們按照執行順序首先被執行。然後一旦Kong知道哪個消費者正在嘗試使用API，它可以動態地載入所有這些資訊。

Kong只有第一個請求才會去資料庫裡取資訊。 在第一個請求中，Kong將從資料庫中獲取（解析）所有資訊，然後將其快取到記憶體中。 所以第一個之後的其他請求都會在記憶體中處理，這意味著Kong可以非常快，而不會在事務上增加太多的延遲。

如果您有兩個不同的叢集，則需要以某種方式將這些資料中心連線在一起。要同步（共享）的資訊主要是Cassandra節點之間的資料，除此之外就是invalidation（使資料失效）事件。

由於Kong會在第一個請求時快取所有的資訊，如果你在其他的節點做了一些更改將會發生什麼呢？第一個Kong節點是怎麼知道資料不再有效的呢？在我們Kong節點之間，會彼此傳送invalidation（失效、資料非法或叫變更）事件，所以每次你在某個Kong節點上做了操作，比如修改了上游服務的地址，那麼這個節點就會通過傳送一個invalidation事件到所有其他的Kong節點來使那個指定的實體失效。

其他的Kong節點收到失效（invalidation）事件然後刪除這個實體。當一個新的請求進來後，Kong會強制重新去資料庫裡獲取這個資料。