blocks|key|2177193|text|我认为这是一个解释的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2177194|我认为在SOA中，service不是一个物理过程(windows服务/应用程序域)，而是一个逻辑边界.同样的规则也适用于SOA和Microservices中最小的自治组件。它们拥有一个或多个域属性/字段集合的一个或多个域属性/字段的集合(技术权威和数据所有者，这意味着它们是唯一可以更改该数据段状态的组件)。|offset|length|style|CODE|2177195|现在，在运行时，我认为如果您不需要分发进程，那么您可以将它们都部署在同一个进程中(稍后需要扩展、分发组件以获得更好的性能).|2177196|讲得通?|2177197|entityMap^0|0|9|7|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I think that this is a matter of interpretation:

I'd argue that in SOA a <code>service</code> is not a physical process (windows service/app domain) but a logical boundary... and the same rules apply in SOA and Microservices in regards to the smallest autonomous component. they own (the technical authority and data owners meaning they are the only one component that can change the state of that piece of data) of a collection of one or more domain properties/fields.

Now at runtime, I'd argue that if you don't need to distribute you process, then you can deploy them all in the same process (later when you need to scale, distribute your components to achieve better performance)...

Make sense?

blocks|key|2177257|text|除了Sean所说的，当SOA在许多公司开始使用时，人们开始将微服务称为API。领域驱动设计的兴起也导致了这个词的使用增加。在目前的行业中，两者之间绝对没有区别，人们认为这是他们认为合适的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2177258|你说得对，当你遵循原则上的哲学时，你最终会得到许多微型服务。在我看来，不管是SOA还是微服务，对独立服务的抽象应该只取决于用例、服务将如何部署以及有多少团队将并行地工作。如果服务跨主机部署(尽管容器和DC/OS框架正在解决这个问题)，网络带宽的成本也会增加。如果它是快速变化的服务，拥有大量的移动部件，那么将一项大型服务分解为微服务将是有意义的。否则，我将避免过早的优化，并将功能打包到单个(或几个大型)服务中。|2177259|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Adding to what Sean had said, microservices are what people started to call APIs when SOA had started to being put to use in many companies. The rise of Domain-driven design has also led to the increase in usage of the term. In the industry right now, there is absolutely no difference between the two, people call it as they seem fit.

You are right when you said that you will end up with many micro-services when you follow the philosophy in principle. In my opinion, be it SOA or microservices, abstraction to independent services should depend only on the use-case, how the services are going to be deployed and how many teams are going to work on those in parallel. There is also an increasing cost to network bandwidth if the services are deployed across hosts (though containers and DC/OS frameworks are solving this problem now). If it is fast-changing service, having lots of moving parts, then breaking down a big service into microservices would make sense. Otherwise I would avoid premature optimisation and have the functionality packaged into a single (or a few big) services.

blocks|key|2177302|text|SOA服务在服务级别上都是关于组件化的。微服务是指在服务级别上的功能组合。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2177303|对于不同的问题，它们是两种不同的解决办法。|2177304|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A SOA service is all about componentization on service level.
A Microservice is all about functional composition on service level.

They are two different solutions for different problems.

blocks|key|257975|text|关于您关于“域”的问题，我认为这是Microservices的一个主要特点:+Microservice应该管理自己的功能域和数据模型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|257976|假设您在公司内有一个产品目录应用程序。您可能不希望有许多其他应用程序访问目录持久性层并抽象(再次)目录模型，因为它会使模型重构/演化变得更硬。它可能会导致这些应用程序之间的并发问题，从而阻止目录应用程序的缩放，相反，您可能更愿意维护一个目录应用程序，该应用程序将公开其他应用程序使用的web服务API(例如REST端点)。|257977|我在这个其他相关问题+"Microservices+=+SOA“中读到了这个评论。事实上，ESB不符合这种微服务特性：“智能端点和哑点”，这意味着当一个微服务需要另一个依赖项时，它应该直接使用它，而不需要任何路由逻辑/组件来处理管道。|offset|length|257978|最后，您可以根据Martin对Microservices视频的介绍来查看这个备忘单。|257979|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/25501098/difference-between-microservices-architecture-and-soa|1|https://gist.github.com/remibantos/0ace22c8256dfacf19e7^0|0|0|4|6|0|0|12|3|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$F|W|G|X|1|Y]]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$F|10|G|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

