V2EX › xenoblade 的所有回复 › 第 1 页 / 共 1 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

3 天前

回复了 aoxg2019 创建的主题 › Java › sprung gateway 问题

题外话，我曾今也有类似的困扰，官方讨论中也说了，API gateway 和 BFF 是两个不同的领域，专注的东西不一样，不应当简单的将两个特性糅合在一个服务中，正确的做法应该是 API gateway -> BFF 。

如果楼主和我一样，对如何基于 spring webflux 体系来设计一套 bff 感兴趣，并且希望 API gateway 支持 BFF 特性，可以参考 https://github.com/fizzgate/fizz-gateway-node ，其中 BFF 核心代码在 com.fizzgate:fizz-aggregate 中。

3 天前

回复了 aoxg2019 创建的主题 › Java › sprung gateway 问题

具体实现可以参考： https://github.com/fitzoh/spring-cloud-gateway-114-spike

3 天前

回复了 aoxg2019 创建的主题 › Java › sprung gateway 问题

这个问题官方有过讨论： https://github.com/spring-cloud/spring-cloud-gateway/issues/114

103 天前

回复了 ZZ74 创建的主题 › 问与答 › 有什么办法能够相对快速的去除 webflux RxJava 那套换成普通的写法

底层 IO 操作的 infrustructure 继续使用 reactor ，上层业务改用 kotlin ，通过 kotlin coroutines 对 reactor 的适配器，修改为 kotlin coroutines 的命令式编程写法，调试难度要低很多。

193 天前

回复了 wencan 创建的主题 › OpenAI › 哪个 rag 系统比较靠谱？

我认为这个例子其实应该归类为“RAG VS 长上下文”，恰恰说明了长上下文在有限信息的 QA 中完胜 RAG 。
目前 langchain 系的通用 RAG 系统上限就在那里了，要想达到更高的精确度需要对不同领域进行微调，例如例子中读书场景的 prompt 优化、chunk 分割的人工干预。

242 天前

回复了 yechentide 创建的主题 › 游戏开发 › 想自己做个异度之刃 3 里的 Flame Clock, 有什么现成的库吗, 或者需要学习哪些东西呢

顶着 ID 说说我的想法：考虑到 OP 不了解建模，效率高的办法就是游戏模型提取了，广泛用于 MMD 圈和 3D 打印圈，游戏模型提取的工具链挺全的，网上也有很多教程，需要实践踩坑，不想花时间可以直接咸鱼找人接单。
模型拿到了之后就是渲染了，还需要实现命火粒子效果、命火材质、命火剩余量的动画。
总之 3D 要了解的东西还是挺多的，如果不强求其实 2D 实现起来快很多。。。

348 天前

回复了 Markxu0 创建的主题 › 问与答 › RPC 服务支持 HTTP 和用一个 gateway 来对外提供统一的 http 服务，哪种方式更优雅和常用呢

从我的经验来说，大部分情况下，对外提供的 http 接口应当显式在服务中申明，再补充几个优势：
1. 方便进行外部流量治理；
1. 确定了内部接口与外部接口的边界，外部接口的定制化更加灵活；
2. 项目交接时，代码即接口文档；

而 gateway http to rpc 适配器的方式可以作为特殊情况下的补充（前提是该体系有成熟的解决方案以及丰富的线上使用案例）：
1. 老项目需要在不改动不重启的情况下快速的将 rpc 接口以 http 协议提供外部调用；
2. gateway 有专门的团队维护，希望系统内只关注 rpc 流量治理，减少 http 接口相关的开发部署成本；

2023-11-14 13:34:14 +08:00

回复了 jimisun 创建的主题 › 问与答 › 关于拖拉拽实现开发功能的低代码平台

正好年初也集中调研过流程编排这个领域，根据楼主的需求我推荐 Camunda8 ，说一下我的理解：
优点：1. 基于 java 开源； 2. 基于 Bpmn 模型同时支持手动流程与自动流程（不支持部分 Bpmn 特性）； 3. 提供大量组件，可自定义，已经看到国内企业基于 Camunda8 封装的低代码平台在卖了。
缺点：1. Bpmn 模型设计之初就是为了解决不同人员/角色的工单流转，并不适合做业务编排，实现复杂逻辑时难免捉襟见肘； 2. 由于采用消息队列（自研消息队列 zeebee ），性能（时延）不如命令式编程； 3. 由于业务低代码平台改变了开发方式，所以要想达到支撑线上业务的水平，能需要对接和开发大量 DevOps 相关的能力； 4. 为了保证兼容性和灵活性，业务最终产物必然是大量流程、配置和脚本混杂的 xml 文件，将随业务发展超过代码的维护成本。

目前我已经释然了，在大部分项目方向规划不明确，对 PaaS 没有达成业界共识的情况下，业务低代码平台就是伪需求，难以推广和发展。