How to deploy applications under the microservice architecture? ?

A microservice application is composed of hundreds of services, which use 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 complicated, it is even more challenging that service deployment must be fast, reliable, and cost-effective.

Single host multi-service instance mode

To use 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 one or more well-known ports of the host.

This model has a parameter that represents how many processes each service instance consists of. For example, a Java service instance can be deployed as a web application on Tomcat; and 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 run multiple OSGI bundled 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, it is possible that a bad service instance occupies 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 many things to communicate with the operation and maintenance team. The complexity increases the possibility of errors during 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 the single virtual machine single instance mode, the service is generally packaged into a virtual machine image. 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 entire virtual machine, including the operating system.
• IaaS charges based on the VM, regardless of whether the virtual machine is busy.
• Deploying the new version of the service is slow. Virtual machine images are relatively slow to create due to their size. For the same reason, virtual machine initialization is also relatively slow, and operating system startup also takes time.
• 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 mode, each service instance runs in its own container. The 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; they can limit the memory and CPU resources of the container. Some containers also have I/O restrictions. Such container technologies include Docker and Solaris Zones. The following figure shows this pattern:

To use this mode, the service needs to be packaged into a container image. A container image is a file system that runs the libraries and applications required for services. Some container images consist of a complete Linux root file system, others are lightweight. For example, in order to deploy a Java service, you need to create a container image that contains a Java runtime library, 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 a physical machine or virtual machine, and a cluster management system, such as k8s or Marathon, may be required to manage the containers. The cluster management system uses the host as a resource pool, and decides which host to schedule the container on according to the resource requirements of each container.

The advantages of containers are similar to those of virtual machines. Service instances are completely independent, and the resources consumed by each container can be easily monitored. Similar to virtual machines, containers use isolation technology to deploy services. The container management API can also be used as an API for management services.

However, unlike virtual machines, containers are a lightweight technology. The container image is created quickly, and the container starts quickly.

maping930883.blogspot.com/2016/06/architect021.html