微服务治理框架

平台基于 K8S Service 和 Kong API Gateway，实现了无侵入式的 Service Mesh（服务网格）微服务治理框架。

img

技术实现原理

平台本身基于云原生技术架构，因此在微服务技术架构的选择上，没有采用 Spring Cloud、Dubbo 等微服务 1.0 的解决方案，而是采用了更适合云原生技术架构的微服务 2.0 的解决方案 - Service Mesh（服务网格）。

在平台的应用运行架构上，租户对应 K8S Namespace，提供隔离的应用运行环境；租户中的每个微服务对应 K8S Service。

K8S Service 提供了服务注册发现、负载均衡、弹性伸缩、健康检查等能力，但是缺少微服务运行时的流量管控能力，因此平台引入了 API 网关 - Kong API Gateway。

在租户中有两层网关：

  • 服务网关：每个租户中有一个统一的服务网关，所有的外部访问一定要经过服务网关，通过安全认证，才能访问租户内部的微服务。
  • 代理网关：对于租户内的每个微服务，会在它的运行的 Pod 里面注入一个代理网关，用于将内部的服务请求接入到上层的微服务治理框架。

这里的代理网关就是 Service Mesh 微服务架构中的 Side Car，是典型的无侵入式设计。无论服务是 Java、Python、.Net 等不同技术架构，不需要修改任何一行代码，通过网关配置就可以实现微服务治理。这也是平台可以支持异构微服务治理的技术基础。

平台基于 服务网关 和 代理网关，对于租户中的微服务应用，无论是内外访问的南北流量，还是服务间访问的东西流量，通通被这两层网关进行了接管。用户只需要进行网关插件的配置，既可以实现安全认证、黑白名单、熔断限流、调用追踪、日志监控等微服务运行时的流量管控能力。

网关监控

以租户管理员身份登录，打开应用服务管理，打开服务的监控面板 -> 网关监控，显示的就是 代理网关 的 Kong Dashboard。

如果是 entry 的监控面板，还会看到服务网关监控，显示的就是 服务网关 的 Kong Dashboard。（服务网关运行在 entry 的 Pod 里）

1718963206021

网关配置

同样在应用服务管理功能中，每个服务的更多选项中，有网关配置的菜单入口，可以进行网关插件的配置。

results matching ""

    No results matching ""