用微服务和ESB方法分解单块应用？

Question

我只有关于ESB的理论知识。

用例：-

1. 我有电子商务一样的应用程序，我可以接收来自不同格式的多个来源的订单。
2. 一旦提交申请，我需要向两个系统发送电子邮件。
3. 一旦申请提交，我需要提交一个输出文件到第三方系统。今天，它仅限于XML，但我们可能需要支持所有格式。
4. 同样，我需要进行分析和报告准备。

我认为ESB和Micro在理论上都适用。两者都使应用程序松散耦合和可扩展，而不是单片应用程序。我不确定我应该考虑哪些标准/属性来选择现成的ESB产品(付费或开源)，而不是将应用程序分解成微服务？

我的理解是:- ESB在这里可能更适合，因为它使应用程序更加松散地耦合，其中一个组件/应用程序只需将消息放在通道上(在基于java的ESB应用程序中，它只不过是java对象，其他组件在其中侦听)。现在，其他组件，如路由器/转换器/适配器/端点等将进入画面并采取进一步行动。这里，发送组件只需要知道目标地址，它将是单通道地址。

对于微服务，这也是正确的，但是这里的使用者需要知道每个特定操作的URL。

但现在，我观察到大多数人更喜欢微型服务而不是ESB。我认为原因可以是ESB有自己的学习曲线/ DSL/付费产品，但是微服务只是将服务划分为更小的、可维护的restful组件。所以没有学习曲线也没有付费产品。

Answer 1

我认为我的观察是，无论哪种方式，你都必须做一些编码。

如果你自己编码所有的东西，你就有成本在开发人员的薪水和时间编码你想要添加的每一个新的东西。

现成的ESB承诺超级可配置和拖放界面，这样您就可以轻松地将所有东西连接在一起，从而避免这种成本。

然而，在实践中，我发现您所连接的东西并不需要非常复杂才能超出拖放界面的功能，并且您不得不返回到编写特殊函数的过程中。

很快，您就会雇用一个专门使用该产品的ESB程序员团队，您的ESB设置变得非常复杂，以至于没有人能够理解它，而且基本上您只是将一种编程语言换成了另一种价格更高的编程语言，并锁定了供应商。

但是，您不应该将微服务与HTTP微服务混淆。您可以将手工编码的微服务隐藏在各种网关后面。如果http是您的客户的一个问题，为什么不让他们通过电子邮件文件跨？或者使用FTP，或者使用消息队列使其更基于事件等等。

我想再补充一条(有争议的)意见。随着公司规模的扩大，自动化一些流程就变得不那么重要了。雇用管理人员做的事情，半手动增加了一个水平的灵活性和快速反应的变化，自动化界面无法竞争。

总是把文件名弄错的那个客户？因为他们有一个5年的技术计划而无法安排API开发的大企业？您所使用的第三方软件不公开API吗？

一旦你有了一些这些问题，就有足够的工作可以让管理团队忙碌，而且你的开发团队可以在你的核心产品上做更好的事情。