前言須知：
從0.13開始 kong就棄用的api改用service來組織api
- 增加了service Route Upstream Target
- service 相當於原來的api,但是沒有路由信息,可以直接掛載物理host,也可以掛一個Upstream的host
- Route指kong的路由實體。Route是Kong的入口，定義了請求的匹配規則，路由到指定的服務。就是專門定義外部訪問的分發hosts,strip_path,preserve_host,protocols,甚至method都在這里定義,和service關聯
- Upstream,這個是新東西,一個虛擬的后端服務, 需要結合Target一起使用, 好處是可以在這里就完成負載均衡,還有健康檢查
- 給Upstream添加實際的物理節點,實現的負載均衡
Kong 的管理方式
Kong 簡單易用的背后，便是其所有的操作都是基於 HTTP Restful API 來進行的，Kong 在port上公開了RESTful Admin API:8001，使用它可以動態地添加和刪除API以及使用基於插件架構的Nginx/OpenResty的功能。
kong的操作及功能實現圍繞下面的知識點展開。
1. kong的關鍵術語
Service：
Service 顧名思義，就是我們自己定義的上游服務，通過Kong匹配到相應的請求要轉發的地方
Service 可以與下面的Route進行關聯，一個Service可以有很多Route，匹配到的Route就會轉發到Service中，
當然中間也會通過Plugin的處理，增加或者減少一些相應的Header或者其他信息
Service可以是一個實際的地址，也可以是Kong內部提供的upstream object
Route：
Route 字面意思就是路由，實際就是我們通過定義一些規則來匹配客戶端的請求，每個路由都會關聯一個Service,
並且Service可以關聯多個Route，當匹配到客戶端的請求時，每個請求都會被代理到其配置的Service中
Route作為客戶端的入口，通過將Route和Service的松耦合，可以通過hosts path等規則的配置，最終讓請求到不同的Service中
例如，我們規定api.example.com 和 api.service.com的登錄請求都能夠代理到10.11.11.11:8000端口上，那我們可以通過hosts和path來路由
首先，創建一個Service s1，其相應的host和port以及協議為http://10.11.11.11:8000
然后，創建一個Route，關聯的Service為s1，其hosts為api.service.com, api.example.com,path為login
最后，將域名api.example.com和api.service.com的請求轉到到我們的Kong集群上，也就是我們上面一節中通過Nginx配置的請求地址
那么，當我們請求api.example.com/login和api.service.com/login時，其通過Route匹配，然后轉發到Service，最終將會請求我們自己的服務。
Upstream：
這是指您自己的API /服務位於Kong后面，客戶端請求被轉發到該服務器。
相當於Kong提供了一個負載的功能，基於Nginx的虛擬主機的方式做的負載功能
當我們部署集群時，一個單獨的地址不足以滿足我們的時候，我們可以使用Kong的upstream來進行設置
首先在service中指定host的時候，可以指定為我們的upstream定義的hostname
我們在創建upstream時指定名字，然后指定solts(暫時不確定具體作用)，upstream可以進行健康檢查等系列操作。這里先不開啟（還沒有研究）
然后我們可以再創建target類型，將target綁定到upstream上，那么基本上我們部署集群時，也可以使用
Target：
target 就是在upstream進行負載均衡的終端，當我們部署集群時，需要將每個節點作為一個target，並設置負載的權重，當然也可以通過upstream的設置對target進行健康檢查。
當我們使用upstream時，整個路線是 Route >> Service >> Upstream >> Target
API：
用於表示您的上游服務的傳統實體。自0.13.0起棄用服務。這里就不在深入了解
Consumer：
Consumer 可以代表一個服務，可以代表一個用戶，也可以代表消費者，可以根據我們自己的需求來定義
可以將一個Consumer對應到實際應用中的一個用戶，也可以只是作為一個Service的請求消費者
Consumer具體可以在Plugin使用時再做深入了解
Plugin：
在請求被代理到上游API之前或之后執行Kong內的動作的插件。
例如，請求之前的Authentication或者是請求限流插件的使用
Plugin通過Admin API配置，可以和Service綁定，也可以和Route以及Consumer進行關聯。
2. 如何通過配置KONG API實現對目標(API或應用)的訪問
其實用nginx的配置去舉例KONG API 是有些差異的，這里只是通過nginx比較形象的讓你理解kong的service、route以及其他相關聯的對象。
我們來看一個典型的Nginx的配置對應在Kong上是怎么樣的，下面是一個典型的Nginx配置
upstream helloUpstream {
server localhost:3000 weight=100;
}
server {
listen 8000;
location /hello {
proxy_pass http://helloUpstream;
}
}
下面我們來看看其對應Kong中的配置
# 配置 upstream
curl -X POST http://localhost:8001/upstreams
--data "name=helloUpstream"
# 配置 target
curl -X POST http://localhost:8001/upstreams/hello/targets
--data "target=localhost:3000"
--data "weight=100"
# 配置 service
curl -X POST http://localhost:8001/services
--data "name=hello"
--data "host=helloUpstream"
# 配置 route
curl -X POST http://localhost:8001/routes
--data "paths[]=/hello"
--data "service.id=8695cc65-16c1-43b1-95a1-5d30d0a50409"
這一切配置都是通過其Http Restful API 來動態實現的，無需我們在手動的 reload Nginx.conf 。開發的同學看到這是不是感覺到很幸福了。
在上述的配置中涉及到了幾個概念：upstrean、target、service、route等概念，它們是Kong的幾個核心概念，也是我們在使用Kong Api時經常打交道的。
kong的重要對象關系
從上面的配置及字面解釋大概能夠推測出他們的職責：upstream，target，service，route，他們便是 Kong 最最核心的四個對象
upstream 是對上游服務器的抽象；
target 代表了一個物理服務，是 ip + port 的抽象；
service 是抽象層面的服務，他可以直接映射到一個物理服務(host 指向 ip + port)，也可以指向一個upstream來做到負載均衡；
route 是路由的抽象，他負責將實際的 request 映射到 service。
他們的關系如下：
- upstream 和 target ：1 對 n
- service 和 upstream ：1 對 1 或 1 對 0 （service 也可以直接指向具體的 target，相當於不做負載均衡）
- service 和 route：1 對 n
kong對象特征
更多知識參考：
代理參考
負載平衡參考
Admin API: 詳解各個對象的相關內容
[sleepy↓]