Golang 微服务和与现有应用程序的通信 [关闭]

Question

我想对我们的 Rails 应用程序进行一些缩放，我想使用 Golang。 所以，今天我们用 RoR 编写了相当大的应用程序，其中大量的处理和计算通过 Ruby 进行，在某些情况下变得很慢。

我想提取我们应用程序的某些部分，并在 Golang 中重新编写它们以获得更好的性能。

我想听听一些好的建议和做法，尤其是如何开始拆分它们。

最好的问候

Answer 1

如何最好地吃大象？一次咬一口……

由于这对您来说是一个新世界，我将首先剥离您的应用程序的一个功能，该功能一开始与其他任何东西都没有高度关联。选择不使用任何实际业务逻辑的报告引擎或直接或类似查询数据库的定期维护任务。它不一定是最需要性能增强的（尽管如果 IME 报告必须通过业务逻辑来获取数据，则几乎总是较慢）。关键是要剥离一些没有巨大先决条件的东西，以便您对新环境将如何插入有信心和理解。

一旦你有了这些，请考虑你需要多少业务逻辑以及你的副作用有多深。尝试在没有太多副作用并且尽可能接近经典函数（即一堆输入，一个输出）的事情上找到你的第二批工作。如果您的 RoR 代码中有可以发送的内容（例如“我得到了所有这些数据”……然后神奇的事情发生了……然后“我输出了一些处理过的数据”），这是一个不错的选择。

在 HTTP 上来回往返会增加一定的延迟（如果直接来自浏览器，则延迟会更少，但仍然...），因此请小心在您知道可以获得收益的地方工作。一个针对您的旧代码的分析器会在这里帮助很多人——无论是昂贵的，都会是您的下一个候选人。

如果您在处理了唾手可得的果实后仍需要优化，那么您可能需要考虑拆分您的业务规则，以便一些存在于 RoR 世界中，而另一些则存在于 Go 世界中。不要维护相同的业务规则的两个实施——那是疯狂的。如果您决定订单是一个系统而供应链是另一个系统，那很好，但不要尝试在这两种环境中维护供应链代码的实现。

看在上帝的份上，如果您将业务逻辑从旧系统迁移到新系统，请不要将旧代码留在原处但未使用！！！你有版本控制——如果有人需要参考旧的实现，让他们挖掘。否则，您会将可怜的代码维护者与永远不会运行的残留代码混淆。如果您已弃用代码，请将其删除。

哦，我确定我不需要这么说，但你需要单元测试来验证 bug 对 bug 的兼容性...

最后，请记住，RoR 是高度面向 MVC 的，而 Go 固有地不是 MVC（尽管有 numberofframeworks）。您肯定会想要检查（并且老实说可能会丢弃）那些框架，但徒劳地尝试进行直接移植。来吧：把它从你的系统中取出。然后继续做一些小的、渐进的进步，慢慢吃掉你的大象。