緣起

其實很久以前就很想要寫這個系列文，不過在因緣際會之下，兩年前(2023年)鐵人賽反而成為筆者系列文的處女作，撰寫了任務為導向的 Azure DevOps 系列文，也獲得了一個不錯的獎項。兩年前的題目算是讓自己當下腦力激盪，強迫自己在當下思考出組織內到底要如何去使用Azure DevOps Service來完成協作這個任務。

在過去筆者還有一個協助組織導入多年的工具，叫做Kong API Gateway，之所以會想要撰寫這個工具的介紹文章，其實也是在引入一兩年後，才發現到這個議題其實在企業中無比重要。

筆者是從開發出身的，最早也認為這僅是一個工具，將公司內各個系統的API都集中管理，可以達到安全性與監控的目的。所以企業應該是用來做好各項管控，以避免公司重要的API資訊外漏而已。

不過多年前如此思考的我，顯然還是太年輕了，實際上一個優秀的API Gateway，從DevOps 的角度來看看是可以從多個面向協助組織。如提高API資訊安全，降低開發人員負擔，協助維運人員各項監控與追蹤任務。

另外，Kong API Gateway 是開源軟體，有非常多的功能與Plugin是免費的，用來不花費成本的學習，絕對是最佳的鐵人賽參賽素材。

開發人員撰寫API常常遇到的一些痛點

一般狀況

最早自己在寫程式的時候，通常除了需求的Feature以外，工程師都還會需要實作非常多非需求面的部分，簡單舉一些例子如下：

1. Logging：不論是API還是Web，只要是要服務使用者的，為了可以查找出程式問題所在，一定需要實作Logging，因此自己寫程式的時候，通常都會實作Log的留存。從最早自己寫File log，接著使用第三方套件如Nlog 或Serilog寫到本機，最後開始直接透過套件將Log 引入到如ELK平台中作為查錯使用。
2. 認證授權：Web Site通常都會考慮認證授權，例如顧客到電商網站，平台需要辨識來下單的顧客，才可以將後續金流到物流一連串的服務提供到顧客手上。但與Web Site不同的是，非常多的API通常都是企業內部系統對接的一種Interface。早期在區域隔離的觀念下，例如機房與外部網路透過防火牆做實體隔離，因此無法輕易地連線到。這種設計在單一區域網路下，往往都直接將API開通後，就提供給機房內其他系統直接使用。但當使用對象超過一個以上時，API就必須要思考認證授權，至少在服務異常的時候可以根據Log找出是哪個系統搞的鬼。
3. 快取：大多數時候，只要是資料庫夠力的前提，程式設計師通常只需要將資料庫視為一個儲存各種資料的位置，需要的時候就透過SQL直接從資料庫取出即可。但當資料庫成為瓶頸後，除了改善SQL語法或是新增index以外，通常程式設計師還會透過快取的機制，將不常變更的資料存入。一方面可以降低資料庫不必要的I/O，同時也可以提高程式提供服務的效能。

上面簡單列出了三點，其實實務上可能還會因為場景遇到更多可能的需求，例如限制流量、CORS、過濾或轉換、提供監控平台觀測資訊等等，都可能會發生在每一位程式設計師身上。

而如果每個API都要自己實作這些內容其實非常不易，特別是這些非功能性的需求，在驗收當下一般使用者根本不會有感覺，因此遺漏的可能性十分高。

成本與安全性議題

筆者在金融業工作，我常常見到一種API的設計，那就是例如某個商業合作模式要完成，就在該系統上維護一支專屬的API。接著兩邊對開一條專線，讓這個服務可以提供給對方使用。

這種設計邏輯大概就是，將使用API的企業該節點，視為內網的一部分。因此只要這支API被呼叫出問題時，可以大概確定就是該公司做的好事。

但是，電信專線的成本其實十分高昂，加上如果一個合作對象就要維護一組API。那如果此項業務擴展，API服務的節點數就會大幅增加，設計不良的狀況下，工程師就會遇到大量的重工。因此改東忘西，改A壞B的狀況就會屢見不鮮。

而如果企業高層決定要將現有內部的API提供給外部使用者，這些外部使用者可能是合作的商業企業夥伴，或是大型企業中不同的子公司使用，就會開始衍伸出更進階的安全性議題。

原因在於，這些API 或是Web Service 在設計與撰寫的時候，在各方面並未思考過開放與管理方式。這就可能造成各種連入負擔與安全性議題，這時候該怎麼辦？

1. 叫工程師給我改，反正需求開出去就是要辦到？

這可能會造成工程師開發成本大增，而且既有使用對象因為變更無法使用服務的風險提高，可能造成各方面的損失。

2. 就照之前模式，要求工程師每次都重新開一個介面並且拉一條專線？

前面說到電信連線成本其實非常高昂，而且雖說這看起來不會馬上影響到現有使用者的體驗，但不可否認的會造成技術債持續疊加，直到哪天撐不住為止。

甚麼是API Gateway？

圖1-1 API Gateway

上面痛點出現後，這種API Gateway的解決方案就開始出現了。這種解決方案如同上圖，就是希望將原本各自分散的功能，集中在一個平台中一併協助完成。這種平台可以協助幾個事項：

1. 統一收攏區域內的API進出口： 透過服務的收攏，可以在關鍵節點上進行盤點與管理，並進階可以做到安全性偵測與惡意攻擊阻擋。
2. 認證授權集中化： 藉由優秀與彈性的平台，可以根據使用對口的需求，調整授權對象的設定。例如過往已經連線的合作對象，可以根據IP限制來初步設定。新的合作對象則可以協議一種認證方式，來達到最基本的安全性要求。
3. 降低工程師的即刻工作大增衝擊： 如果將突然大量的工作加駐在工程師身上，可能會造成工程師負荷過重而流失人才。但如果又面臨了政策或是主管機關的要求而不得不為，否則企業也可能面臨裁罰的風險。這時一個中介的平台可以協助企業即刻進行需求的調整進行緩解，後續再根據須調整事項進行後續調整。這應該才是最佳的做法。

系列文預期收穫

筆者由於是在DevOps領域較為精熟，因此在撰寫的過程中雖說會藉由Kong作為學習的本體，但主要還是會圍繞在認證授權與可觀測性實踐為主。

身為讀者的你，筆者希望藉由此系列文，帶來一系列的探索與學習，包含了：

• dotnet core api 簡易實作

  • 認證授權
  • 可觀測性
  • Log 匯出

• Kong API Gateway

  • 觀念說明(Service/Route)
  • 認證授權(APIKey/ JWT)
  • 可觀測性
  • Log

• 可觀測性工具實踐

  • ELK
  • Jaeger
  • Promethus + Grafana

• 個案講解

  • 管理實戰：Azure DevOps + Kong 變更管理模式建立
  • 問題排查

  期望大家有一趟愉快的旅程，坐好了~ 出發~~