在过去两年中，我们（团队最初有15人，现在有100人）在Temporal之上建立了一个价值十亿美元的业务，为财富500强公司执行关键业务应用。我们对Temporal非常满意。确定性很糟糕，你必须努力工作，让所有活动都具有幂等性，就像我们为持久化软件所做的那样。我们使用的语言是错误的（Go），与我们后来调查的其他语言（Python和TypeScript）相比，有很多样板代码。可见性可能很慢，并且会丢失信息。我们需要编写自己的API来与Agent有效配合，以进行故障的根本原因分析。尽管有所有这些缺点 - Temporal非常棒，感觉比之前使用的编排器（如Prefect或Airflow）要好得多。100%会再次采用。
源讨论SQLite 是你进行持久化工作流所需的一切原帖 387 条评论 · 导入时统计听起来你主要是在单台机器上运行这个？ 随着规模的扩大，Temporal会变得复杂得多。Cassandra很难管理。当出现问题时，Ringpop和TChannel很难调试。由于一致性要求，SQL后端支持不支持水平扩展的副本（只支持单实例）。根据你的代码编写方式，修改嵌入到工作流中的代码会变得复杂，因为任何会修改历史事件顺序的内容都会破坏已部署工作者的确定性。 我们大量使用它，所有最初用它进行简单脚本/自动化的人很喜欢它，但所有在它之上构建真实生产系统的人却都很讨厌它。可能是操作错误，但根据我的经验，这与这些评论中描绘的乐观画面并不一致。
完整原文把你的经验，加入这段讨论。
你能分享一些关于go + temporal的学习经验吗？这对我们的下一个迁移目标来说是接下来要做的。
完整原文这就是当人们说 Temporal 很重时，他们真正想表达的意思。他们实际上是在说：持久、可靠、分布式的任务很难处理，管理起来需要付出努力！这是事实。据我所知，没有哪个系统能让这件事真正变得容易。这是一个艰难的领域。也许 Temporal 让这件事比它应有的难度更难，但我对此没有实际经验。 在这个领域里没有免费的午餐。由于我的使用量很小且相对孤立，我不清楚 Temporal 到底有多好或有多差，但软件很少能真正运行并给我留下深刻印象，而 Temporal 在我本地机器上真正实现了编排，确实做到了。我认为 Netflix 的 Conductor 是另一个很酷的选择，但由于许可证的原因，我最终选择了 Temporal。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。