Microservices architecture is a hot concept at present. It is not a vacuum, but an inevitable result of technological development. Though micro service architecture not accepted draft technical standards and norms, but the industry has some very influential platform for the open source micro service architecture, the architect can according to the technical strength of the company and according to the characteristics of the project to select a suitable platform for the micro service architecture, in order to safely implement projects of renovation and development process of service.
This paper summarizes four commonly used microservices architecture solutions, including ZeroC IceGrid, Spring Cloud, Message queue-based and Docker Swarm.
ZeroC IceGrid microservices architecture
ZeroC IceGrid, as a microservice architecture, is developed based on RPC framework and has good performance and distributed capability. The overall schematic diagram of ZeroC IceGrid is shown below.
IceGrid has the following obvious characteristics of the microservices architecture.
First, the microservices architecture requires a centralized service registry and some sort of service discovery mechanism. IceGrid service Registry is defined in XML files. The service Registry is Ice Registry, which is a separate process and provides HA high availability mechanism. The corresponding service discovery mechanism is named query service, that is, the API provided by LocatorService. You can query the available address of the corresponding service instance based on the service name.
Second, each microservice in a microservice architecture is typically deployed as a separate process, and when stateless services are available, they are typically serviced by multiple separate processes. In IceGrid, an IceBox is a separate process, and when an IceBox encapsulates only one Servant, it is a typical microserver process.
Then, microservice architectures typically need to have some kind of load balancing mechanism built into them. IceGrid is implemented through the load balancing algorithm embedded in client API. Compared with the way of traffic forwarding by middleware Proxy, IceGrid is more efficient, but it increases the workload and difficulty of platform development, because clients using various languages need to implement the algorithm logic of load balancing.
Finally, a good microservices architecture platform should simplify and facilitate application deployment. We see that IceGrid provides grid.xml to describe and define an Application based on a microservice architecture, a command-line tool to deploy the Application with one click, and an aid tool for publishing binaries, ICepatch2. The following figure shows how icepatch2 works. Icepatch2server is similar to the FTP server. It is used to store binary code and configuration files to be published to each Node. The ICepatch2Client on each Node pulls files from the ICepatch2Server. Advanced features such as compressed transfer and differential transfer are used to reduce unnecessary file transfer. Objectively, before Docker technology, icepatch2 was very advanced and complete, which greatly reduced the operation and maintenance workload of microservice system in distributed cluster.
If you develop a system based on IceGrid, there are usually three typical technical scenarios, which are shown in the figure below.
The first scheme is a gradual transformation scheme in line with traditional Java Web projects. Spring Boot has only Controller components but no data access layer and Service objects. These Controller components invoke remote Ice microservices deployed in IceGrid via Ice RPC, wrapped as REST services for the front end. The overall idea of this scheme is clear and the division of labor is clear. Leader provides a basic framework for this approach in his open source project: github.com/MyCATApach…. .
Solution 2 and Solution 3 are more suitable for teams with strong front-end JavaScript skills, such as those who are good at Node.js. Solution 2 is to use JavaScript instead of Spring Boot to implement REST services. For web apps, consider solution three, where browser-side JavaScript communicates directly with Ice Glacier2 using HTML5 WebSocket technology, which is efficient and agile.
IceGrid has also been containerized since version 3.6. Ice Nodes and Ice Registry can be started as Docker containers, which simplifies IceGrid deployment on Linux. For the Ice microservice architecture system written in Java, we can also use the Java remote class loading mechanism to make each Node automatically download the specified Jar package from a remote HTTP Server and load the relevant Servant classes, so as to achieve a mechanism similar to Docker Hub. The following figure shows the implementation of the myCAT-ICE open source project mentioned earlier.
Spring Cloud microservices architecture
Spring Cloud is a complete framework for implementing microservices based on Spring Boot, so it can only use the Java language, which is the most obvious difference between it and several other microservices frameworks. Spring Cloud is an overall plan that contains many sub-projects, among which Spring Cloud Netflix, developed by Netflix and later incorporated into Spring Cloud, is the core project of Spring Cloud micro-service architecture. That is, we can simply think of the Spring Cloud microservice architecture as Spring Cloud Netflix. If we use Spring Cloud later, it means Spring Cloud Netflix unless explicitly stated.
First, the service registry in Spring Cloud is the Eureka module, which provides a service registry, a service discovery client, and a simple management interface. All services use Eureka’s service discovery client to register themselves with Eureka, as shown in the diagram below. You’ll notice that it looks a lot like one of the previous diagrams in Chapter 4.
So how does Spring Cloud solve the problem of load balancing for services? Since Spring Cloud’s microservices interface is mainly implemented based on the REST protocol, it adopts the traditional HTTP Proxy mechanism. As shown in the figure below, Zuul acts like an Nginx service gateway through which all client requests access the back-end services.
Zuul obtains service information from Eureka and automatically maps routing rules without manual configuration. For example, the URL path /customer/* in the figure above is mapped to the customer micro service. When Zuul forwards a request to a specific microservice, it uses a client-side load balancing mechanism similar to ZeroC IceGrid, called the Ribbon component. The following figure shows Zuul’s relationship with Eureka and its service load balancing.
Below is a panoramic view of the Spring Cloud microservices architecture platform. We see that it clearly inherits the philosophy of the Spring Framework — integration!
As shown in the figure, the Spring Cloud microservices architecture platform integrates the following technical and functional modules commonly used in actual project development.
OAuth module based on Spring Security to solve service Security problems.
The ability to provide Composite Services.
Hystrix is a circuit breaker that fuses certain critical service interfaces. If a service is not responding (such as a timeout or a network connection failure), Hystrix can redirect the request to the fallback method in the service consumer. If the service fails repeatedly, Hystrix will fail quickly (for example, by directly calling the internal fallback method and not trying to call the service again) until the service is restored.
Dashboards for monitoring can simplify o&M related development efforts.
In general, Spring Cloud is a good alternative to Dubbo, although Spring Cloud is a microservice architecture based on REST communication interfaces, while Dubbo is based on RPC communication. Spring Cloud is a relatively low threshold solution for Java Internet business platform with low performance requirements.
Message queue-based microservices architecture
In addition to standard rPC-based communications (and RPC-like communications such as Http Rest, SOAP, etc.), there are microservices architectures based on message queue communication, Microservices in this architecture interact with each other by publishing messages and subscribing messages. The diagram below shows the interaction between various components in this microservice architecture. We can see that message-oriented middleware is the key, which is responsible for connecting various microservices and UI components, and is responsible for the interconnection of the whole system.
Micro service architecture based on message queue is a design full of asynchronous communication mode, there is no direct coupling relationship between each component, there is no service interface and service invocation, between services through the message to realize mutual communication and drive business processes, from this point of view, based on message queue micro service architecture is very close to the Actor model. In fact, the distributed Actor model can also be considered a microservice architecture, and has been around long before the concept of microservices existed. The following is a shopping website microservice design diagram, we see that it adopts the message queue-based microservice architecture.
The Honeycomb platform of netease adopts the design idea of message queue-based micro-service architecture. As shown in the figure below, micro-services communicate with each other through RabbitMQ.
Compared with the above microservice architectures, there are not many microservice architectures based on message queue, and there are relatively few cases, which are more reflected as a kind of design experience related to business. Each country has its own way of implementation, lacks recognized design ideas and reference architectures, and has not formed a well-known open source platform. Therefore, if such micro-service architecture needs to be implemented, the project team basically needs to design and implement a basic platform of micro-service architecture from scratch. The cost is high and the risk is high. Therefore, the architect needs to make an overall thinking and objective evaluation before making a decision.
Docker Swarm microservices architecture
Docker Swarm is actually a product of Docker that “highly copies” Google’s open source Kubernetes micro-service architecture platform. However, Docker has been unable to keep up with its rivals and lacks influence in the industry. When Docker 1.12 was released in 2016, Docker Swarm was forcibly integrated into Docker Engine instead of being released as a separate tool, which is similar to the way Microsoft promoted Internet Explorer. But even then, it’s hard to hide the fact that Docker Swarm didn’t make it to the big time.
Docker Swarm the initial goal of Docker Swarm is to turn some independent Docker hosts into a cluster. As shown in the following figure, we can create a Swarm by simple Docker command line tools.
As The Kubernetes microservices platform became more popular, Docker tried to make Swarm more like Kubernetes, a container-based microservices platform. The structure diagram of Swarm cluster is shown below.
A Swarm cluster has two types of nodes.
Swarm Manager: Responsible for cluster management, maintenance of cluster status, and scheduling tasks to work nodes.
Swarm Node: host a Swarm Node. Each Node reports tasks running on it and maintains synchronization status.
Docker Compose is an official Orchestration project that provides a YAML format file describing a containerized distributed application and tools for one-click deployment. The following figure shows the YAML file definition for a two-node Couchbase cluster, which was then deployed to two nodes in the Swarm cluster.
Note the “Services” definition in the YAML file on the left in the image above. Swarm Manager assigns a unique DNS name to each Service, so it is possible to discover and load balance Services through the oldest and simplest DNS polling mechanism, clearly borrowed from Kubernetes. Docker Swarm highly copies the design of its predecessor Kubernetes and does not have much influence in the micro-service architecture, so we do not give an in-depth introduction here.