Author: Zhu Mingzhi, a research and development expert
Introduction: With the gradual rise of containerization concept represented by Docker, a large number of companies and enterprises using distributed architecture begin to consider containerization upgrade of the original system. Why do traditional distributed architectures need containerization? What are the opportunities and challenges facing containerization? As an intelligent big data service provider, how does individual push container landing? What will happen in the future? This paper takes the practice of individual push in containerization as an example to discuss and prospect with everyone.
Characteristics of traditional distributed architecture
Traditional distributed architecture systems generally have the following two characteristics:
Traditional distributed architecture systems are divided into modules based on business and resource consumption. For example: According to the business differentiation, Getui will divide into different system modules, including client CM module that establishes long connection with mobile phone SDK, and IM module that is responsible for message routing; Depending on resource consumption, the user modules that read and write multiple Redis and MySQL will be split into different roles.
In traditional distributed architecture, there are multiple instances of the same role module. This system, on the one hand, achieves high availability and does not affect the whole business when a server goes down. On the other hand, when the pressure increases, it is convenient to increase throughput through expansion. For example, when a Redis read-write role has more requests, the system only needs to expand the instance of that role.
Years of practice has proved that traditional distributed architecture system has obvious advantages of easy expansion, high reliability, high efficiency and low cost, but also has certain limitations.
Due to the complex character of role modules, traditional distributed architecture system is difficult to be completed manually in configuration management, service resource management and deployment environment. For example, for different versions of each business module, developers need to make configuration modifications one by one before going online. When specific features need to be modified, many modules are involved, creating a lot of repetitive work orders for developers.
So, how can we solve these problems and create an ideal online environment and a good visual management system? At this point, containerization comes to mind.
Opportunities and challenges of containerization
Containerization can effectively solve a series of problems of traditional distributed architecture system. Among them, Docker and Kubernetes are the most commonly used open source container engines and orchestration tools.
When Docker
Docker is easily the most popular open source container engine out there. The principle of Docker is to pack multiple applications and all the environments needed for operation through containers, so as to avoid many hidden dangers caused by irregular placement. For example, Docker can effectively avoid Java environment version differences, different applications influence each other, the use of resources competition and other problems.
When Docker is used, Docker image follows the layered strategy. First of all, each product line module of the push, using their own base image. Second, the service application of each product line is built on top of its own base mirror layer, which ensures that the operating environment of each container does not conflict with each other.
When Kubernetes
Kubernetes is an open source platform for automated deployment, expansion, and o&M of container clusters. The concept of Kubernetes is to guide the placement of each container, reduce the difficulty of server resources, so that operation and maintenance management becomes more convenient.
There are two main reasons for choosing Kubernetes as the tool for Docker container choreography.
One, a push encountered problems:
Version update iteration is fast
Many application processes consume large server resources
The server environment is inconsistent
DevOps needs to move forward
Two, Kubernetes advantages:
Operation and maintenance automation
The application container is built once
Computer hardware resources can be fully utilized
Layout management has outstanding advantages
In the process of using Docker and Kubernetes, Geturen benefited a lot, but also brought some pressure to the original distributed system structure of Geturen. For example, the original framework and modules of the individual push system need to be adapted. The original system is very large and needs to be gradually moved; There must be a trade-off between existing ecological services. Therefore, we explore this area through a landing containerization practice.
Push containerization practice
In one project, we carried out a full container practice.
Before the specific implementation, we first determine the overall architecture diagram, the architecture diagram contains some basic Kubernetes structure. For example, in the Master node deployment, APIserver is the control entrance of the entire system, Scheduler is responsible for task scheduling and command delivery, and Controller Manager is the management and control center within the cluster. In Node Node deployment, Kubelet acts as Agent to monitor and execute the tasks of the Node and report the status of the Node, while Proxy is responsible for the connection and forwarding of the whole network rules.
In practice, how to deploy stateful components successfully, how to realize intercommunication between Intranet and extranet, what kind of configuration center is required, and how to do monitoring are all problems that developers are prone to encounter.
◎ Deployment of stateful components
In Kubernetes, there are many stateless components that manage pods based on a stateless, one-time concept. A Replication Controller, for example, simply guarantees the number of pods available for service. If a Pod is deemed unhealthy, Kubernetes takes a very simple and crude approach to the Pod: delete it, rebuild it, and automatically expand and shrink it. This approach is generally applicable to business logic processing and memory computing programs.
However, Kubernetes can provide a unique flag to Pod through StatefulSet to ensure the successful deployment and orderly expansion of stateful components such as ZooKeeper, MySQL and Redis.
However, in order to satisfy the requirement that the service’s Pod lands in the same directory wherever it is placed, the stateful component must be mounted across the network when it is placed in the container. However, using a network volume for mounting is not as reliable as local mounting, and the network performance loss is tens of times higher than local mounting. At the same time, the maintenance operation of this component is not frequent, which does not bring much convenience for operation and maintenance. Therefore, all things considered, it does not put such stateful components into containers.
◎ Communication between internal and external networks
Communication between internal and external networks is a typical problem in the process of containerization. Twitter uses Calico to assign virtual addresses, so networks within the same cluster can communicate with each other. When a service in a cluster accesses external services, it can directly use the real physical address. When services outside the cluster access internal services, map virtual IP addresses to real IP addresses in iproute mode.
◎ Configuration Center
About the configuration center, you can first sort out some requirements, highlight the key points to solve one by one. The requirements of this containerization practice include configuration center clustering, WEB interface management and permission management, support for multiple environment configurations, simple development and integration, local backup, etc.
After researching a number of open source configuration centers, and comparing the features of QConf, Diamond, Xdiamond, Disconf, Apollo, McOnf, and XXL-conf, he chose Apollo with more features.
◎ Monitoring collection
Applications running in Kubernetes are prone to problems such as network isolation from the outside, life cycle managed by the cluster, running nodes are not fixed and so on. We made some adjustments to our own monitoring system, such as deploying the master service outside Kubernetes cluster and deploying Agent in each Pod of the cluster, so as to realize data collection, monitoring and reporting to the master service.
Future prospects for containerization
Finally, while learning from this experience, INDIVIDUAL Push hopes to make plans and prospects for the container practice in the future. For example, we could explore business monitoring and scaling, automated testing, and Stateful services further.
The combination of service monitoring and capacity expansion can identify false death and judge service pressure. Automated testing, by complementing automated tests for each business and module, can greatly reduce the cost of regression testing and better achieve the goal of rapid iteration and continuous delivery, which is a very important step in the DevOps process. Stateful service, with the subsequent development of Kubernetes related technologies, could help us find more appropriate container methods, so as to achieve complete container, or even cloud service.
Conclusion:
At present, containerization is very popular. Containerization has great advantages in cost control, service stability guarantee and work efficiency improvement. However, traditional distributed architecture often increases the difficulty of containerization transformation due to the stereotypical of its basic components and architecture, which makes it difficult to turn the ship around. In this article, I hope that the author’s share can help developers to better understand their thinking in the process of containerization.
It is important to note that the practice of containerization is not containerization for containerization’s sake, but rather to provide more efficient and stable system services through containerization based on a full understanding of existing business needs and solutions, which is the real value of containerization.