使用 Erlang 电子邮件归档的建议

Question

我们致力于电子邮件归档服务。该产品是用 Java 编写的。主要功能是从客户的邮件服务器（大多数情况下是 MS Exchange）读取电子邮件，用特定参数丰富它们并将它们写入磁盘。邮件然后被归档、索引并且可以被搜索。

我们使用的邮件服务器是 Apache James，Apache Lucene 用于索引，Jboss 作为应用程序服务器来做其他工作。所以在典型的生产环境中，会有负载均衡器接收大 PST 文件，然后处理读取 PST 并发送邮件来集阿帕奇詹姆斯。中间进程将邮件归档到磁盘上，然后使用 Lucene 进行索引。

由于整个过程处于离线状态，因此我们不会遇到特定的特定并发性或容错问题，负载均衡器可能会每天接收一次 PST 文件。

我想知道我们是否可以在流程中的任何地方使用 Erlang？

Answer 1

根据索引/归档任务的细节，整个堆栈可以被一个更小的 Erlang 系统代替。 “更小”是指它不涉及任何外部工具，维护和运行时占用空间可能会小得多，开发人员要记住的内容可能会少很多（具体来说，它会让开发人员摆脱必要的运营思维）用于 webstack 风格的多工具合并）。这将完全取消 James、Lucene 和 Jboss，但无论您用来从 PST 提取邮件的任何内容都可能保留下来，并将位通过套接字推送到 Erlang 系统。

这可以逐步完成，但我认为让 Erlang 节点与 JMX 星座一起工作需要做很多额外的工作——这实际上取决于 JMX 位与核心逻辑的分离程度。如果您当前的代码是以一种使 JMX 易于替换的方式编写的，那么您可以将这些位替换为使 Java 应用程序与 Erlang 节点本机对话的接口库之一。

让 Java 商店能够很好地使用 Erlang 是一大步。如此多的思维方式必须被推翻，并且必须学习一个完全陌生的环境（Erlang 本身是如此简单，以至于语言并不是真正的问题，它在探索平台）。在过渡期间，它会使现有开发人员的认知负担加倍。这是否值得完全取决于您的业务情况。

虽然从长远来看，我无法想象想要在 JVM 世界中为任何非 Android 的东西生活，但现实情况是大多数业务问题都不是长期的。我也不想坚持使用 COBOL，但大量企业确实有这样做的充分理由。

如果您的商店经常对您的产品进行重构或审查，那么将有很多机会引导事情以一种可行的方式实现，而不会破坏银行或破坏您的团队。如果不是，我怀疑这是否值得，而且 Erlang 可能更适合首先用于内部项目，这样您的开发人员就可以在没有持续运营压力的情况下感受事物。