Service Oriented Architecture (SOA) is a component model, which splits the different functional units of an application (called services) and connects them through well-defined interfaces and contracts. Interface is defined in a neutral way, which should be independent of the hardware platform, operating system and programming language. This enables services built in a variety of systems to interact in a unified and common way. It is a kind of design method, which contains multiple services. Services provide a series of functions through interdependence.
Microservice architecture: in fact, similar to SOA architecture, microservice is the sublimation of SOA. A key point of microservice architecture is “business needs to be completely componentized and serviced”. The original single business system will be divided into multiple small applications that can be independently developed, designed and run. These small applications interact and integrate through services.
In the system based on SOA architecture, the granularity of modules is relatively coarse. For example, a member system SOA may include the modules of member basic information management, member relationship management, member asset management, etc. these modules are uniformly planned in the member management service, and are also in the same process when they are deployed. If the architecture is designed according to the concept of microservice, membership management may be an independently deployed service, and other modules are similar. Whether it needs to be independent or not, the architect needs to decide according to the business of the module, and needs to examine whether the module needs to be independent or not.
Sometimes, the domain boundaries of a system may be the same in SOA and microservices. SOA and microservice have the same architecture idea in essence, but microservice introduces the concept of componentization and domain modeling according to the business form. In most application scenarios, it is easier to maintain and expand than SOA.
Whether it is SOA or micro service architecture, it is a solution derived from the development of the system to a certain extent, and it is an architecture solution to solve the shortcomings of the system. When the centralized deployment is adopted at the beginning of the system, with more and more system modules, the split scheme is naturally produced.
Both SOA and microservice architecture are the result of splitting according to business, but they have many differences.
In SOA system architecture, ESB (Enterprise Service Bus) is used to communicate between services. ESB is responsible for service definition, service routing, message transformation and message delivery, which is a heavyweight implementation. In short, ESB is a pipe used to connect various service nodes.
Microservices emphasize the use of unified protocols and formats, such as restful protocol and RPC Protocol, without heavy implementation such as ESB. Some systems will deploy a unified gateway system in order to manage the micro service system uniformly, and the gateway is the only entrance to the system. From the perspective of object-oriented design, it is similar to appearance pattern. The gateway encapsulates the internal architecture of the system and provides a customized API for each client. It may also have other responsibilities, such as authentication, monitoring, load balancing, caching, request fragmentation and management, and static response processing. The key point of gateway mode is that all clients and consumers access microservices through a unified gateway, and handle all non business functions in the gateway layer. Each service needs to go to the service management center to register actively, so as to realize the automatic discovery of services.
On the whole, the service granularity of SOA is coarser, while that of micro service is finer. For example, for a large enterprise, “employee management system” is a service in SOA architecture; If the micro service architecture is adopted, the “employee management system” will be divided into more services, such as “employee information management”, “employee attendance management”, “employee leave management” and “employee welfare management”.
As for the granularity of microservice, different people have different opinions. Some small partners say that until the service can not be split, I think this idea is wrong. The granularity of a microservice should be divided according to your specific business and your dependent module relationship. Don’t blindly split it into too many services with small granularity, This will bring a lot of trouble to the team in terms of governance. Take a simple example: in the employee management system, if the business relationship between attendance management and leave management is very close, and many operations need transactional atomic operations, you can consider merging the two microservices.
SOA encourages the sharing of components, while microservices try to minimize sharing through “context boundaries”.
Whether it is SOA or microservice, each independent system can be developed with different programming languages, as long as the interface protocol provided meets the standards. In the aspect of development, because microservices will adopt the strategy of smaller granularity, the number of services in the actual situation will be much more than that of SOA architecture. The architecture concept of microservices requires “rapid delivery”, and correspondingly requires the best practices related to agile development, such as automated testing, continuous integration and automated deployment. Without the support of these basic capabilities, once the scale of micro services becomes larger (for example, more than 20 micro services), it will be difficult to meet the requirements of rapid delivery as a whole. This is also an obvious pit that many enterprises have stepped on when implementing micro services, that is, the cost of deployment increases exponentially after the system is split into micro services.
If the infrastructure of rapid delivery within the enterprise is relatively weak, it may encounter the problem of deployment cost in the later stage by using micro service architecture.
Microservice is suitable for those Internet applications that need fast delivery and lightweight. Modern Internet is changing rapidly, every system needs to try and deliver quickly, which is one of the main reasons for the emergence of micro service architecture. Because each service can be deployed separately, it is easier to scale horizontally in the case of large concurrency. Even if one service is down, it will not affect the normal operation of other services. SOA, due to the existence of ESB, will affect the normal operation of all systems once the ESB is down.
Compared with microservices, SOA is more suitable for those enterprise level systems with small visits but large and complex business system. When an enterprise level system develops to a certain extent, SOA will emerge at the historic moment, and this system will continue for a long time. During this period, different technology stacks will be used to develop different systems, and these systems will be continuously integrated. If you want to start over or carry out large-scale optimization, the human and material resources will not be worth the loss, Therefore, such a system can only continue in a compatible way, and the important component that undertakes the communication of various heterogeneous systems is ESB.
SOA and microservice are essentially two different architecture design concepts, even though they have intersection in the concept of service and division. Because there are two different architecture patterns, there is no one better or worse in the application, only whether it is suitable or not. The specific architecture design depends on your application scenario and purpose. SOA is more suitable for large and complex enterprise application environments that need to integrate with many other applications. That is to say, small applications are not suitable for SOA architecture because they do not require message middleware components. And microservice architecture, on the other hand, is more suitable for smaller and well segmented, web-based systems. If you are developing Internet applications, and there are no historical problems, please give priority to the adoption of microservice architecture.
|System division||Big business logic||Single task or small business logic|
|system communication||ESB||Unified protocol standard|
|Service delivery||Manual delivery||Automated rapid delivery|
|Applicable scenarios||Inside the enterprise||Internet applications|
|Administration||Focus on central management||Focus on decentralized management|
|extend||Hard to expand||It’s easy to scale out a single service|
More wonderful articles