去中心化的API網關是否就是ServiceMesh?
今天談下去中心化的API網關，
對于API網關我前面多篇文章都已經指出過，其本身要實作請求的統一代理，必然是一種中心化的架構，如果不希望中心化你可以走服務注冊中心來實作服務注冊發現和服務請求，最近出現一個新的概念API Gateway Mesh，個人感覺這個概念不太合適，
不合適的原因就是在API網關去中心化后，其常說的服務注冊發現，安全，限流熔斷，日志等微服務管控治理能力本身就通過Sidecar模式下沉到微服務中，也就是說ServiceMesh基本可以實作所有的API網關的能力，除了統一的流量代理和負載均衡，
在我談這個問題前，先參考一段螞蟻金服技術專家關于API Gateway Mesh的一些闡述，具體可以參考公眾號完整文章，
從本質概念上來講，API Gateway 用一句話概括：「Exposes your services as managed APIs」，將內部的服務以更加可控可管理的方式暴露出去，這里的關鍵詞是「暴露」和「可控」，Service Mesh 用一句話概括：「A infrastructure to decouple the application network from your service code」，一種將服務代碼與應用網路解耦的基礎設施，這里的關鍵詞是「解耦」，
在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 一般情況下是用來負載東西流量的Proxy，兩者都具備負載均衡的能力，API Gateway 一般情況下是通過 lvs 、nginx 中心化的一個負載均衡器，我們管這個叫硬負載；而 Service Mesh 一般情況下是通過服務發現，Sidecar 之間是點對點的呼叫，我們叫軟負載，
通信協議上，API Gateway 一般對外接收開放的通信協議，一般是 HTTP、gRPC 等，而且可能涉及到協議的轉換，將 HTTP 轉換成內部的 RPC 協議，而 Service Mesh 代理的內部流量一般是內部的私有 RPC 協議（WebService、Dubbo、SOFABolt、Thrift 等等），在鑒權、流控、安全等控制流量的層面上，對于 API Gateway 來講都是強依賴的，這樣才體現「可控」的特點，而 Service Mesh 代理的內部流量，由于一般處于內網環境，這些控制一般情況下都是弱依賴，
具體文章可以參考，
https://mp.weixin.qq.com/s/o4yrZXhW4tnggctL03t7kw
API網關核心是請求代理
當重新思考API網關的時候，又回到其核心能力即請求代理和負載均衡，因此對于負載均衡和代理這塊一定是中心化的架構，不可能去中心化，但是傳統API網關在攔截了流量后，往往對API介面請求進行了安全，日志，限流熔斷等各種管控治理能力的增加，那么增加的這部分能力是可以Mesh化的，
在上篇文章里面談到API網關和ServiceMesh的另外一個區別就是API網關是內部能力的對外暴露，解決的是南北流量的互動；而對于ServiceMesh往往是解決微服務應用內部，各個微服務之間東西流量的互動，
也就是ServiceMesh并不一定需要具備對外的服務暴露和負載均衡能力，
在了解了這點后，簡化理解就是：去中心化API網關 = 中心化的負載均衡能力+ ServiceMesh去中心化的管控能力，
也就是說API網關的請求代理全部轉移到負載均衡設備來完成，而其他管控治理能力全部下沉到SeriviceMesh架構中的Sidecar來完成，
服務注冊發現和負載均衡配置
當把上面這點思考清楚后，你會看到去中心化網關要解決的核心問題在哪里？
我個人理解其中有一個關鍵能力就是SeviceMesh的服務注冊發現和負載均衡設備或類似Nginix反向代理之間的自動化集成和協同問題，
在云原生和DevOps下可以看到，
當一個微服務應用完成持續交付和自動化部署后，會自動下發一個Sidecar邊車到微服務部署的Pod中，這個邊車里面包括了API網關需要的管控治理代理Jar包，實作流量攔截和各種微服務治理能力，
在Sidecar下發完成后，會自動完成微服務的自動化注冊和接入程序，但是并不會和負載均衡設備協同，完成負載均衡配置資訊的自動化修改，因此在這里需要增加一個關鍵能力，即：
在微服務部署并自動化注冊后，需要自動化更新更新負載均衡設備的路由配置表資訊，也就是這個負載均衡能力不會使用ServiceMesh的負載均衡，而是需要借助獨立的負載均衡組件來完成統一的服務代理和服務對外暴露，
微服務和微服務暴露的API介面
第二點，在談微服務網關和API網關的時候就談到過，微服務網關只管理到微服務組件的粒度，而API網關需要管理到一個個的API介面的細粒度，
對應回ServiceMeshd的解決方案也是同樣的道理，當前的開源Mesh化解決方案往往無法管理到一個個的API介面這個粒度，這部分能力仍然是需要進行定制，即將API網關這部分的能力剝離出來后下沉到Sidecar中來實作，
管理到一個個的API介面服務力度是對Mesh架構做的一個大定制化能力提升，
服務請求端無法下發Sidecar
注意，在同一服務能對外暴露的時候，前端本身具備多樣性，比如前端很可能就是一個APP應用，這個時候可能并沒有辦法采用統一的微服務開發框架，自然也無法在前端模塊下發標準的Sidecar代理模塊，
拿服務訪問安全來舉例說明，
在傳統的API網關架構中，會直接在API網關攔截到請求流量后，進行服務安全檢查，如果沒有訪問權限直接拒絕并回傳，在ServiceMesh架構下，安全能力會在微服務請求模塊來完成，即請求模塊中的Sidecar代理在鑒權不通過的時候直接拒絕，該流量請求并不會達到API介面服務的提供模塊上，
那么在請求端無法下發Sidecar情況下，這部分能力只能是轉移到API介面服務提供端來完成，即請求端不做請求流量攔截和管控能力，
負載均衡和心跳檢測，健康檢查
最后一點，負載均衡實作的時候需要考慮到心跳和健康檢查問題，而負載均衡往往并不具備集群節點的心跳和健康檢查能力，
因此這部分能力仍然需要在Mesh的控制中心來完成，
即Mesh的控制中心在監控檢查發現了不可用的微服務集群節點的時候，應該動態的將該集群節點從負載均衡設備的路由配置表中移出，
如何改造擴展？
簡單來說即基于Ngnix和Istio兩個開源組件來進行擴展和集成，同時自定義一個apiGateway.jar包，通過DevOps程序以Sidecar模式自動化部署到微服務中來實作微服務管控治理，
當前也可以使用OpenRestry來代理Ngnix，但是只使用OpenRestry的負載均衡，服務代理，節點心跳檢查能力，其它管控能力仍然是下發到邊車完成，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/295723.html
標籤：區塊鏈