2016-09-20 70 views

回答

0

很多人都涉及到微服务为SOA 2.0,所以如果我正确地得到你的问题,你绝对可以在一个项目中...

+0

SOA中的ESB用于根据需要执行协议转换/ req-resp转换。由于微服务通常被视为智能端点哑管,我们可以在微服务架构中处理这些情况? Netflix在其API网关中执行协议转换,但它是否遵循SEDP原则? – Divs

+0

SOA和微服务中的重要原则是减少耦合,并避免状态更改的同步通信,因为该方面的消息传递可以帮助实现异步持久通信......您使用哪些工具并不是真正的意义......有意义吗? –

+0

我想了解MSA中的哪个组件可以用来处理req/resp转换。根据Web上的大多数文章,它是API网关层,而不是ESB。就在这种情况下,有人正在使用此层在MSA中执行相同的操作,他们是否违反SEDP原则? – Divs

1

简单来说,微服务是SOA的子集,使用这两种架构。您可以参考以下9 characteristics of Microservice,他们仍然遵循SOA设计原则:

组件化通过服务

各地的业务能力,组织

产品没有项目

智能终端和哑管道

分散治理

分散d ATA管理

基础设施自动化

失败的设计

进化设计

如果你指的SOA架构实现ESB,然后使用ESB并不一定会让你的SOA标准,除非你坚持服务特点/服务设计原则服务设计&建模。因此,让我们分离服务的ESB。从根本上讲,ESB只是SOA的一些非功能性元素的实现。

选择一个整体的应用程序是一个基本的现象开始与微服务。不过,我坚信微服务可以用于更多的业务场景。

+0

我同意单独使用ESB不会影响质量为了一个好的SOA设计。但是,几乎一致表示ESB不在MSA中使用。如果不是,为什么在这种情况下,MSA中的哪个组件/层可以处理xformation /协议翻译等? – Divs

+0

在MSA中,我们遵循“智能终端和哑管道”,其中指出,变换/协议翻译是相应的服务责任。换句话说,转换/翻译也可以作为可重用的公用事业服务。尽管MSA不建议使用ESB,但同时它不会强制删除ESB。在创建ESB与企业系统依赖关系的逻辑和紧密耦合情况下,您始终可以将ESB视为MSA的一部分。 –

3

是的,你完全可以在同一环境中的架构。这是为什么:

微服务架构在很大程度上受到启发SOA,所以自然在这两个原则的使用是非常相似的,往往有两个之间的混淆。但是,您应该注意,这些范例在范围范围内不同。 微服务架构是设计以特定方式的应用程序的方法,而SOA旨在把为了在不同域中的多个异构应用程序(通常在企业环境)之间的通信,避免由具有点 - 点通信中间件,并且通常会降低集成工作量并长期提高投资回报率。 SOA不仅仅是一种架构方法,而是提供了一种全新的方法来优化企业中的IT域。它通常需要对流程和层次结构进行更改,因为SOA治理机构需要在某个时间到位才能理想地执行企业策略。

因此,在实践中,你会经常看到这样的事情 - 在相同的一般SOA许多应用程序体系结构样式:

many application architecture styles in the same general SOA

希望这有助于。