GuoLei Song

We wanted to provide more features through the community, but we didn't achieve that; The current version only provides easy access to information and does not provide Sofastack with a...

1、可以暂时不考虑对于 ark 部分的支持，如果在实际的开发过程中，有影响，可以将 ark 部分能力关闭掉（功能要支持插件化） 2、权限部分不需要具体实现，可以基于 Oauth2、spring security 搭一个框架出来，后续托管社区来实现对接具体平台 3、注册中心部分是重点需要关注的，由于 zk 和 sofaregistry 在模型上是不同的，所以在定义模型时，可以适当考虑冗余，由一个模型来呈现 4、重点是对 sofaregistry 的集成，现在的注册信息是通过 rest api 获取的，当数据量变大时，同步获取会有一定延迟，异步去拉则存在一定的时效性问题；这块需要和 sofaregistry 同学一块看下，基于事件方式，由服务端直接推过来是不是更合理。

@ashlee618 我的意见是不绑定到具体的实现上去，可以在接口层面提供好扩展，redis 作为存储的一种实现，基本 map 的 mem 存储也是一种实现，当然也可以扩展其他存储

> TypeError: Cannot read property 'detail' of undefined 这个应该是前端没有拿到状态数据导致，可以具体看下调用的是哪个接口，再做具体分析

应用面板相关功能的思考： - 对于 spring boot actuator 提供的基于 server 端 主动 pull 的模式，优势在于这种模式可以使得 server 端能够及时的获取到目标实例的状态数据，并且不用引入任何缓存来存储获取到的实例状态。但是 pull 模式在一定程度上依赖各个client 端的状态，除此之外也不得不考虑网络的影响（如 server 端无法直接访问 client），使得 server 端运行状态会直接或者间接收到 client的影响（超时、500等）。因此，出于一种对于对 server 端的保护考虑，且在管控的应用状态数据允许一定延迟的情况下，引入缓存来解耦 dasboard client 和 server 之间的关系，并且使得...

> 不过redis场景下如何设计ip维度和应用两个维度的查询方案还需要考虑一下怎么设计。 应用状态数据上报不基于应用维度，只有IP 维度，每个应用实例是一个独立的监控单元。应用层面仅是对于应用实例统计、健康检查状态统计这些。所以基于 prefix_ip_ suffix 这种就能隔离。另外你如果有什么更合理的想法，可以回复到下面

> 统计数据也是靠dashboard定时任务去做的对吧，这种情况的话。 其实不需要，应用实例还是注册到 zk 的，所以这里可以通过监听 ZK 来实现

> 还有那个启停能力的功能，是指RPC在registry上下线，还是说控制网关啊。 这块是应用面板部分，应用启停针对的是应用本身。比如重启应用、下线应用

> > 有没有容易复现的样例供我们参考下 > > 奇怪的是同样的环境，1.8B单卡推理没问题，只要涉及到多卡，就会这样。。😓🤯 > > ```yaml > name: Qwen_vllm > dependencies: > - _libgcc_mutex=0.1=conda_forge > - _openmp_mutex=4.5=2_gnu > - bzip2=1.0.8=hd590300_5 > - ca-certificates=2023.11.17=hbcca054_0 > - ld_impl_linux-64=2.40=h41732ed_0 >...

I would like to take over this task, please assign it to me. @songxiaosheng