The ESB should and must be considered in microservitization. So what’s the difference between an ESB and a microservice in the same service-oriented architecture? How should the construction of microservitization accommodate the ESB? How to migrate, replace, and maintain business availability in the context that new architectures will eventually replace corrupt traditional architectures? In the following content, I will give you a detailed analysis.
SOA and ESB
The development of technology architecture has its own rules to follow, from monomer to vertical separation, to service-oriented, and finally to distributed micro services. From the perspective of technology architecture, the whole is broken into pieces, and from the perspective of service management, the management is from a 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 architecture:
SOA architecture: In fact, it is a design concept that does not depend on architecture and technology, but only 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, used to connect service nodes. Communication between services is routed and forwarded through the ESB. Most importantly, different applications may have different protocols and packets, and the biggest function of an ESB is to solve the interconnection between different services. So, the ESB is actually an implementation of SOA.
Features of microservices
Looking at the above description of SOA, does it feel similar to microservices 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 microservices:
1. Independence, focus, 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 pull the whole body.
Focus on your own services, for example, report services. If you only 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 professional degree, high quality and value.
2. Distributed, high availability, capacity expansion and resource allocation
Microservices framework, support distributed deployment and operation mode, solve the high availability of services.
Through service discovery in the registry, the capacity of services can be dynamically expanded or shrunk, and the horizontal capacity can be automatically adjusted according to the amount of concurrent services.
You can adjust the service resource ratio based on service modules. For example, in the financial system, the user management module (user adding, deleting and changing) use frequency is low, can deploy a resource less, single copy of the user service; However, the accounting module is used very frequently, reaching hundreds of orders every day, which may allocate an accounting service with multiple or multiple copies of resources. However, if it is not a micro-service architecture, the overall system expansion is required to meet the requirements of the modules with the maximum business volume, which will cause resource waste of other modules.
3. Service decoupling and servitization
After splitting microservices, dependencies between services are provided over the network. That is to say, a service only needs to provide the required functional interface to satisfy the overall business implementation. As a result, it doesn’t matter what programming language a microservice uses or how the business logic is implemented, it just needs to provide the functional interface it needs (focus only on the result). In this way, services can be truly decoupled when they are developed, managed, and used, without being restricted by development frameworks and development patterns.
After microservitization, 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 the business processing capability.
Esbs versus microservices
1. Independence but not freedom. Compared with microservices, SOA architecture can deploy business services independently, but it is not free enough to communicate with each other as freely as microservices. Service communication can only be done through THE ESB. All service communication needs to be forwarded by the ESB, and centralized management, permissions and policies are configured on the ESB.
2, non-distributed solution, high availability of services can not be solved through the framework as a whole, only through the traditional way to solve. Therefore, it is more impossible to achieve horizontal dynamic expansion and shrinkage capacity.
3. An ESB, although a service-oriented framework, is not truly service-oriented. Servitization should be the mode of self-consumption. After the service capability of microservices is provided, users can realize subscription and use. But in an ESB, service capabilities are provided only for a few services in a particular scenario, and other services need to be added through customization if they are to be used.
4. As with self-consumption, the service provider cannot automate the service provision, and the ESB needs to add corresponding interfaces to enable the service to provide corresponding business capabilities. Therefore, in ESB construction, the specified interfaces that need to be exposed are mapped out in advance, and if there are new requirements, they need to be customized. Microservices, on the other hand, provide a micro-service platform. As long as a specific agreement is followed, no matter whether the service is provided or used, it can be added or deleted freely.
5. Microservice architecture is a new type of service-oriented architecture, while ESB architecture is easy to corrupt and difficult to maintain, with non-open source technology core and vendor binding. Microservices are basically based on new technologies that are open source, without corruption, and can master the core technology independently.
6. The ESB is a centralized service management model. The performance of the ESB will determine the overall communication performance of the group, and because of the “centralization”, the information system of the whole group will face the risk of “paralysis” if the bus fails. Microservices, on the other hand, are decentralized so that problems in any one component do not affect the overall business.
The ESB will eventually be replaced
The business continues to grow, which requires constant technological innovation, and the enabling technology framework continues to evolve. The source of all changes is in the change of business, business consumption into geometric growth, so it requires that the service can freely expand capacity; The growing number of new businesses requires services to support dynamic operations and management. The ESB architecture is too rigid for cloud native service governance.
Under the guidance of this trend, we started to do the micro-service construction. However, how to install the ESB during the micro-service construction is a big problem. The interconnection of most systems in an enterprise depends on the SERVICE bus of the ESB. However, the transformation of all the systems connected by the ESB at the same time is a huge project, with low fault tolerance, and high risk. So the replacement of the ESB, while inevitable, requires careful planning.
Generally, the transformation of ESB needs to adopt the mode of gradual transformation and gradual migration. According to the different system status quo, the corresponding methods are as follows:
The system that accepts deep transformation can be transformed into a micro-service system through splitting, so the previous invocation mode can be directly modified into the invocation mode of micro-service. This part needs to be planned according to the actual situation in our micro-service construction.
Systems that support minor modifications do not do micro-servitization, but can modify how and where the call or access is made. This part of the system can directly replace the calling address with the ADDRESS of the API gateway. Through the API gateway, the functions of the original ESB such as protocol translation, routing and forwarding, authentication control and so on can be provided to replace the proxy of the ESB.
Systems that are completely unreformed, or systems that are so heavily dependent on the ESB that the ESB cannot be replaced until there is a deep transformation, still need to be retained. But new, or incremental, microservice systems need to be considered for communication with the ESB, as well as with older systems, so compatibility and management of the running ESB need to be done.
In the early days of microservices construction, the ESB cannot be completely replaced or replaced due to its critical role in the enterprise, so there needs to be a transition period: through the microservices manager, which also accommodates the services of the managed ESB; The API gateway translates packets, routes and forwards the ESB interfaces, and ensures that the existing systems are compatible, managed, and interconnected with the incremental or modified systems.
In fact, the functions of an ESB, routing and forwarding, are very similar to those of an API gateway. Stay tuned as we focus on the differences and pros and cons of the API gateway’s role in microservices versus the ESB.