This article is published by NetEase Cloud .
The concept of cloud native (Cloud Native) was first proposed by Matt Stine from Pivotal in 2013 and has been used since then. This concept is a collection of ideas summed up by Matt Stine based on his years of architecture and consulting experience, and has been continuously improved by the community. There are many contents, including DevOps, Continuous Delivery, MicroServices, and agile foundations. Facilities (Agile Infrastructure) and 12 elements (TheTwelve-Factor App) and other major themes include not only the reorganization and construction of the company's culture and organizational structure based on business capabilities, but also methodology and principles, as well as specific operational tools. With cloud-native technologies and management methods, businesses can be better born in the "cloud" or migrated to the cloud platform, so as to enjoy the efficient and continuous service capabilities of the "cloud".
As the name suggests, cloud native is an application designed for the "cloud", so the technology partly relies on the 3-layer concept of traditional cloud computing (Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS)) For example, agile and immutable infrastructure delivery is similar to IaaS, which is used to provide basic resources such as computing network storage. These resources are programmable and immutable, and can provide services directly through APIs; some applications can already be provided through PaaS services. Combining different business capabilities does not necessarily need to be built from scratch; some software can be directly run to provide services to cloud users only with "cloud" resources, that is, SaaS capabilities, and users directly face native applications.
The architecture design of the application is based on cloud services, which has higher requirements for technical personnel. In addition to the consideration of business scenarios, more non-functional requirements such as fault isolation, fault tolerance, and automatic recovery will be considered. More elegant designs can also be achieved with the help of the capabilities provided by cloud services, such as the demand for elastic resources, high availability across computer rooms, and data reliability of 11 nines (99.999999999%), which are basically the capabilities provided by cloud computing services themselves. , the developer can directly select the corresponding service, and generally does not need to think too much about the problem of its own computer room. If the architecture design itself can support multi-cloud design, the usability will be further improved. For example, Netflix can handle the situation that a certain computer room in AWS fails to work normally, and can also provide services for users. This is the magic brought by "cloud", of course. , the cloud will also bring more isolation and other issues. As shown in Figure 1-4, the current industry-recognized cloud native mainly includes the following aspects.
Figure 1-4 Cloud native content
agile infrastructure
Just as product requirements can be realized through business code, and rapid business changes can be guaranteed through version management, cloud computing-based development models should also consider how to ensure that the provision of basic resources can automatically realize requirements according to code, and record changes to ensure the environment. consistency. Using principles, practices, and tools from software engineering to provide lifecycle management of underlying resources, meaning workers can build stronger or more stable infrastructure more frequently, and developers can pull a set of infrastructure at any time To serve the needs of development, testing, joint debugging and grayscale online. Of course, at the same time, business development is required to have a good architecture design, and there is no need to rely on local data for persistence. All resources can be pulled up and released at any time, and at the same time, elastic, on-demand computing and storage capabilities are provided in the form of APIs. .
Technicians deploying servers, managing server templates, updating servers, and defining infrastructure patterns are all done through code and are automated. Server resources cannot be managed by manual installation or cloning. Operators and developers work together The application code for resource configuration is the center, and it is no longer a machine. The infrastructure is changed and tested through code, and stable infrastructure services are maintained in an automated process that executes tests after each change.
In addition, the scope of infrastructure will be more extensive, including not only machines, but also different cabinets or switches, multiple computer rooms in the same city, multiple computer rooms in different places, etc. These contents will also be discussed in part one by one in subsequent chapters.
continuous delivery
In order to meet the frequent changes of business requirements, through rapid iteration, the ability of products to be released at any time is a series of development practice methods. It is divided into continuous integration, continuous deployment, continuous release and other stages, which are used to ensure that from the proposal of requirements to design development and testing, to the rapid and safe deployment of code to the production environment. Continuous integration means that every time a developer submits a change, it is immediately built and automated to test to ensure that business applications and services meet expectations, so as to determine whether the new code and the original code can be correctly integrated. Continuous delivery is the ability to release software. After continuous integration is completed, it can be provided to systems such as pre-release to meet the conditions of the production environment. Continuous deployment refers to the use of a fully automated process to automatically submit each change to the test environment. , and then safely deploy the application into the product environment, open up all links of development, testing, and production, and automatically deliver products continuously and incrementally, which is also the ultimate goal of a large number of products. Of course, in the actual operation process, some products Will increase the grayscale publishing and other environments. In short, it represents more of a software delivery capability. Please refer to Figure 1-5 for an example of the process.
Figure 1-5 Continuous Delivery Process
DevOps
If DevOps is literally understood as Dev (developers) + Ops (operations and maintenance personnel), in fact, it is a collective name for a set of processes, methods and systems. Its concept has been developed since it was first proposed in 2009, and the content is also very rich. , both theoretical and practical, including different aspects of organizational culture, automation, lean, feedback and sharing. First of all, the organizational structure, corporate culture and concepts need to be designed from the top down to promote communication, collaboration and integration between the development department, operation and maintenance department and quality assurance department. In simple terms, the organizational form is similar to system layering design. Secondly, automation means that all operations do not require manual participation, and all rely on the system to complete automatically. For example, the above-mentioned continuous delivery process must be automated to complete rapid iterations. Again, the emergence of DevOps is due to the growing recognition in the software industry that in order to deliver software products and services on time, the development and operations departments must work closely together. In summary, as shown in Figure 1-6, DevOps emphasizes how efficient organizational teams can collaborate and communicate through automated tools to complete software life cycle management, thereby delivering more stable software faster and more frequently.
Figure 1-6 DevOps emphasizes organizational communication and collaboration
Microservices
With the business development of enterprises, the traditional business architecture faces many problems. First, the monolithic architecture cannot meet its change requirements when there are more and more demands, and it will become more and more difficult for developers to change a large number of codes, and at the same time, it is impossible to evaluate risks well, so the iteration speed is slow; second, The system often paralyzes the entire business due to the bottleneck of a business, the architecture cannot be expanded, the barrel effect is serious, and the availability requirements of the business cannot be met; finally, the overall organizational efficiency is low, and resources cannot be well utilized, resulting in a lot of waste. Therefore, organizations urgently need to change. With the maturity of a large number of open source technologies and the development of cloud computing, service-oriented transformation has emerged as the times require, and different architectural design styles have emerged. The most representative is Netflix, which is the first foreign cloud-based service-oriented architecture transformation. After nearly 10 years of hard work, after being forced to suspend business for 3 days due to the paralysis of the entire site, the company has achieved the transition from single architecture to microservice globalization, meeting the thousand-fold increase in business (such as Figure 1-7), and resulted in a set of best practices.
Figure 1-7 Netflix's microservices support a thousand-fold increase in business
With the advantages and rapid development of the microservice architecture, in 2013, MartinFlower made a systematic theoretical elaboration on the concept of microservices, and summarized the relevant technical characteristics. First of all, microservices are an architectural style and a kind of service; secondly, the particles of microservices are relatively small, and a large-scale complex software application consists of multiple microservices. For example, Netflix currently consists of more than 500 microservices; finally, It adopts the philosophy of UNIX design, each service only does one thing, it is a loosely coupled stateless service (independent extension, upgrade and replacement) that can be independently developed and deployed. The microservice architecture is shown in Figure 1-8.
Figure 1-8 Example of microservice architecture
From the definition and analysis of microservices, it can be seen that a microservice is basically an application service that can be released independently, so it can be upgraded, grayscale or reused as an independent component, and has little impact on the entire large application. A dedicated organization can complete it independently. The relying party can fully develop as long as the input and output ports are determined, and even the organizational structure of the entire team will be more streamlined, so the communication cost is low and the efficiency is high. According to the needs of the business, different services can have different technology selections based on business characteristics. Whether it is computing-intensive or I/O-intensive applications can rely on different language programming models, and each team can operate independently according to its own characteristics. When the service is under high pressure, there can also be more fault-tolerant or current-limiting services.
The microservice architecture does have many attractions, but its introduction also has a cost. It is not a silver bullet. Using it will introduce more technical challenges, such as performance delays, distributed transactions, integration testing, fault diagnosis, etc. , enterprises need to reasonably introduce them according to different stages of the business, and cannot "microservices" completely for the sake of microservices. Chapter 5 of this book will also provide trade-offs corresponding to different solutions on how to solve these problems.
12 elements
The full English name of "12 Factors" is The Twelve-Factor App. It was originally organized and started by Heroku engineers. It is the wisdom of collective contributions, as shown in Figure 1-9. According to the cloud-based software development model, the 12 elements closely describe the prototype of the software application and explain the reasons for using the cloud-native application architecture. For example, in the design process of an elegant Internet application, some basic principles that need to be followed are similar to those of cloud native. By strengthening detailed configuration and specification, similar to Rails's principle of "convention over configuration", especially in large-scale software production practice, these conventions are very important, from stateless sharing to the process of horizontal expansion, From loosely coupled architectures to deployment environments. Based on the contextual association of 12 elements, software production becomes a single deployment unit; multiple jointly deployed units form an application, and the relationship between multiple applications can form a complex distributed system application.
Figure 1-9 12 elements
These principles in Figures 1-9 are briefly described below. I believe that many developers have applied some of these principles well in actual development work, but they are not aware of the concept itself. For developers who are relatively unfamiliar with these principles, if you want to know more about the operation process, please refer to the article "12-Factor Application and Practice in the Cloud Native Era".
benchmark code
Every deployed application is tracked in a version control repository. In multiple deployment environments, there will be multiple deployment instances. A single application has only one code base. Multiple deployments are equivalent to running multiple instances of the application, such as one instance in the development environment, one in the test environment, and one in the production environment. instance.
In fact, in the cloud computing architecture, all infrastructure is code configuration, that is, Infrastructure as Code (IaC). The entire application can be programmed through configuration files without manual intervention, and basic services can also be achieved. tracked.
rely
The application does not implicitly depend on the system-level class library, declares all dependencies through the dependency manifest, and uses the dependency isolation tool to ensure that the program does not call the system, but the dependencies are not declared in the manifest, and are uniformly applied to the production and development environments . For example, through appropriate tools (eg Maven, Bundler, NPM), applications can clearly expose and isolate dependencies on the deployment environment, rather than vaguely depend on the deployment environment.
In container applications, all application dependencies and installations are declared through DockerFile, and dependencies, including versions, can be clearly displayed graphically through configuration, and there is no black box.
configure
Environment variables are a clear, easy-to-understand, and standardized method of configuration that stores application configuration in environment variables, ensuring that configuration is excluded from code, or otherwise may be differentiated between deployment environments (e.g. R&D, display, production) Any code that can be injected via OS-level environment variables.
Instances run in different environments according to different environment configurations. In addition, to implement configuration as code, in cloud environments, whether it is a unified configuration center or a distributed configuration center, there are good practices, such as the use of Docker's environment variables. .
backend service
Instead of treating local or third-party services differently, treat the dependent backend as a service, such as a database or message broker, as an additional resource that is consumed equally in various environments. For example, in the basic services of cloud architecture, computing, network, and storage resources can be treated as a kind of service, and there is no need to distinguish whether they are remote or local.
build, publish, run
The application strictly distinguishes the three phases of build, release, and operation. The three stages are strictly separated. One stage corresponds to one thing, and each stage has a very clear implementation function. The build process of cloud-native applications can move the release configuration to the development stage, including the actual code build and the production environment configuration required to run the application. In cloud-native applications, the container-based Build-Ship-Run fits perfectly with these three stages, and is also Docker's best practice for this principle.
process
Processes must be stateless and shareless, i.e. the cloud application runs as one or more stateless and shareless programs. Any necessary state is serviced into backend services (cache, object store, etc.).
All applications are designed to fail anytime and anywhere, and are designed for failure, so processes may be pulled up or disappeared at any time, especially in the stage of elastic expansion.
port binding
A network-oriented service can be created without relying on any network server. Each application has complete functions and provides all services to the outside world through port binding. For example, web applications provide services through port binding (Port binding), and monitor Requests (including HTTP) sent to this port.
In container applications, the applications are uniformly served by exposing ports, and try to avoid communication through local files or processes. Each service is served through service discovery.
Concurrency
Processes can be regarded as first-class citizens, and concurrency can be achieved by horizontally scaling applications, extending through the process model, and having the characteristics of no sharing and horizontal partitioning.
In Internet services, the explosiveness of business may occur at any time, so it is unlikely to provide expansion services at any time through hardware expansion, and it needs to rely on horizontal expansion capabilities for expansion.
easy to handle
The architectural design of all applications needs to support the characteristics of being destroyed at any time, and be consistent with the independence of the state, allowing the system to quickly and elastically expand, change the deployment, and recover from failures.
In a cloud environment, applications may fail at any time due to fast, flexible and elastic scaling of applications due to business peaks and lows, as well as uncontrollable hardware factors. Therefore, applications should be as stateless as possible in architectural design. It can be pulled up and destroyed anytime and anywhere, while ensuring the minimum start-up time of the process and the disposability of the architecture, and can also provide a more agile release and expansion process.
Environmental Equivalence
On-premises and online differences must be narrowed, the environment must be consistent, and the R&D, test, and production environments must be as similar as possible to provide continuous delivery and deployment services for applications.
In containerized applications, the environment built by files can be versioned, thus ensuring the differences between different environments, and at the same time, it can greatly reduce the cost communication problems such as troubleshooting caused by different environments.
log
Each running process will directly output (stdout) and error output (stderr) event streams, and can also use logs as event streams as data sources, and through centralized services, the execution environment collects, aggregates, indexes, and analyzes these events.
Logs are part of the system running status. No matter in system diagnosis, business tracking or the necessary conditions for subsequent big data services, Docker provides standard log services, and users can develop custom plug-ins to process logs according to their needs.
management process
Managing or maintaining the running state of an application is the basic part of software maintenance, such as database migration, health check, security inspection, etc. It runs as a one-time program in the same environment as the long-running program of the application.
In the application architecture mode, such as Pod resources or dockerexec in Kubernetes, it can be released along with other applications or manage its status through related programs when abnormal diagnosis occurs.
The content of cloud native is very extensive, and there is no systematic description and complete definition at present. The basic components and related characteristics of cloud native applications are introduced above, and readers may still have some confusion about the logic of cloud native applications. To illustrate more clearly, we summarize their dependencies as shown in Figure 1-10.
Figure 1-10 Dependencies of cloud native content
First of all, in order to seize business opportunities, the business needs to iterate quickly and keep trial and error. Therefore, enterprises need to rely on the ability to have continuous delivery, which includes not only technical requirements but also product requirements. How to have continuous delivery capabilities, large and comprehensive The architecture is obviously inappropriate because of its inefficiency. Therefore, a microservice architecture has been evolved to meet the needs. By dividing the system into independent individuals, the design dependencies of each individual service need to be standardized and completed through the principle of 12 elements. Similarly, if the system is divided into dozens or even hundreds of service components, DevOps is needed to well meet processes such as business collaboration and release. Finally, the effective implementation of DevOps needs to rely on a certain soil, that is, agile infrastructure services. In reality, only the cloud computing model can meet the overall requirements. Through the above analysis, we summarize the characteristics of three different levels for cloud-native applications.
- High availability design (Design for Availability) , according to the application business requirements, high availability is divided into different levels, such as high availability in different regions, different computer rooms (cross-city or same city), different cabinets, different servers and different processes, cloud native applications should be Design different levels of architectural support according to the availability requirements of the business.
- Scalable design (Design for Scale) , the design of all applications is stateless, which makes the business inherently scalable. During peak and low peak periods of business traffic, it can automatically and elastically expand depending on the characteristics of the cloud to meet business needs.
- Design for Failure , that is, calls that include dependencies between systems may fail at any time, hardware infrastructure services may be down at any time, and the system capabilities of back-end stateful services may have bottlenecks. In short, exceptions occur. It can fail quickly and then recover quickly to ensure that the business is always online, and the business cannot be left in a deadlock.
From the above basic description and the composition or characteristics of cloud-native applications, compared with container technology (described in detail in Chapter 2), we can see that the characteristics of containers are inherently designed according to these principles. With the continuous evolution of Internet business architecture, from single application to distributed application, and even microservice architecture application, the 12 elements provide a unified methodology and standardization for building Internet-based applications, and have strong vitality. The principles are the gems of application development. Of course, in practice, every principle is not static. With the emergence of new ideas and technologies, the original factors will be extended and developed, and new principles and applications will appear. This theory is also applicable to any language. Applications developed with back-end services (databases, message queues, caches, etc.) are therefore also used as one of the basic guiding principles for cloud-native architecture applications.
This article is excerpted from " Practice of Cloud Native Application Architecture ", written by NetEase Cloud Basic Service Architecture Team, and explains the evolution from monomer to distributed service architecture. For more exciting content, please look forward to sharing in the next issue.
Text/NetEase Cloud Basic Service Architecture The team
Learn about NetEase Cloud:
NetEase Cloud Official Website: https://www.163yun.com/
New User Gift Package: https://www.163yun.com/gift
NetEase Cloud Community: https://sq.163yun.com/