Regarding your question about the "domain", to my view, and I believe it is a main characteristic for Microservices: A Microservice should manage its own functional domain and data model. 

Let's say you have a products catalog application within your company. You probably would not like to have many other applications hitting the catalog persistence layer and abstracting (again) the catalog model as it would harden the model refactoring / evolution. Probably it would cause concurrency issues between these applications preventing the catalog application to be scaled 
Instead you would probably prefer to maintain a single catalog application, which would expose web service APIs (such as REST endpoints) consumed by other applications.

I've read this comment in this <a href="https://stackoverflow.com/questions/25501098/difference-between-microservices-architecture-and-soa">other related question</a> "Microservices = SOA - ESB". Indeed, ESB are incompatible with this microservices characteristic: "Smart endpoints and dumb points" which means that when a microservice needs another one as a dependency, it should use it directly without any routing logic / components handling the pipe.

Finally, you could take a look to this <a href="https://gist.github.com/remibantos/0ace22c8256dfacf19e7" rel="nofollow noreferrer">cheat sheet</a> based on a Martin Fowler introduction to Microservices video.

blocks|key|258004|text|我发现微软给出了一个很好的解释：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|258005|微服务来源于SOA，但SOA不同于微服务体系结构。大型中央代理、组织级别的中央协调器和企业服务总线(+Enterprise，ESB)等特性在SOA中是典型的。但在大多数情况下，这些都是微观服务社区的反模式。事实上，有些人认为“微服务体系结构是做得对的。”|blockquote|style|BOLD|258006|entityMap|0|LINK|mutability|MUTABLE|url|https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/service-oriented-architecture^0|3|2|0|0|35|8|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@$A|V|B|W|G|H]]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

I found a good explanation done by <a href="https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/service-oriented-architecture" rel="nofollow noreferrer">Microsoft</a> : 

<blockquote>
 Microservices derive from SOA, but SOA is different from microservices
 architecture. Features like big central brokers, central orchestrators
 at the organization level, and the Enterprise Service Bus (ESB) are
 typical in SOA. But in most cases, these are anti-patterns in the
 microservice community. In fact, some people argue that “The
 microservice architecture is SOA done right.”
</blockquote>

blocks|key|2177506|text|SOA不同于微服务。SOA是一个特性库，它需要一个消息服务中间件来实现组件之间的交互。为了节省一些冗长的理论，让我用我最近使用的一些软件作为说明。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2177507|我最近有个金融解决方案。解决方案被分解成两个子解决方案，相互通信。|2177508|第一种称为融合银行贸易创新(FBTI)，另一种称为融合银行企业渠道(FBCC)。这些解决方案由不同的团队开发，并作为不同的解决方案出售，但作为一个单一的解决方案一起工作。没有FBTI就不能使用FBCC。FBCC是客户与什么(客户界面)交互，而FBTI是银行与之交互的管理仪表板。|2177509|这两个特性之间的通信是使用消息服务中间件(如IBM消息队列(MQ))实现的。FBCC向队列发送消息，并由FBTI选择，这是它们的通信通道。|2177510|​|2177511|📷|atomic|offset|length|2177512|2177513|另一方面，微型服务是基于任务的。组件之间的交互是通过web服务实现的。我将使用一个名为Prestashop电子商务解决方案作为示例。|2177514|当您下载预prestashop时，所有的功能都被划分为单独的模块，例如，如果您想更改主页的横幅，就会有一个模块。有一个模块只用于导航栏，与页脚模块不同。解决方案有300多个模块。还有一些模块，如管理产品、类别、购物车等--见下图|2177515|2177516|2177517|该解决方案的模块化特性为其他prestashop合作伙伴开发不同的模块提供了一条途径，这些模块可以替代预prestashop中的默认模块，也就是说，您可以从合作伙伴那里购买另一个模块来替换默认模块，如cart、发货计算器。|2177518|总之，SOA概念主要用于两个或多个解决方案之间的交互，而微观服务概念用于解决方案中两个或多个任务之间的交互。|2177519|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://developer.qcloudimg.com/http-save/yehe-900000/352fb5a56bad3c45160ba846ccff629c.png|imageAlt|1|https://developer.qcloudimg.com/http-save/yehe-900000/e4dd529258378f3b7468e44533c8f3e4.png^0|0|0|0|0|0|0|1|0|0|0|0|0|0|1|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1C|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1F|8|@]|9|@$M|1G|N|1H|1|1I]]|A|$]]|$1|O|3|I|5|6|7|1J|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1K|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1L|8|@]|9|@]|A|$]]|$1|T|3|K|5|L|7|1M|8|@]|9|@$M|1N|N|1O|1|1P]]|A|$]]|$1|U|3|I|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1R|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16|17|-4]]|18|$5|12|13|14|A|$15|19|17|-4]]]]

