CodeCaster 最近的时间轴更新
CodeCaster

CodeCaster

V2EX 第 736478 号会员,加入于 2025-02-24 11:22:43 +08:00
今日活跃度排名 16352
全职开源,跪谢各位V友,求一个Star,项目地址:https://github.com/ModelEngine-Group/fit-framework
CodeCaster 最近回复了
我会每次问大模型问题时,最后带一个“谢谢”,希望他以后记得,有一个小碳基还是很有礼貌的。
18 天前
回复了 Joker123456789 创建的主题 Java 微服务是不是一种错误的方向?
看完这个问题以及上面所有的讨论,我想提出一种全新的思路,大家可以一起讨论下。

首先,在微服务出现以前,大多数服务是以单体应用的形式存在的,后续由于各种原因(项目变大,需求变多等等)演变为微服务。单体应用有单体应用的优点与缺点,微服务也有微服务的优点和缺点。这两种模式的争论其实一直存在,正如 @micean 说的,“从一个极端到另一个极端”,这句话一点不错。我觉得其实是有解决方案的,是不是可以在这两个“极端”中找一个平衡点呢?

记得 2023 年的时候,google 开源了一款软件,叫 service weaver ,他有一个口号,“以单体形式编码,以微服务形式部署”,他的这个思路非常新颖,主要想告诉大家的一点就是,编码的时候可以按照一个模块一个模块来开发,互相没有耦合,但是最终部署的时候可以选择是单体应用一起部署,或者是微服务分开部署。

其实,我们团队在这之前也一直在做这方面的探索,但是一直没有开源,直到 2025 年春节前,我们的项目也开源了,我们以 Java 为主,推出了一套插件化的开发框架,每一个模块都可以以插件进行开发,插件之间互相不感知,但是我们参考 OSGI 的思想(@ioufev ),做到了插件可以聚合成一个进程部署(单体应用形态),或者分开部署(微服务形态)。

如果做到了这一步,是不是可以解决楼主的问题呢?其实微服务并不是一个错误的方向,而是在技术的螺旋式上升演进过程中的一个关键点。

以下是我在知乎上回答的类似问题的回答: https://www.zhihu.com/question/11654944781/answer/96580243167
这个是我们这个插件化框架的社区地址: https://github.com/ModelEngine-Group/fit-framework

我们项目刚开源不久,欢迎来讨论单体应用和微服务之间的相关问题,如果有同学们喜欢,也可以给我们点个 Star ,鼓励一下我们,感谢~
个人备案也需要一点时间,最近刚好在备案,看了看流程,流程理论上来说也不复杂,就是费时,注册完域名,需要邮箱实名(这步很快,阿里云上 20min 搞定了),然后是个人实名(这步稍微慢一点,但也是小时级完成的),接下来的步骤稍微麻烦一点,首先,个人实名之后,这个实名信息会发送给管理局,但是管理局不清楚周末上不上班,反正就是等待 3 个工作日再往下做成功率最高,等了 3 个工作日之后,需要在云上购买一个 ECS ,时间至少需要满 90 天(不清楚是不是所有云都是这个要求,但是云厂商肯定还是希望购买他们服务的,记住,这个是 90 天不是月,比如 2 月购买的机器,买一个月就没有 30 天,我就是前几天买的,买完真心疼),然后弄个弹性公网 ip 就可以正式备案了,备案说的是 1-20 个工作日吧,就是等。

我也是最近在搞开源社区推广,要弄一个域名,才想到的备案,才正好研究了下这个流程,楼主要是觉得有用可以点我个人信息给我项目加个 star 哈~
@xiaomushen 你说的很对,支持你的观点
@xiaomushen 理解,赞同,因此我们才在 Java 上发力,我们希望能够成功,但是不成功,也能带来一点思维碰撞的贡献也可以。 顺带求各位 V 友,可以给个 Star ,感谢
@JrD 我上面提到的 Python 的工程性比较差,这个是相对 Java 语言的,所有语言都可以通过“开发规范、架构设计、review 等问题来保证”,对不对?只是这么做的成本不同语言是不一样的吧? Java 是公认的工程性比较好的语言,Python 的确灵活性更强,相对的,工程性比 Java 差了不少。

感谢讨论,但是我也表达我的观点,我并不是想针对编程语言引战,我希望这个讨论可以相对客观的来看。Java 和 Python 各有特点,也都各有不足之处。
@xiaomushen 不好意思,我不太明白你的重点讨论点是什么?我同意你说的“做应用,各种语言都可以”,但是我不太明白我上面提到的哪句话让你产生了“就好比大部分数据库都是 C 开发的,难道说,C 语言是做基于 DB 应用的首选?”这样的反问呢?谢谢指出,欢迎讨论
@sighforever 明白你的观点,也感谢你的支持~但是对于其中的一点,就是“实在没必要在 python 以外的语言上整和 AI 相关的事儿”我觉得这个有待商榷。

我的观点是这样的:当前的事实是,从事 AI 工作的人使用 Python 的最多,Python 方面的 AI 库又多又方便,至于运行的快不快的确不是一个关键点,关键点在于 Python 语言的工程性非常差,而这个工程性差直接导致了,遇到问题难以调试,一旦实际生产遇到一个问题,排查的成本是完全会掩盖之前快速开发的成本的。还有一点就是安全性,Python 语言实在太灵活,导致有很多很多黑科技可以改变语言本身的运行逻辑。当前 AI 实在太火,大多数人又都是“好人”,以至于所有人都忽略了其潜在的风险(之前某大厂大模型投毒事件就是一个真实的例子),所以选择一个工程性非常优秀的语言来做 AI 相关的事情并不是没有必要的。

最后,还是感谢你的支持~
@wyntalgeer 感谢你的意见,但是我们团队还是会坚持的。我这里说明一下,我们开源的这个项目,在写之前,并不是没有调研行业周边,而是看了其他框架,设计的思路的确不一样,上面也列出了几个特别的点。

除了这个和 LangChain 比较类似的模块外,我们还有其他几个模块,同样设计理念和业内其他框架不同,比如底层还有一个插件化的编程框架(借鉴 OSGI 的思路)等。我们开源的目的是希望将我们觉得好的东西分享给所有人,在大家的意见之下不断去完善。哪怕能给大家带来一点点思考,也是有价值的。

感谢
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   997 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 14ms · UTC 19:14 · PVG 03:14 · LAX 12:14 · JFK 15:14
Developed with CodeLauncher
♥ Do have faith in what you're doing.