GitHub user mfordjody added a comment to the discussion: [提案] Pixiu 在 AI 时代的演进应当聚焦 Dubbo 原生差异化，而非沦为又一个通用 AI 网关
这篇文章的意思是指做成 ai 网关对原有的生态服务造成影响？文章有点混乱，可能是有一半 ai 辅助一半手写的原因，我没太多时间回看，但原本在 kubernetes 模式的设计清晰度还是比较高的，这个项目本质是由控制面和数据面组成的，控制面就是 controller，数据面就是这个 pixiu。那么优势就是在于通过控制面进行聚合通道，然后翻译出数据流通过数据面进行路由传达到后面相应服务。 简单的构图上面是 k8s 模式，下面是本机模式，意思是有普通的服务，也有 pixiu 的 ai 相关的服务，都 input 控制面聚合然后在 output 到 pixiu 在路由到对应的服务，其实本质上没有影响，因为可以对现有服务提供支持，也可以对 ai 对服务提供支持，互不影响。 <img width="2704" height="1172" alt="image" src="https://github.com/user-attachments/assets/6a795c7c-8c8a-4e06-9fe5-901233487e96"; /> 问题在于，数据面怎么和控制面进行长连接？重点还是 pixiu 的数据面，控制面现在是用 configmap yaml 加热更新这个数据面，所以需要做的事把现有的设计梳理完整。那么实现上，xds server 的 ads 聚合流能够去完成这件事情，然后我在 controller 里面实现一个聚合资源框架就差不多了。 这个项目我做的一些设计我必须坦白清楚。那么 pixiu 如何决策应该清晰，在本地和kubernetes模式上有很大的不同，构图简单展示在kubernetes模式和本地模式上的，所以本地的功能层面很重要。影响我在完成这项任务的时候不会做返工。 另外，我看到dubbo-go 作为数据面 + pixiu 做控制面？本质可以参考构图思路。可以把 cli 换成 dubbo-go ai 相关的，我不太清楚 dubbo-go sdk 和你所构想的模式，仅供参考。 GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/990#discussioncomment-18074535 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
