** The ESB should and must be considered in microservitization construction. ** How does an ESB differ from a microservice as well as a service-oriented architecture? How should an ESB be placed in microservitization construction? In the context of the new architecture replacing the corrupt traditional architecture, how to migrate, replace and ensure the availability of business? 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 separation, then to service-oriented, and finally to distributed micro-services. From the perspective of technical architecture, the whole is divided into parts, and from the perspective of service management, it is from single management to centralized management. In addition to microservices, SOA and ESB are also well-known architectures after servitization, that is, after the introduction of service-oriented architectures:

  • SOA architecture: In fact, it is a design concept without the dependence of architecture and technology, but multiple services are deployed and run independently. Services are called through the network, and finally provide a series of complete functions.

  • ESB: An enterprise service bus that connects service nodes and routes and forwards traffic between services through the ESB. Most importantly, different applications may have different protocols and messages, and the biggest function of an ESB is to facilitate the intercommunication between different services. So, an ESB is actually an implementation of SOA.

Features of microservices

Looking at the description of SOA above, does it feel like a microservice architecture? Or microservices are the distillation of SOA. So how are microservices different from SOA and ESB?

Let’s take a look at the advantages of micro services:

1. Independence, focus and autonomy

  • It can be deployed independently, run independently, use a separate database, and even use a separate front end. This can reduce the impact of the fault surface, there will not be a drag on the whole thing.

  • Focus on your own services, such as report services. If you focus on reports, you can focus on report services without considering monitoring, alarms, and logs. You only need to input data and generate reports.

  • Research and development team autonomy, can pull up a small team of three or five people, only report related functions and business, high efficiency, high degree of professionalism, high quality and value.

2, distributed, high availability, scaling, resource allocation

  • Microservices framework, supporting distributed deployment and operation mode, solves the problem of high availability of services.

  • You can discover services in the registry to implement dynamic service expansion and expansion. The expansion capacity can be automatically adjusted based on the number of concurrent services.

  • Adjust the resource ratio of services based on service modules. For example, in the financial system, the user management module (user adding, deleting and modifying) is used less frequently, so a user service with less resources and a single copy can be deployed. However, the accounting module is used extremely frequently, reaching hundreds of orders every day, which may allocate a multi-resource and multi-copy accounting service. However, in the case of non-microservice architecture, the overall expansion of the system is required to meet the module with the largest business volume, which will cause the resource waste of other modules.

3. Service decoupling and servitization

  • After the separation of microservices, dependencies between services are provided over network transport. That is to say, a service only needs to provide the required functional interface to meet the overall business implementation. As a result, microservices don’t have to worry about what programming language they use or how they implement the business logic, just provide the functional interface (focusing only on the result). In this way, services can be truly decoupled when they are developed, managed and used, and will not be restricted by development frameworks and development modes.

  • After microservitization, not only the system can use the business capabilities of the service, but other departments or systems with needs can also call the microservice through interfaces to provide their business processing capabilities.

ESB contrast microservices

Independence is not free. ** Compared with microservices, SOA architecture can deploy business services independently, but it is not free enough to communicate with each other as microservices do. It can only do service communication through ESB. All service communication needs to be forwarded by ESB, managed centrally in ESB, and configured with 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 means. Therefore, it is impossible to achieve the horizontal dynamic expansion and contraction capacity.

3. An ESB, while a service-oriented framework, is not really servitization. Servitization should be the mode of self-consumption. After the service capability of micro-service is provided, users can realize subscription. In an ESB, however, service capabilities are provided for use only by a few services in a particular scenario, and other services need to be added through customization if they are to be used.

4. Similar to self-consumption, service providers cannot implement automated service provision, and corresponding interfaces need to be added in the ESB to enable the service to provide corresponding business capabilities. So in ESB construction, specific interfaces that need to be exposed are mapped out in advance and customized if new requirements arise. However, micro-service is a micro-service platform. As long as the specific protocol is followed, both the provision and use of services can be added or deleted freely.

5. Microservice architecture is the new servitization architecture, while ESB architecture is easily corrupted and difficult to maintain, with non-open source technology core and vendor binding. Microservices are basically new technologies based on open source, free of corruption and able to master the core technologies themselves.

6. ESB is a centralized service management mode. The performance of ESB will determine the overall communication performance of the group. Microservices, on the other hand, adopt a decentralized solution, and the failure of any one component does not affect the global business.

The ESB will eventually be replaced

The business continues to grow, so technology continues to evolve and the technology framework continues to evolve. The source of all changes is the change of business. Business consumption increases geometrically, so the service is required to expand and shrink freely. The increasing number of new businesses requires services to support dynamic operations and management. The ESB architecture is too rigid and is not suitable for service governance under the cloud native concept.

The old system architecture is gradually unable to support, and the new microservice architecture comes into being. Under the guidance of this trend, we start the construction of microservice, but how to place the ESB during the construction of microservice is a big problem. The interconnectivity of most systems in an enterprise depends on the ESB service bus, but transforming all esB-connected systems at the same time can be a huge amount of engineering, low fault tolerance, and high risk. So the replacement of an ESB, while imperative, needs careful planning.

In general, the transformation of ESB needs to adopt the method of gradual transformation and gradual migration, and make corresponding treatment according to different system status:

  • The system that accepts deep transformation can be divided and transformed into microservice system, so the previous call mode can be directly modified into the call mode of microservice. In our microservice construction, corresponding construction planning should be made according to the actual situation.

  • Support for mildly modified systems that do not do microservitization, but can modify the method and address of the call or access. This subsystem can directly change the calling address into the ADDRESS of the API gateway, through which the functions of the original ESB, such as protocol conversion, routing and forwarding, authentication control and so on, can be provided to replace the proxy of the ESB.

  • Systems that do not accept transformation at all, or that rely so heavily on the ESB that the ESB cannot be replaced until further transformation is made, need to retain the ESB. But new, or incremental, microservice systems need to be considered for communication with the ESB and with older systems, so the running ESBs need to be compatible and managed.

In the early stages of microservice construction, the ESB cannot be completely replaced or replaced due to the key role it plays in the enterprise, so there needs to be a transition period: through the microservice management console, which also hosts the services of the ESB; Through the API gateway, packets are converted and the ESB interfaces are routed and forwarded to ensure the compatible management and interconnection between the existing system and the incremental or modified system.

The functionality of an ESB, routing and forwarding, is very similar to the functionality of an API gateway. Next, we’ll focus on the differences and pros and cons of API gateways in microservices versus ESBs.