在新浪微博中，運營工程師如果想要創建一個API服務，需要經歷以下流程：
整個流程冗長且低效，難以滿足DevOps低代碼化運維的趨勢。因此，我們希望通過一個管理后臺門戶，使得操作工程師可以在UI界面中輕松管理HTTP API路由和其他配置。
經過深入分析，我們選擇了Apache APISIX作為新的API網關，主要基于以下優勢：
盡管Apache APISIX具備諸多優勢，但在實際使用中仍存在一些不足，無法直接滿足新浪微博的需求：
因此，我們基于Apache APISIX 1.5版本及其兼容的Dashboard，進行了定制化開發。
定制開發的核心目標是實現完全零代碼的管理方式。所有HTTP API服務的創建、編輯、更新、上下線等操作，均需通過Dashboard完成。為確保安全性，我們禁止直接調用APISIX Admin API，所有操作必須經過UI界面的審核。
在企業層面，我們引入了SaaS ID的概念，用于標識不同的產品線或業務線。通過角色分配，不同用戶可以管理各自的服務，具體角色包括：
在定制版本中，路由規則的創建或修改需要經過審核流程后才能發布。對于重要的API路由，如果發布后出現問題，可以快速回滾到上一版本，且回滾粒度精確到單個路由。
我們實現了與社區理解不同的金絲雀發布功能。相比全面部署，金絲雀發布可以將路由規則的變更限制在特定網關實例上，從而降低風險并實現快速試錯。
金絲雀發布的API路徑為：
/admin/services/gray/{SAAS_ID}/routes在發布過程中，數據合法性會被校驗，并通過事件廣播至所有工作進程。停用時，系統會嘗試從ETCD中還原原始配置，確保服務正常運行。
為降低服務遷移阻力，我們提供了批量導入功能。操作工程師可以通過Bash腳本調用管理后端的API，快速導入服務配置。導入后續操作仍需在H5界面中完成。
大多數微博服務使用Consul KV作為服務注冊與發現機制。為此，我們開發了consult_kv.lua模塊，并在管理后臺提供了直觀的UI界面，方便運營工程師查看和管理注冊節點。
該模塊已被合并到APISIX主分支，并包含在2.4版本中。其流程模型基于訂閱發布模式，支持同時連接多個Consul集群。
遷移過程中，需要將Nginx的上游和路由規則逐一導入網關系統。這是一個繁瑣的過程，同時需要解決Nginx復雜變量的兼容問題。
高度定制化導致后續升級成本較高。例如，從1.x版本升級到2.0版本需要額外的開發和測試工作。
盡管定制開發主要基于內部需求，但我們也在考慮將通用功能貢獻給社區。例如，Consul KV服務發現模塊經過內部打磨后，已提交至開源分支。
通過定制化開發，新浪微博成功將Apache APISIX應用于復雜的業務場景中。盡管面臨遷移和升級的挑戰，但我們相信，通過不斷優化和與社區的合作，可以進一步提升系統的穩定性和可擴展性，為更多企業提供參考。
原文鏈接: https://apisix.apache.org/blog/2021/07/06/the-road-to-customization-of-sina-weibo-api-gateway-based-on-apache-apisix/