search

opensergo / opensergo-control-plane

Universal cloud-native microservice governance control plane (微服务治理控制面)
Apache License 2.0
35 stars 23 forks source link

[DISCUSSION] Control plane extension mechanism｜OpenSergo 控制面扩展机制讨论 #46

Open LearningGp opened 1 year ago

LearningGp commented 1 year ago

背景

opensergo-control-plane作为控制面有很多场景有扩展的需求，比如某些自定义CRD的解析、转换或是应用等。而Go语言本身对扩展机制没有很好的支持，因此我对目前的一些方案设计和实践做了简单整理。

Go插件机制实现方案概述

Go plugin 包

基于Go plugin包实现扩展机制的方案，通过编译.so文件的方式构建插件，主程序借助plugin加载并使用插件，底层基于cgo 机制调用 unix 的标准接口实现。无额外的性能开销，但对插件存在严格的的约束检查。

实践案例：mosn/mosn

基于通讯的多进程方案

插件以独立进程的方式运行，主程序通过通讯的方式调用插件。目前该方案较多的实践是基于 hashicorp/go-plugin 框架包装，以RPC的方式通讯。可能存在一定通讯开销，插件的管理以及进程的管理会引入一定的复杂度。

实践案例：hashicorp/terraform、grafana/grafana中的backendplugin、mosn/mosn等

动态解释执行方案

插件由Go、Lua、JS等语言编写，主程序解释执行。该方案有较多不同语言的支持框架，例如：traefik/yaegi、d5/tengo、yuin/gopher-lua、robertkrimen/otto。其中traefik/yaegi是一个Go解释器，完整支持Go规范。

实践案例：traefik/traefik

WebAssembly方案

插件被编译为WebAssembly，借助WasmEdge/WasmEdge这一WebAssembly运行时，在Go主程序中运行WebAssembly。

关于控制面的插件机制

从控制面的需求出发，对于不同复杂度的插件，可能会适合不同的插件机制 对于复杂度较低的插件，例如计算类插件，这类插件往往只需要主程序单向调用插件即可。并且插件粒度较小、功能上以逻辑计算为主例如某个策略的算法实现。这类的插件的扩展机制我个人倾向于动态解释执行方案或是WebAssembly方案这类复杂度相对较低的方案。Go plugin 包方案由于严格的的约束检查在开源社区中推行存在一定的阻碍，除非某些插件具备较高的性能需求。 对于复杂度较高的插件，例如对于一些用户的内部自研系统，如果想要依靠一个插件将其纳入到OpenSergo的统一管辖中，借由OpenSergo的数据链路实现能力。那么这类插件不仅需要主程序到插件的调用，也需要插件到主程序的调用链路。插件的复杂度较高，粒度也较大。这类的插件我个人倾向于基于通讯的多进程方案，能够满足上述的需求，但是需要做好插件、进程的管理。这部分会需要进一步的详细设计。

欢迎参与讨论

针对以上提到的这些方案，都各有优劣势和使用场景（后续我也会补充更详细的整理文档），opensergo-control-plane可能会需要根据不同的场景采用不同的扩展机制，欢迎大家参与讨论，如果有其他的Go语言扩展机制实现方案也希望大家能补充在本Issues下。

sczyh30 commented 1 year ago

Good idea. Discussions are welcome!

JasonChen86899 commented 1 year ago

提供另外一种思路 通过serverless方式启动注入用户自定义插件 缺点是引入了serverless框架 但是考虑到正常的云平台都会引入serverless机制 所以我感觉可行性较大

sczyh30 commented 1 year ago

提供另外一种思路 通过serverless方式启动注入用户自定义插件 缺点是引入了serverless框架 但是考虑到正常的云平台都会引入serverless机制 所以我感觉可行性较大

可否简单描述下整体的流程、预计的实现方式与成本、运维成本、优点与劣势？

JasonChen86899 commented 1 year ago

提供另外一种思路 通过serverless方式启动注入用户自定义插件 缺点是引入了serverless框架 但是考虑到正常的云平台都会引入serverless机制 所以我感觉可行性较大

可否简单描述下整体的流程、预计的实现方式与成本、运维成本、优点与劣势？

具体流程和实现方式：

  1. 控制面提供新建插件的方式 如新建插件 然后编写插件处理函数
  2. 新建插件后 调用serverless框架启动处理函数也就是目前的控制面插件
  3. 控制面在运行时会检测当前运行的插件函数并调用 根据返回结果继续做下一步处理

成本： 预计成本依赖于用户自身的serveless单个函数运行成本

运维成本： 同serverless运维单个函数成本

优点：

  1. 天然适配多语言环境 各语言插件都能编写
  2. 只需对接serverless平台即可

劣势：

  1. 引入serverless框架 如果用户不具备此功能或者不想开启此功能则无法该种插件
sczyh30 commented 1 year ago

The extension design of Envoy Gateway, FYI: https://github.com/envoyproxy/gateway/blob/main/docs/latest/design/extending-envoy-gateway.md