alaahong commented on issue #613: URL: https://github.com/apache/fesod/issues/613#issuecomment-3422770495
> 你好 [@alaahong](https://github.com/alaahong) ， 我在阅读 Draft flow 时有几个细化的问题想请教： > > 1. **Request Router** 在设计中具体承担哪些职责？它是仅做请求分发，还是也会包含负载均衡、错误重试等逻辑？ > 2. 关于 **Metrics** > > * 计划暴露哪些关键指标（例如请求延迟、错误率、缓存命中率、工具调用次数等）？ > * 暴露指标是否会让 MCP server 本身变得更“重”？ > * 这些指标会暴露给哪些系统？ > > 另外，我之前在调研 fast-excel 时写过一个基于 MCP 的 demo，简单实现了 `list_sheets`、`read_sheet_range`、`cache` 等工具（cache 使用的是 Caffeine 实现）。 👉 [代码仓库](https://github.com/bengbengbalabalabeng/fastexcel-mcp-server) 👉 [Deepwiki](https://deepwiki.com/bengbengbalabalabeng/fastexcel-mcp-server) > > 欢迎提出优化意见或改进建议 🤝 🤝 🤝。 > > Hi [@alaahong](https://github.com/alaahong) , While reviewing the Draft flow, I had a few detailed questions: > > 1. For the **Request Router**, what are its specific responsibilities? Will it only handle request dispatching, or also include load balancing, retries, and error routing? > 2. Regarding **Metrics** > > * which key indicators are planned to be exposed (e.g., request latency, error rate, cache hit ratio, tool invocation counts)? > * Will exposing metrics make the MCP server itself “heavier”? > * To whom will these metrics be exposed? > > In addition, when I was exploring fast-excel earlier, I created a small MCP demo that implements tools like `list_sheets`, `read_sheet_range`, and `cache` (with Caffeine). 👉 [code](https://github.com/bengbengbalabalabeng/fastexcel-mcp-server) 👉 [Deepwiki](https://deepwiki.com/bengbengbalabalabeng/fastexcel-mcp-server) > > Feedback and suggestions for improvements are very welcome 🤝 🤝 🤝. Thanks for your following. Feel good to meet such proposal in community. I haven't conducted research on popular MCP implementations yet; this discussion is based solely on my current personal observations. 1. The primary responsibility of the Request Router is likely request distribution—routing requests to the corresponding Tool implementation methods. It can perform basic rule validation and centralize exception handling. Functions like load balancing, retries, and circuit breakers can be delegated to external controllers. 2. Whether to expose metrics depends on implementation and practical value. Single, one-off executions may not warrant metric introduction, but they become more useful in scenarios with scaled, repeated calls. Basic metrics like execution duration, resource consumption, and throughput can be implemented at the finest granularity. Alternatively, observability can be exposed simply by launching agents. 3. A quick glance at the accompanying code repository suggests it might be a bit heavy? While leveraging SpringAI offers efficiency benefits, introducing SpringCache while also manually setting cache via utility methods seems somewhat at odds with the JSR107 philosophy. Additionally, could Fesod's unique strengths be leveraged more? For instance, efficient reading of massive datasets? Otherwise, if only basic functionality is provided, POI agents might be more mature. Also, consider implementing unit tests—such as using Fesod for logic and cross-validating with POI. --- 我还没有针对流行的MCP实现做调查，仅凭个人当前感觉进行讨论 1. Request Router的职责可能主要负责分发请求，既将请求路由给对应的Tool实现方法，可以做一些简单的规则校验，可以统一异常管理；负载均衡、重试、熔断等可以交给外部控制。 2. 暴露指标是否重取决于实现的方式以及是否有意义，单一的单次的执行可能没有太大的引入指标的必要性，在成规模多次数调用的场景下可能更有用。最小粒度可以尝试实现执行时长、资源消耗、吞吐量等基本指标，也可以简单地通过agent等启动的方式仅暴露可观测性； 3. 简单看了下附带的代码仓库，有点重？基于SpringAI的好处自然是实现的效率，但是，诸如引入SpringCache的同时又采取手动Util Set Cache的方案是否不太适配JSR107的思路？同时，还可以更多发挥Fesod本身的特色？譬如高效读取海量数据？否则仅提供基本功能的话，POI的agent可能更成熟？同时，可以考虑实现一些单元测试，譬如采用Fesod实现逻辑，通过POI交叉验证等； -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
