In the construction of micro service, ESB should be considered, and ESB must also be considered. What is the difference between ESB and microservice in the same service-oriented architecture? How should ESB be placed in the construction of micro service? Under the background that the new architecture will eventually replace the corrupt traditional architecture, how to migrate and replace to ensure business availability? The following content will give you a detailed analysis.
SOA and ESB
The development of technical architecture has its laws to follow. From monomer to vertical splitting, then to service-oriented, and finally to distributed micro services, it is divided into parts from the perspective of technical architecture, and from the perspective of service management, it is from single management to centralized management. After service-oriented, that is, after service-oriented architecture is proposed, in addition to microservices, SOA and ESB are also well-known architectures:
SOA Architecture: in fact, it is a design concept without architecture and technology dependence. It is just that multiple services are deployed and run in an independent form. Services are called through the network, and finally provide a series of complete functions.
ESB: enterprise service bus, which is used to connect various service nodes. The communication between services is routed and forwarded through ESB. The most important thing is that different applications may have different protocols and messages. The biggest function of ESB is to solve the interconnection between different services. Therefore, ESB is actually an implementation form of SOA.
Characteristics of microservices
Looking at the above description of SOA, does it feel similar to the microservice architecture? In other words, microservices are the sublimation of SOA. So what is the difference between microservices and SOA and ESB?
Let’s take a look at the advantages of microservice:
1. Independence, focus and autonomy
You can deploy and run independently, use a separate database, or even use a separate front end. In this way, the influence surface of the fault can be reduced, and there will be no pulling and starting the whole body.
Focus on your own business, such as report service. If you only focus on reports, you can focus on report business. You don’t need to consider monitoring, alarm and log. You only need to input data to generate reports.
The R & D team is autonomous, which can pull up a small team of three or five people to do only report related functions and businesses, with high efficiency, high professionalism, high production quality and value.
2. Distributed, high availability, capacity expansion, resource allocation
Microservice framework supports distributed deployment and operation mode, and solves the problem of high availability of services.
Through the service discovery of the registry, the dynamic expansion and contraction of services can be realized, and the horizontal expansion and contraction capacity can be automatically adjusted according to the amount of business concurrency.
Adjust the resource allocation of services according to different business modules. For example, in the financial system, the user management module (user addition, deletion and modification) is used less frequently, and a single copy user service with less resources can be deployed; However, the accounting module is used very frequently, reaching hundreds of orders every day. It is possible to allocate an accounting service with multiple resources and multiple copies. However, if it is not a micro service architecture, it is necessary to expand the overall capacity of the system to meet the modules with the maximum business volume, which will cause a waste of resources of other modules.
3. Service decoupling and service
After splitting the microservices, the dependencies between services will be provided through network transmission. In other words, a service only needs to provide the required functional interfaces to meet the overall business implementation. Therefore, it is not necessary to consider what programming language the microservice uses and how to implement the business logic. It only needs to provide the functional interface (only focusing on the results). In this way, the service can be truly decoupled during development, management and use, and will not be restricted by the development framework and development mode.
After microservicing, not only the system can use the business capability of the service, but other departments or systems in need can also call the microservice through the interface to provide its business processing capability.
ESB vs. microservice
1. Independent but not free. Compared with microservices, SOA architecture can deploy business services independently, but it is not free enough. It can not communicate freely like microservices. It can only do service communication through ESB. All service communication needs ESB forwarding, centralized management at ESB, and configure permissions and policies.
2. For non distributed solutions, the high availability of services cannot be solved by the framework as a whole, but only by traditional methods. Therefore, it is impossible to realize lateral dynamic expansion and contraction.
3. Although ESB is also a service-oriented framework, it can not really realize servitization. Service should be a self consumption mode. After the service capability of micro services is provided, users can subscribe. However, in ESB, service capabilities are only provided for certain services in specific scenarios. If other services want to be used, they need to be customized.
4. In the same way as self consumption, service providers cannot realize automatic service provision. Corresponding interfaces need to be added in ESB to facilitate service provision of corresponding business capabilities. Therefore, in the construction of ESB, the specified interfaces to be exposed will be formulated in advance. If there are new requirements, they need to be customized. What microservices provide is a microservice platform. As long as specific agreements are followed, whether services are provided or used, they can go online, offline, increase or decrease freely.
5. Microservice architecture is a new service architecture, while ESB architecture is easy to corrupt and difficult to maintain. The technical core is not open source and is bound by manufacturers. Microservices are basically new technologies based on open source, without corruption, and can independently master the core technology.
6. ESB is a centralized service management mode. The performance of ESB will determine the overall communication performance of the group. Due to too “centralization”, once the bus fails, the information system of the whole group will face the risk of “paralysis”. Microservices are different. Microservices adopt a decentralized scheme, and the problem of any component will not affect the global business.
ESB will eventually be replaced
The business continues to grow, so it needs continuous technological innovation to promote the continuous progress of the technical framework. The source of all changes is the change of business, and the business consumption has increased exponentially, so the service is required to expand and shrink freely; The continuous increase of new businesses requires services to support dynamic operation and management. The ESB architecture is too rigid, and it is no longer suitable for service governance under the original physiological concept of cloud.
The old system architecture is gradually unable to support, and the new micro service architecture came into being. Under the guidance of this trend, we began to build micro service, but how to place the ESB during the construction of micro service is a big problem. The interconnection of most systems in the enterprise depends on the ESB service bus, but at the same time, the transformation of all ESB connected systems will have a huge amount of work, low fault tolerance and high risk. Therefore, although the replacement of ESB is imperative, it also needs careful planning.
Generally, the transformation of ESB needs to adopt the method of gradual transformation and gradual migration. According to the current situation of different systems, corresponding methods shall be adopted:
If the system undergoing in-depth transformation is split and transformed into a microservice system, the previous call mode can be directly modified into a microservice call mode. In our microservice construction, we need to make corresponding construction planning according to the actual situation;
The system that supports light modification does not do microservice splitting, but can modify the calling or access mode and address. This part of the system can directly replace the calling address with the address of the API gateway. The API gateway provides the functions of the original ESB, such as protocol conversion, routing forwarding, authentication control, etc., and replaces the ESB agent;
For systems that do not accept transformation at all, or systems that rely heavily on ESB, the ESB cannot be replaced before in-depth transformation, so it is still necessary to retain the ESB. However, it is necessary to consider the communication between the newly transformed or incremental micro service system and the ESB and the old system. Therefore, it is necessary to be compatible and managed for the running ESB.
At the initial stage of microservice construction, ESB cannot be completely replaced or replaced because of its key role in the enterprise. Therefore, there needs to be a transition period: it is compatible with the services of managing ESB through the microservice management console; Convert messages through API gateway, route and forward ESB interface, so as to ensure the compatibility, management and interconnection between the existing system and the incremental or modified system.
In fact, the functions of ESB, such as routing and forwarding, are very similar to those of API gateway. Next, we will focus on the differences and advantages and disadvantages between the role of API gateway in microservices and ESB. Please look forward to it.