xenoblade 最近的时间轴更新 xenoblade 最近的时间轴更新
xenobladex
xenoblade 最近回复了
6 天前 回复了 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 中。
如果楼主和我一样，对如何基于 spring webflux 体系来设计一套 bff 感兴趣，并且希望 API gateway 支持 BFF 特性，可以参考 https://github.com/fizzgate/fizz-gateway-node ，其中 BFF 核心代码在 com.fizzgate:fizz-aggregate 中。
6 天前 回复了 aoxg2019 创建的主题 › Java › sprung gateway 问题 |
6 天前 回复了 aoxg2019 创建的主题 › Java › sprung gateway 问题 |
106 天前 回复了 ZZ74 创建的主题 › 问与答 › 有什么办法能够相对快速的去除 webflux RxJava 那套换成普通的写法 |
底层 IO 操作的 infrustructure 继续使用 reactor ，上层业务改用 kotlin ，通过 kotlin coroutines 对 reactor 的适配器，修改为 kotlin coroutines 的命令式编程写法，调试难度要低很多。
196 天前 回复了 wencan 创建的主题 › OpenAI › 哪个 rag 系统比较靠谱？ |
我认为这个例子其实应该归类为“RAG VS 长上下文”，恰恰说明了长上下文在有限信息的 QA 中完胜 RAG 。
目前 langchain 系的 通用 RAG 系统上限就在那里了，要想达到更高的精确度需要对不同领域进行微调，例如例子中读书场景的 prompt 优化、chunk 分割的人工干预。
目前 langchain 系的 通用 RAG 系统上限就在那里了，要想达到更高的精确度需要对不同领域进行微调，例如例子中读书场景的 prompt 优化、chunk 分割的人工干预。
245 天前 回复了 yechentide 创建的主题 › 游戏开发 › 想自己做个异度之刃 3 里的 Flame Clock, 有什么现成的库吗, 或者需要学习哪些东西呢 |
顶着 ID 说说我的想法：考虑到 OP 不了解建模，效率高的办法就是游戏模型提取了，广泛用于 MMD 圈和 3D 打印圈，游戏模型提取的工具链挺全的，网上也有很多教程，需要实践踩坑，不想花时间可以直接咸鱼找人接单。
模型拿到了之后就是渲染了，还需要实现命火粒子效果、命火材质、命火剩余量的动画。
总之 3D 要了解的东西还是挺多的，如果不强求其实 2D 实现起来快很多。。。
模型拿到了之后就是渲染了，还需要实现命火粒子效果、命火材质、命火剩余量的动画。
总之 3D 要了解的东西还是挺多的，如果不强求其实 2D 实现起来快很多。。。
351 天前 回复了 Markxu0 创建的主题 › 问与答 › RPC 服务支持 HTTP 和用一个 gateway 来对外提供统一的 http 服务，哪种方式更优雅和常用呢 |
从我的经验来说，大部分情况下，对外提供的 http 接口应当显式在服务中申明，再补充几个优势：
1. 方便进行外部流量治理；
1. 确定了内部接口与外部接口的边界，外部接口的定制化更加灵活；
2. 项目交接时，代码即接口文档；
而 gateway http to rpc 适配器的方式可以作为特殊情况下的补充（前提是该体系有成熟的解决方案以及丰富的线上使用案例）：
1. 老项目需要在不改动不重启的情况下快速的将 rpc 接口以 http 协议提供外部调用；
2. gateway 有专门的团队维护，希望系统内只关注 rpc 流量治理，减少 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 没有达成业界共识的情况下，业务低代码平台就是伪需求，难以推广和发展。
优点：1. 基于 java 开源； 2. 基于 Bpmn 模型同时支持手动流程与自动流程（不支持部分 Bpmn 特性）； 3. 提供大量组件，可自定义，已经看到国内企业基于 Camunda8 封装的低代码平台在卖了。
缺点：1. Bpmn 模型设计之初就是为了解决不同人员/角色的工单流转，并不适合做业务编排，实现复杂逻辑时难免捉襟见肘； 2. 由于采用消息队列（自研消息队列 zeebee ），性能（时延）不如命令式编程； 3. 由于业务低代码平台改变了开发方式，所以要想达到支撑线上业务的水平，能需要对接和开发大量 DevOps 相关的能力； 4. 为了保证兼容性和灵活性，业务最终产物必然是大量流程、配置和脚本混杂的 xml 文件，将随业务发展超过代码的维护成本。
目前我已经释然了，在大部分项目方向规划不明确，对 PaaS 没有达成业界共识的情况下，业务低代码平台就是伪需求，难以推广和发展。
Select Language