… 我在90年代末就了解了分布式递增-单调日志，当时还有许多其他方法可以实现保证的事务性数据库操作。我非常确定这些方法一定是在50年代或60年代就被发明出来了，因为这些都是早期商业计算机用户面临的问题：银行软件。这些技术被埋藏在遗留的COBOL程序中，需要被逐渐替换为稳健的Java核心服务。我确信Restate的设计者一定从如何将这些基本原理转化为适应当今软硬件生态系统的实际系统中，学到了非常有用的见解。然而，这让我开始怀疑，现在的年轻程序员是否只被教导了“快速构建-快速发布”的理念，而已经没有软件工程师能够在系统设计之初就将这些保证融入进去，而是站在那些发明我们这门学科的前辈们的肩膀上，让他们的经验真正被实践所用？或者，我是不是漏看了文章中某些描述新突破的内容？
源讨论每个系统都是一份日志：在分布式应用中避免协调原帖 155 条评论 · 导入时统计把你的经验，加入这段讨论。
我认为你的观点非常正确——大多数东西已经被发明了，而且过于强调快速行动和打破常规的心态。 这里有一个后续的想法：资深人士在多大程度上让我们这些新人走错了路？一些例子如下： 数据库的创建者知道复制日志，但我们得到的是数据库，而不是复制日志产品。 Java的创建者知道不可变性："我尽可能使用不可变对象。" [詹姆斯·高斯林，1]，但直到几年后才有人给我们提供了pcollections/javaslang/vavr。而且它们仍然远未普及，甚至远未进入标准库。 据称 Brendan Eich 希望在浏览器中加入 Scheme，但他的上司让他改用 JS。 我们还错过了哪些东西？ [1] https://www.artima.com/articles/james-gosling-on-java-may-20...
完整原文这显然建立在计算机科学长期历史的研究原则和想法之上。 是的，有时候你会想"哦，当我们开始采用架构 pqr（微服务）时，我们无意中放弃了 xyz（即步骤间的因果顺序）。但这里有一个想法，如何在不破坏 pqr 的好处的情况下重新获得它"。 如果你想，可以认为这是其中一种情况。我认为在这方面有巨大的实际价值（在我的职业生涯中我确实发现如此）。 技术进步是呈锯齿状的。你增加了能力 x，但在这个过程中失去了 y，后来有人找到方法同时拥有 x 和 y。这就是进步。
完整原文当我上学的时候有一个选修要求。你必须从 2 或 3 门课程中选一门来毕业。那是编译器设计，这门课在之前学期的同班同学中评价非常差，或者分布式计算。可能还有第三门，但如果有的话，那门课我记不太清了。 所以我选了分布式计算。这最终成为满足我大学教育 80/20 法则的四门课程之一。 最近我开始问同事他们是否上过这样的课程，结果震惊地发现很多人不仅没上过，甚至不记得他们学校曾经提供过这门课。什么？ 我理解在 90 年代这可能很罕见，但 2000 年代开始关注水平扩展，而 2020 年代则充斥着分布式计算的问题。怎么……为什么……我无法理解我们怎么会走到这一步。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。