Application Statistics Platform Architecture design: Intelligent Predictive App statistics

A push research and development expert Zhu Mingzhi

With Docker as the typical representative of the concept of container gradually emerging, a large number of companies and enterprises using distributed architecture, began to consider the original system of containerized upgrade. Why do traditional distributed architectures need to be containerized? What are the opportunities and challenges of container-facing? How does a push, as a smart Big data service provider, get containerized to the ground? How will the future develop? This article takes the practice which pushes on the container to be an example, with everybody to discuss and the prospect.

Features of the traditional distributed architecture

Traditional distributed architecture system, generally has the following two features:

First, according to the difference of business and resource consumption, the developer will divide the traditional distributed architecture system into modules. For example: According to the business distinction, a push will be divided into different system modules, and the phone SDK to establish a long-connected client cm module, as well as the IM module responsible for message routing, depending on the resource consumption, a push will be multiple read and write Redis and read MySQL multiple user modules into different roles.

Second, in the traditional distributed architecture system, the same role module will have multiple instances. This system, on the one hand, achieves high availability, while a server outage does not affect the overall business. On the other hand, it is convenient to increase throughput by expansion when the pressure becomes larger. For example, the system only needs to expand the instance of the role when there are more requests for the Redis read-write role.

Many years of practice have proved that the traditional distributed architecture system has obvious advantages of easy expansion, high reliability, higher efficiency and low-level, but also has certain limitation.

Due to the complexity of the character module, the traditional distributed architecture system is difficult to be completed by manual in the aspects of configuration management, service resource management and deployment environment. For example, for each of the different versions of the business module, the developer will need to make configuration changes before going online, and when the specific function needs to be modified, there will inevitably be many modules involved, creating a large number of duplicate work orders for the developer.

So, how can we solve these problems and create an ideal online environment and a good visual management system? At this point, we think of the container.

The opportunity and challenge of containerized

Containerized can effectively solve a series of problems of traditional distributed architecture system. Among them, Docker and kubernetes are the most common open source container engines and orchestration tools.

Docker

Docker is undoubtedly the most popular open source container engine available today. The principle of Docker is to put a number of applications and all the environment needed to run, through the container is the container packaging, so that can be placed to avoid a lot of irregularities caused by the hidden dangers. For example, Docker can effectively avoid the Java environment version differences, different applications, the use of resources competing with each other.

A layered strategy that uses Docker mirroring when using Docker. First, the various product line modules that are pushed, use the respective base image. Secondly, a service program that pushes each product line is placed above its own underlying mirror layer, which ensures that the operating environment of each container is not in conflict.

Kubernetes

Kubernetes is an open source platform for automated deployment, expansion, and operation of container clusters. Kubernetes's philosophy is to guide the placement of each container, reduce the difficulty of server resources, make operation and maintenance management become more convenient.

A choice of kubernetes as a tool for Docker container orchestration, there are two main considerations.

One, a push encountered the problem:

Version Update Iteration Fast

Many application processes, server resource consumption is large

Server environment is not uniform

Need to advance DevOps

Second, the advantages of kubernetes:

Operation and Maintenance automation

Application Container Build Once

Computer hardware resources can make full use of

Orchestration Management has outstanding advantages

In the application of Docker and Kubernetes, a lot of benefits, but also for a push the original distributed system structure to bring some pressure. For example, the original frame and module of a push system need to be adapted, the original system is very large, it needs to be migrated gradually, and the original ecological service must have some trade-offs. Therefore, we explore this area through a container-based practice of landing.

The practice of pushing container

In a push of a project, we carried out a full container of practice.

Before the concrete implementation, we first determine the overall structure diagram, the frame composition contains kubernetes basic structure. For example: On the Master node deployment, Apiserver is the control entrance of the whole system, scheduler is responsible for task scheduling, command, controller Manager as the Management control center within the cluster; On node node deployment, Kubelet as the agent to monitor the task of executing the node, reporting the State of the node, and the proxy is responsible for the entire network rules connection and forwarding.

When the concrete practice, how the state component can be deployed successfully, how to realize interoperability between intranet and Internet, how to configure the center, and monitor how to do it, are the problems that developers are prone to encounter.

Deployment of stateful components

In Kubernetes, there are many stateless components, which are based on a stateless, one-off concept for pod management. Like the replication Controller, it simply guarantees the number of pods available for service. If a pod is considered unhealthy, then kubernetes will treat the pod in a very simple and rude manner: Delete, rebuild, and auto-expand the capacity. This approach is typically used for business logic processing and in-memory computing programs.

However, Kubernetes can provide the pod with a unique flag by Statefulset, guaranteeing the successful deployment and orderly expansion of stateful components such as zookeeper, MySQL, and Redis.

However, in the system, if the pod to satisfy the service is placed, the data must be landed to the same directory, and when the stateful component is placed in the container, the mount will definitely need to go through the network. However, using a network volume for mounting without local mounts is reliable, and the performance loss of the network is dozens of times times higher than the local one. At the same time, the maintenance of this component is not frequent and does not bring much convenience to operations. Therefore, after a comprehensive consideration, a push does not place such stateful components in the container.

interoperability of internal and external networks

The interoperability of internal and external networks is a typical problem that is easy to encounter in containerized process. A push uses calico to allocate virtual addresses, so networks within the same cluster can be interoperable. A real physical address can be used directly when a service inside a cluster accesses the outside. When the service outside the cluster is inside, it is necessary to map the virtual IP to the real IP by Iproute, in order to realize the internal service access.

Configuration Center

About the configuration center, you can first set up a number of demand points, marked out the focus after one by one to solve. A push. The key points of attention in this containerized practice include Configuration Center clustering, web interface management and Rights management, multi-environment configuration, simple development integration, local backup, etc.

After a series of research on a range of open source configuration centers, the qconf, Diamond, Xdiamond, disconf, Apollo, mconf, and xxl-conf features were compared, and a more complete Apollo was selected.

(Note: The survey is time-sensitive, the latest version of some of the configuration centers in the diagram, which may now support features not yet supported)

Monitoring Collection

Applications running in the kubernetes are prone to problems such as network isolation, the survival cycle being managed by the cluster, and the running node not being fixed. We have made some adjustments to our own monitoring system, such as deploying the master service outside the Kubernetes cluster, deploying the agent within each pod in the cluster, enabling data collection and monitoring and reporting on the main service.

Subsequent prospects for containerized

Finally, we hope that while absorbing this experience, we will plan and forecast the future of containerized practice. For example, we can consider continuing in-depth exploration from business monitoring and scaling, automated testing, stateful services, and more.

The combination of business monitoring and expansion capacity can identify the suspended animation and determine the business pressure. Automated testing, supplemented by automated tests for each business and module, can significantly save the cost of regression testing and better achieve the goal of fast iterative continuous delivery, a very important step in the devops process. Stateful services, follow-up with the development of kubernetes-related technologies, can help us find more appropriate container way, so as to complete the container, even the cloud service.

Conclusion:

At present, container-based, containerized in the control of costs, guarantee service stability, improve work efficiency has a great advantage, but the traditional distributed architecture is often due to its basic components and structure of the stereotypes, increased the difficulty of container transformation, resulting in the ship disaster turn. This article hopes that through the author's sharing, it can help the developers to better understand their ideas in the containerized process.

It is important to note that containerized practices are not containerized, but rather are based on a full understanding of existing business needs and solutions, providing more efficient and stable system services through the container, which is the real value of container.

Application Statistics Platform Architecture design: Intelligent Predictive App statistics