SOA is different from micro service. 
SOA is feature base and it needs a message service middle ware for interactions between the components. To save you some lengthy theory, let me use some software i worked with recently as illustration.

There is a finance solution i worked with of recent. The solution was broken down into two sub solution that communicate with each others.

The first one is called Fusion Banking Trade Innovation(FBTI) while the other is called Fusion Banking Corporate Channel(FBCC). These solution were developed by separate team and sold as different solution but work together as a single solution. FBCC cannot be used without FBTI. FBCC is what the customer interact with(client interface) while FBTI is the admin dashboard that the bank interact with.

Communication between the two features is achieved using a message service middleware like IBM Message queue(MQ). FBCC send message to the queue and is being picked by FBTI and that is their channel of communication.

<a href="https://i.stack.imgur.com/tn4ld.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/tn4ld.png" alt="enter image description here"></a>

Micro service on the other hand is task based. The interactions between components is made possible through a web service. I will used a solution called Prestashop ecommerce solution as illustration.

When you download prestashop, all the functionalities is divided into separate module e.g if you want to change the banner of the home page, there is a module for it. There is a module for navigation bar alone and is different from module for footer. There are more than 300 modules for the solution. There are also modules like Manage Products, Categories, Shopping Cart etc. see fig below
<a href="https://i.stack.imgur.com/miyJa.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/miyJa.png" alt="enter image description here"></a>

The modular nature of this solution has provided an avenue for other prestashop partner to develop different modules that could replace those default modules in prestashop i.e you can buy another module from a partner to replace default modules like cart, shipping calculator.

In conclusion, SOA concept is majorly used for interaction between two or more solutions while micro service concept is used for interaction between two or more tasks within a solution.

I was looking for differences b/w SOA and Microservices architecture style
and found a good link <a href="https://www.infoq.com/articles/boot-microservices" rel="noreferrer">https://www.infoq.com/articles/boot-microservices</a>

It Says: 
As a successor to "Service Oriented Architecture" (SOA), microservices can be categorized in the same family of "distributed systems", and carry forward many of the same concepts and practices of SOA. Where they differ, however, is in terms of the scope of responsibility given to an individual service. In SOA, a service may be responsible for handling a wide range of functionality and data domains, while a general guideline for a microservice is that it is responsible for managing a single data domain and the corresponding functions around that domain.

Please help me to understand : 
The meaning of single data domain (recommended for microservice).
is it saying that a separate Microservice has to be build to manage a single domain/entity (and associated/composite domain/entities with this single domain/entity). Becasue if this case, then there will be many(~20 to ~50) microservices even to implement a basic functionality (enterprise) application

Edit:
I have gone through the link <a href="https://stackoverflow.com/questions/25501098/difference-between-microservices-architecture-and-soa">Difference between Microservices Architecture and SOA</a>, but it explains, that it is same on the first two tenets, and different on 3rd point (in SOA, Services share schema and contract, not class), but that is SOAP contracts, but then what is the difference b/w SOA (with REST) vs Microservices (which is mostly with REST)

Microservice vs SOA differs

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在寻找b/w SOA和Microservices体系结构风格的差异，并找到了一个很好的链接。上面写着：作为“面向服务的体系结构”(，SOA )的继承者，微服务可以被分类在同一个“分布式系统”家族中，并且继承了SOA的许多相同的概念和实践。但是，它们的不同之处在于赋予个人服务的责任范围。在SOA中，服务可能负责处理广...

问Microservice与SOA不同
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Microservice与SOA不同EN