A microservice application consists of hundreds of services, which adopt different languages and frameworks. Each service can have its own deployment, resources, expansion and monitoring requirements. For example, you can run several service instances according to service requirements. In addition, each instance must have its own CPU, memory and I / O resources. Although it is complex, the more challenge is that service deployment must be fast, reliable and cost-effective.
Single host multi service instance mode
Using the single host multi service instance mode, you need to provide several physical or virtual machines, and each machine runs multiple service instances. In many cases, this is the traditional application deployment method. Each service instance runs the well-known port of one or more hosts.
This pattern has a parameter representing how many processes each service instance consists of. For example, you can deploy a Java service instance on Tomcat as a web application; A node.js service instance may consist of a parent process and several child processes. This mode has another parameter that defines how many service instances are running in the same process group. For example, you can run multiple Java Web applications on the same Tomcat or multiple OSGi bundle instances in the same OSGi container.
One of the disadvantages of the single host multi service instance model is that there is little or no isolation between service instances, unless each service instance is an independent process. If you want to accurately monitor the resource usage of each service instance, you cannot limit the resource usage of each instance. Therefore, a bad service instance may occupy all the memory or CPU of the host.
The second disadvantage of the single host multi service instance model is that the operation and maintenance team must know the detailed steps of how to deploy. Services can be written in different languages and frameworks, so the development team must have a lot to communicate with the operation and maintenance team. The complexity increases the possibility of errors in the deployment process.
Single host single service instance mode
Using the single host single instance mode, the service instances on each host are independent. There are two different implementation modes: single virtual machine single instance and single container single instance.
Single virtual machine single service instance mode
Using single virtual machine and single instance mode, services are generally packaged into virtual machine images. Each service instance is a VM started with this image. The following figure shows this architecture:
- Resource utilization efficiency is not high. Each service instance occupies the resources of the whole virtual machine, including the operating system.
- IAAs charges according to the VM, regardless of whether the virtual machine is busy or not.
- Deploying the new version of the service is slow. Virtual machine image creation is slow due to size. For the same reason, virtual machine initialization is slow, and it takes time for the operating system to start.
- The operation and maintenance team has a lot of work to create and manage virtual machines.
Single container single service instance mode
When using the single container single service instance pattern, each service instance runs in its own container. Container is a virtualization mechanism running at the operating system level. A container contains several processes running in a sandbox. From a process perspective, they have their own namespace and root file system; You can limit the container’s memory and CPU resources. Some containers also have I / O restrictions. Such container technologies include docker and Solaris zones. The following figure shows this mode:
Using this pattern requires that the service be packaged into a container image. A container image is a file system that runs libraries and applications that contain services. Some container images consist of a complete Linux root file system, while others are lightweight. For example, in order to deploy Java services, you need to create a container image containing the Java runtime, perhaps tomcat, and compiled Java applications.
Once the service is packaged into a container image, several containers need to be started. Generally, multiple containers are run on one physical machine or virtual machine. Cluster management system, such as k8s or marathon, may be required to manage containers. The cluster management system regards the host as a resource pool and decides to schedule the container to that host according to the resource requirements of each container.
The advantages of containers are very similar to virtual machines. Service instances are completely independent, and it is easy to monitor the resources consumed by each container. Similar to the virtual machine, the container uses isolation technology to deploy services. The container management API can also be used as an API for managing services.
However, unlike virtual machines, containers are a lightweight technology. The container image is created quickly and the container starts quickly.