前言
對於API網關，業界貌似對它進行下划分，有下面幾個分類/場景。
- 面向Web App
- 面向Mobile App
- 面向Partner OpenAPI
- 面向Partner ExternalAPI
- 其他。。。
在18年8月份的時候，有幸用.NET Core 2.1重構了一個對外的業務網關項目，這個項目的作用其實就是將公司內部能提供的數據能力公開出來，可以讓有需要的公司使用。
這個項目按照分類，應該是要歸類到 面向Partner OpenAPI 。
這個項目剛開始是用Nancy寫的，那個時候要向外提供一個新的能力的時候，都是要加這個能力的代碼，發布后才能真正的對外提供，不過當時對外提供的東西比較少，負責的同事也要閃人了，所以也還是可以接受。
在18年7月份的時候，越來越多的能力要對外提供，而且每次都要改代碼，受不了，就提出了重構。
這個項目目前每天大概有1500萬左右的有效調用量，部署在6台4c4g的CentOS虛擬機上面(其實用不了那么多機器，每台機器的基本都是20%以下的cpu和10%左右的內存)，用Jexus去托管。大入口是Nginx，所以最后的流向是：
Request -> Nginx -> Jexus -> dotnet
下面就分別來說說這個網關涉及到的一些東西。
統一鑒權
鑒權這一塊用的還是很古老的做法，用的是用戶名和密碼的方式來處理，這個可以理解成是驗簽的一個過程。
這里支持兩種形式，一種是參數明文傳輸，還有一種是參數加密傳輸。
其實就是有部分公司覺得我不能直接傳明文的123給你，要傳一個加密后的123，讓你解密然后去處理。
服務限流
限流功能就是限制調用方過於頻繁的調用，這個限制，根據業務場景分為秒、天、月三個層級。
不同調用方，不同數據服務都有不同的限制，這個是基於Redis來實現的。
路由轉發
路由轉發用的是HttpClientFactory。
剛開始的時候還是用steeltoe來處理服務注冊和發現，不過發現並不好用，然后也有很多服務沒有接入 Eureka， 所以最后就沒有處理服務注冊和發現，而是直接用域名的方式來請求。
參數重組
用戶的請求參數基本上都會是透傳給下游服務，當然不能排除會有一些特殊的需求。
舉個簡單的例子說明一下，好比只想讓調用方查廣州的天氣，不想讓他查深圳的天氣，而下游服務是這兩個城市都可以查的，所以要有一些特殊的參數去告訴下游服務。
這個時候，我們就需要對用戶的入參進行一次重組，重新構造了一個JSON參數丟給下游服務，相當於特殊情況會有固定的參數格式給到下游服務，用的是JObject來處理。
鏈路跟蹤
由於調用鏈有的時候非常復雜，為了記錄調用方一個請求完整的調用鏈，網關這邊會生成一個traceId在請求頭，路由轉發的時候會一起發過去。
不同服務在記錄日志的時候就會把這個traceId也統一記錄起來，這樣所有的日志都可以通過這個traceId從日志系統中找到。
熔斷降級
下游服務不一定能保證 7*24 小時的正常服務，有時可能因為數據庫處理超時，網絡請求超時，從而造成在一段時間內，不能正常響應。
這個時候網關就不應該每次都去真正的請求服務，而要斷開一段時間，直接返回失敗給調用方。
這一塊是結合 HttpClientFactory 和 Polly 來實現的，省了很多麻煩。
服務計次
計次可以說是這個網關的一大核心，因為要賺錢，要收調用方的錢。錢基本就是按次數算出來的。
之前寫過一篇博客，實現是類似的。
業務指標監控
需要知道最近某段時間范圍內，不同調用方，不同數據服務的調用情況(成功，失敗，有效，總次數等)
這里用的是prometheus，程序負責寫指標數據，prometheus會去拉取這些數據，然后結合Grafana來做成不同的看板來展示。
日志記錄
日志記錄為分兩大類，一類是程序日志，一類是調用日志。
程序日志目前是拓展NLog，把數據丟到Kafka，然后運維那邊會抽數據到Elasticsearch。
為了避免Kafka抽風，所以丟數據到Kafka失敗的話，會落盤到日志文件，然后由Filebeat收集，然后丟到Elasticsearch。
最后的展現形式是 graylog， 大概如下
調用日志是和調用方結算的依據之一，所以這個的重要性還是挺高的。
目前用的是異步寫入加容錯。調用日志最終是落到數據庫歸檔。
迭代更新
更新對一個程序來說是必不可免的，所以有一個好的發布流程可以減少一些困難。雖說重構后，這個項目也就更新了3次。
這里用的是Go CD來發布的，從測試到預發再到生產，流水線的操作。
總結
雖然這個項目挺小的，但是也可以用“麻雀雖小，五臟俱全”來形容。
最后問問，最近有那位大佬招小弟嗎？有的話可以聯系一下我哈。