API網關Kong

網關是什麼，爲何咱們須要網關?

網關比如咱們現實生活中的大門，咱們要天天出門上班，下班回家都要經過大門進出。在網絡世界中網關實際上起着控制流量進出的做用。咱們日常使用電腦訪問互聯網，路由器承擔了出去流量的網關的工做，在流量到達網關後，網關使用NAT技術完成了源地址轉換。（能夠理解爲出門前換了一雙鞋子）
當客戶端流量到達服務端以後，也須要進入服務端的網關進行處理，這個網關一般也叫web反向代理，一般爲了提升性能和安全考慮，不會直接把web中間件的端口直接暴露給用戶
在服務端網關這層一般要完成認證、鑑權、流控等相關環節後進行路由轉發給後端的web中間件處理，最終再將結果返回給客戶端

目前咱們的用的網關是啥？有什麼優缺點？

市面上的網關產品或者解決方案主要分軟件、硬件兩種。硬件主要以F5爲表明，軟件則以nginx、openresty、kong等爲表明。咱們目前的全部項目均使用nginx來作服務端的網關

優勢：

配置相對簡單，參考文檔和配置樣例多
官方和第三方的模塊豐富，可擴展性強
性能表現優異，系統開銷低，併發吞吐能力強

缺點：

項目多，項目間相同的配置大量存在，配置文件可維護行差
全部的配置必須人工配置與校驗，自動化能力弱
日誌文件集中在本地，集羣環境下分析工做量大

Kong是什麼？

Kong是一個在Nginx運行的Lua應用程序，由lua-nginx-module實現。OpenResty不是Nginx的分支，而是一組擴展其功能的模塊(整合了Lua模塊後從新發布的nginx) 。Kong和OpenResty一塊兒打包發行，其中已經包含了lua-nginx-module

能夠簡單理解爲：
Kong > OpenResty > Nginx + lua-nginx-module

Kong 是在客戶端和（微）服務間轉發API通訊的API網關，經過插件擴展功能。Kong 有兩個主要組件：

Kong Server ：基於nginx的服務，用來接收客戶端請求，分api（默認8001）和http（默認8000）、https（默認8443）三個端口
Apache Cassandra或者postgresql數據庫：用來持久化存儲操做數據

Kong能解決什麼問題？

Kong最誘人的一個特性是能夠經過插件擴展已有功能，這些插件在 API 請求響應循環的生命週期中被執行。
插件使用 Lua 編寫，Kong的內置插件功能有：

1. 認證插件支持多種認證方式。如：basic auth、key auth、oauth二、hmac auth、jwt、ladp auth、session等
2. 安全插件上支持針對消費者的API ACL策略控制、IP限制、機器人檢測、acme自籤免費證書等
3. 流控插件上支持請求速率限制、請求大小限制、請求中斷、代理緩存等
4. 監控分析插件上支持prometheus、zipkin等
5. 日誌插件上支持接入TCP、UDP、HTTP協議的日誌服務，同時支持syslog、statsd等日誌服務
6. 還有一些第三方的無服務插件，例如aws、azure等。

簡而言之，kong在nginx、openresty的基礎上整合了衆多的功能，實現了API網關服務。
對咱們而言，最直接的是能夠經過api來配置nginx上的虛擬主機，經過使用官方提供的konga webui工具konga，使得配置管理可視化

Kong的幾個重要概念

一、upstream
和nginx裏面的upstream一致
api地址：http://192.168.1.16:8001/upstreams (192.168.1.16是kong服務的ip地址)
重要字段：
name：必須配置，和後面service關聯的時候使用
algorithm：默認round-robin。目前支持三種：round-robin, consistent-hashing, least-connections

API配置示例：建立upstream

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/ \
  --data 'name=fjwjw-dev-web' \
  --data 'algorithm=round-robin'

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/ \
  --data 'name=fjwjw-dev-static' \
  --data 'algorithm=round-robin'

