SOA和微服务之间的真正区别是什么

免责声明

我希望我不要踩任何人的脚趾或冒犯任何一个概念的狂热者

背景

我一直在寻找面向服务的体系结构和微服务之间的真正区别，而没有找到明确的答案。

我读到以下内容：

• SOA的副作用
• SOA是反模式
• 微服务来修复SOA的故障
• ESB并不是真正的ESB，而是EAI
• 对消息中介的过度依赖
• 供应商正在滥用SOA的概念并试图出售其产品
• SOA不受控制地增长

但是，仍然没有明确定义面向服务的体系结构（作为一个概念）和微服务（作为一个概念）之间的体系结构差异

据我了解，它们都具有：

• 服务提供商，只做一件事
• 服务网关/ ESB将这些服务提供给消费者
• 服务使用者，通过ESB /服务网关访问服务

题

那么，除了将SOA重新标记为微服务之外，还有什么不同吗？限制微服务成为宏的技术约束吗？

注意：我不是在寻找观点，只是在寻找事实，希望在要点中

参考文献

• 软件工程问题
• 马丁·福勒（Martin Fowler）的网站（我认为他讨厌这段时间）
• 信息世界
• 迈克尔·富瑟斯的网站
• 堆栈溢出问题

更新资料

似乎在Stack溢出问题中也发生了类似的辩论，无论是否区分微服务都是变相的面向服务架构。

SO问题的结论：

• MS是SOA 的特例
• MS支持较小规模的应用程序托管服务
• MS取决于技术（使用HTTP而非开放协议选项）
• MS依靠技术来加强纪律（服务的自动部署）
• MS考虑使用ESB（邪恶），但使用API​​网关，IMHO是ESB的一种

如果满足以下条件，那么可以得出结论，MS是SOA：

• MS是否支持编排概念？一个或多个主流程管理工作流程
• MS中是否有消息代理层？一组适配器，将消息格式从服务生产者的消息空间转换为服务使用者
• 微服务可以从整体企业应用程序读取数据吗？可以是单片应用程序的API吗？还是必须是能够独立运行的独立的自包含应用程序？

如果最后一个问题的答案为否，那么微服务将无法处理复杂的工作流程系统，例如信用卡管理系统或对帐系统

服务提供商，只做一件事

对该项目产生广泛影响的核心区别在于，通过微服务，这些服务提供商可以独立部署和扩展。

这很棒，因为您可以更加敏捷。如果一项服务需要更改，则只需更改一项，而无需更改。如果您想尝试一种新的框架或语言，只需替换该服务即可。如果您突然需要100倍的容量，请启动一些具有该服务的新计算机来处理大量流量。如果您想对某些东西进行版本控制，只需对它进行版本控制就不会影响整个应用。而且它使事情变得更容易监视，检测，在团队之间分散，过时了...

但这带来了一些健康的含义：

• 您的发布过程需要更改，因为部署一些服务与部署几十个服务的方式有所不同。
• 您的发布过程需要更改，因为将服务部署到一台计算机与部署到几十台计算机的方式有所不同。
• 您的数据库设计，使用和部署需要更改，因为如果服务需要部署此大型共享数据库才能正常工作（破坏所有其他服务），则部署服务就毫无意义。
• 您需要更改库的设计和使用方式，因为如果需要更新此共享库（破坏所有其他服务），则部署服务就毫无意义。
• 您的日志记录/授权/会话管理/等需要更改，因为当您只是一项服务时，共享内容非常容易，但是当您拥有一堆组成产品的独立的小服务时，它们就很不一样了，并且它们将想分享东西。哦，所有这些共享的东西都可能需要处理不同版本的东西。
• 您的交流需要改变。只需很少的服务，您就可以沿着不经常发生和/或可能发生缓慢通信的路线破坏事物。借助微服务，他们将互相交流很多，而高延迟不会减少这种情况。

这里是底线之间的一个明显区别SOA和微服务是概念

智能终端哑管

与SOA不同，SOA依赖于遗忘的服务使用者和生产者，将流量管理，消息格式转换和服务编排委派给外部系统，例如ESB，服务编排器，消息代理。