我们致力于电子邮件归档服务。该产品是用Java编写的。主要功能是在大多数情况下从客户端的邮件服务器，MS Exchange读取电子邮件，用特定参数丰富它们并将它们写入光盘。然后将邮件存档，编入索引并可以搜索。
我们使用的邮件服务器是Apache James，用于索引的Apache Lucene和用于执行其他工作的Jboss作为应用程序服务器。因此在典型的生产环境中，将有负载均衡器接收大PST文件，然后处理读取PST并发送邮件设置Apache James。中间进程在光盘上邮件存档，然后在Lucene上进行索引。
我们没有遇到特定的特定并发或容错问题，因为整个过程处于脱机状态，负载均衡器可能会在一天内收到PST文件。
我想知道我们是否可以在流程中的任何地方使用Erlang？
答案 0 :(得分：2)
根据索引/存档任务的详细信息，整个堆栈可以用较小的Erlang系统替换。通过＆＃34;较小的＆＃34;我的意思是它不会涉及任何外部工具，维护和运行时占用空间可能要小得多，并且开发人员可能会记得很少（具体而言，它会让开发人员摆脱webstack风格所必需的操作思维模式）多工具合并）。这将完全取消James，Lucene和Jboss，但无论你使用什么来从PST中提取邮件，都可能会保留并通过套接字将位推送到Erlang系统。
这可以逐步完成，但我认为让Erlang节点使用JMX星座将会有很多额外的工作 - 这实际上取决于JMX位与核心逻辑的分离程度。如果您当前的代码是以使JMX易于替换的方式编写的，那么您可以将这些位替换为使Java应用程序本身与Erlang节点通信的接口库之一。
让Java商店与Erlang合作是一大步。必须推翻许多思维方式，并且必须学习一个完全陌生的环境（Erlang本身很容易，语言不是真正的问题，它是平台）。在过渡期间，它会使现有开发人员的认知负担加倍。这是否值得，完全取决于您的业务情况。
虽然从长远来看，我无法想象想要在任何不适合Android的东西中生活在JVM世界中，但现实情况是，大多数业务问题都不是很长期。我也不想坚持使用COBOL，但是大量的企业确实有合理的理由。
如果您的商店经常参与重构或审核您的产品，那么就会有很多机会引导某种方式，这样可以在不破坏银行或破坏您的团队的情况下实现这一目标。如果没有，我怀疑它是否值得，Erlang可能更适合内部项目，因此您的开发人员可以在没有持续运营压力的情况下感受事物。