二、target
和前面的upstream相關聯，配置後端web中間件的ip地址和端口，權重等
api地址：http://192.168.1.16:8001/upstreams/fjwjw-dev-web/targets (fjwjw是前面upstream的名稱)
重要字段：
target: 後端web中間件的ip地址和端口,不配置端口默認爲8000
weight：權重

API配置示例：建立target，關聯前面建立好的upstream

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/fjwjw-dev-web/targets \
  --data 'target=192.168.1.60:80' \
  --data 'weight=100' 

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/fjwjw-dev-web/targets \
  --data 'target=192.168.1.61:80' \
  --data 'weight=100'   

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/fjwjw-dev-static/targets \
  --data 'target=192.168.1.13:1457' \
  --data 'weight=100'

三、service
和前面的upstream相關聯，配置虛擬主機相關的信息
api地址：http://192.168.1.16:8001/services/
重要字段：
name：服務名稱
host：和upstream相關聯的字段
port：指定upstream端口
protocol：指定鏈接後端的協議
connect_timeout：客戶端鏈接超時時長
read_timeout: 客戶端讀取超時時長
write_timeout: 客戶端寫入超時時長
ca_certificates：服務端ca證書相關關聯
client_certificate: 客戶端證書相關
retries：後端重試次數

API配置示例：建立service，關聯upstream

curl -i -X POST \
  --url http://192.168.1.16:8001/services/ \
  --data 'name=fjwjw-dev-web' \
  --data 'path="/web"' \
  --data 'url=http://fjwjw-dev-web' 

 curl -i -X POST \
  --url http://192.168.1.16:8001/services/ \
  --data 'name=fjwjw-dev-static' \
  --data 'path=/' \
  --data 'url=http://fjwjw-dev-static'

四、route
api地址：http://192.168.1.16:8001/routes
重要字段：
name：路由規則的名稱
paths：路徑
service：和哪一個service關聯
methods: 支持的http方法（須要大寫）
hosts: 具體訪問的域名

API配置示例：建立route,和前面的service相關聯

curl -i -X POST   \
  --url http://192.168.1.16:8001/services/fjwjw-dev-web/routes   \
  --data 'name=fjwjw-dev-web'  \
  --data 'hosts[]=fjszyws.dev.59iedu.com'  \
  --data 'paths=/web'   \
  --data 'preserve_host=true' \
  --data 'strip_path=false'    

 curl -i -X POST   \
  --url http://192.168.1.16:8001/services/fjwjw-dev-static/routes   \
  --data 'name=fjwjw-dev-static'  \
  --data 'hosts[]=fjszyws.dev.59iedu.com'  \
  --data 'paths=/'   \
  --data 'preserve_host=true' \
  --data 'strip_path=false'

五、consumer
Consumer是使用Service的用戶，其核心原則是爲其添加Plugin插件,從而自定義他的請求行爲.
最簡單的理解和配置consumer的方式是,將其於用戶進行一一映射,即一個consumer表明一個用戶（或應用）
api地址：http://192.168.1.16:8001/consumers

使用API網關須要哪些方面的調整和挑戰

一、 動靜分離徹底拆分
目前咱們項目的先後端的入口都是nginx，域名徹底一致。
api網關實際上更適合處理動態部分的請求。雖然不拆分先後端請求域名也能知足現有需求，但從規範性以及後續靜態資源CDN加速等方面考慮，建議先後端域名進行拆分。
另外，拆分以後api網關和K8S服務集成，能夠使用K8S服務名與後端進行動態關聯。

二、日誌收集與分析
使用api網關以後，全部的項目日誌集中化存儲，運維分析上將帶來挑戰，須要一套完整的日誌解決方案

三、核心插件適配使用api網關以後，客戶端認證、鑑權、流控等工做不須要再由應用程序完成，網關層能夠承擔這部分工做，在認證、鑑權、流控插件上須要適配咱們的項目和應用