Microservice vs SOA differs
I was looking for differences b/w SOA and Microservices architecture style and found a good link https://www.infoq.com/articles/boot-microservices
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 Difference between Microservices Architecture and SOA, 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)
I think that this is a matter of interpretation:
I'd argue that in SOA a service 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?
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.
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 other related question "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 cheat sheet based on a Martin Fowler introduction to Microservices video.
链接地址: http://www.djcxy.com/p/34088.html上一篇: 什么是微服务？
下一篇: 微服务与SOA不同