V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  CodeCaster  ›  全部回复第 2 页 / 共 2 页
回复总数  24
1  2  
@ReinerShir @clf ,非常感谢二位的提醒,我去大致看了一下 LangChain4J 项目的样例,这个项目拥有很多 Star ,的确是一个优秀的项目,但是我们的版本(我们这个模块叫 FEL ,项目整体叫 FIT ,这里是 FIT Expression for LLM 的缩写)相比之下还是有一些特点的:

1. 我看 LangChain4J 主要是流式处理+异步回调,而我们是采用了响应式编程,这意味着我们可以在编排的 AI 应用的任意节点间增加背压;
2. 我们在响应式的基础上增加了 BPM 的相关方法,比如支持并发流、条件判断等,这对于流程编排来说,更自然的在编码级别进行了支持。

非常欢迎讨论交流,我们也会吸取其他框架的优点,欢饮关注点 Star ,推动我们继续~
@lower 有的,其实上面的第二段代码 retrieveFlow 就是这方面的,我们社区的 example 中关于 fel 的部分例子就有,那边可以看代码和文档。不过因为我们现在刚刚开源,对于生态的一些支持还有限,打算接下来会像 LangChain 一样,对生态内容进行补齐,这样,开发者就比较方便实用了~
@wellCh4n 非常感谢支持,因为这部分代码还是比较多的,可以后面空了好好看一下~
微服务接口变化,而造成的调用方也要发生改变,最常规的解决方案,就是老的接口先不变,新增一个全新的接口,所有调用方根据自己的升级节奏逐步升级到新接口,待全部调用方都升级完毕之后,再将老接口下线。
其实,上述问题在微服务体系中非常常见,我觉得这个问题就是微服务架构这种模式造成的,因为不同的微服务本质上是离散的不同个体,他们之间的调用就是他们之间的强依赖关系,既然是强依赖,那么被依赖方发生改变,必然会造成依赖方要随之改变,这种变化是会传播的。
看到了微服务具有这样的问题,其实再看看过去的传统单体应用,调用方和被调用方都在一个进程中,这个时候,服务提供方发生改变,我们随手把调用方代码一起改了就完事了,根本不会有这样的问题,因为其实调用方和被调用是一个整体。
所以,这个问题,我觉得,没有什么更好的方案了,既然选择了微服务,就需要正视这样的问题存在,选择最常规最稳妥的解决方案吧。
1  2  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5741 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 06:34 · PVG 14:34 · LAX 23:34 · JFK 02:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.