A key topic for everyone to talk about microservices is “service splitting.” Service split generally means that for a complete business system, we need to split the business into some independent service components based on some factors and mechanisms. These service components are independently developed, independently managed, and provide standard services to the outside world. In Kato, we often say “a component deployed to Kato is a microservice”. If the business is a legacy system, integrated architecture. Then you don’t need to think about how to split it, just deploy it to Kato first, and use the microservice system to manage it first. It is nothing more than a service type that provides a variety of businesses, with poor sharing attributes. If your business has been developed in accordance with the microservice model, such as based on the SpringCloud microservice architecture framework. Then you may not have the trouble of splitting. However, all service components need to be efficiently managed and continuously developed.
Therefore, this article mainly talks about the service assembly of the business system in Kato. Maybe your business currently adopts various technical architectures, including legacy integrated architecture, Spring Cloud architecture, Dubbo architecture, and so on. We deploy them to the Kato platform for assembly.
- Have mastered the various component creation methods of Kato reference document
- Have mastered the principle and usage of the communication between Kato components reference document
- Have mastered the usage of Kato service network management plug-in reference document
Based on ServiceMesh Assembly
The key to service assembly is to clarify the direct communication dependencies of services. Establish component dependencies based on communication relationships. In the application, business components can be added or removed at any time as needed, and the dependencies between components can be dynamically added and removed. Use ServiceMesh Traffic Routing Management to control the communication between components.
Only the microservice architecture assembled by ServiceMesh can view the relationship between components in the application topology.
Based on SpringCloud Architecture Assembly
If your application is developed based on SpringCloud, the same is the deployment of a service and a component to Kato for assembly. Different from ServiceMesh-based, the communication relationship between services is bridged by SpringCloud’s service registry for service registration and direct communication. In other words, Kato cannot obtain the direct communication dependency of the service, so it is not displayed in the topology diagram. But the key is the integration of Kato ServiceMesh and SpringCloud. As shown in the figure below, the communication between all services and the registry and database is done through ServiceMesh, and the communication from UI to Gateway is done by ServiceMesh.
Whether to support mixed assembly of multiple architectures
The key to service assembly is how the communicating parties conduct service discovery and what protocol they communicate. In Kato, by supporting the 7-layer Restful protocol and the 4-layer TCP/UDP protocol, it can support mixed assembly of various architectures.