Shulou(Shulou.com)06/01 Report--

This article mainly explains "what are the characteristics of cloud native". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the characteristics of cloud native"?

What is cloud native

Cloud Native (translated as "Cloud Origin" in China) was first put forward by Matt Stine. Like micro-services, Cloud Native is not a specific technology, but a collection of ideas, including DevOps, continuous delivery (Continuous Delivery), micro-services (MicroServices), agile infrastructure (Agile Infrastructure), Conway's law (Conways Law), and reorganizing the company according to business capabilities. Cloud Native includes both technology (microservices, agile infrastructure) and management (DevOps, continuous delivery, Conway's Law, reorganization, etc.). Therefore, Cloud Native can also be said to be a collection of a series of Cloud technologies and enterprise management methods.

Cloud Native has the following features:

Take the cloud as the infrastructure

Cloud servic

No servic

Scalable

High availability

Agile

Cloud first

Wait

Second, micro-service

Although microservices bring architectural advantages, they also introduce complexity. We have to use some components to solve the problems caused by the increased technical complexity:

Service registry: a service can have multiple instances, so how do we know which instances of a service there are when making a request to a service? In order to reduce the hassle of manual maintenance, we need a service registry. When each service instance starts, it registers its own IP address and other information with the registry. In this way, when a service invokes the interface of another service, it can query the instance of other service through the registry and initiate a request to the instance. The Waltz main store acts as a registration center.

Load balancing: since a service can have multiple instances, it is necessary to introduce a load balancing mechanism to play the role of multi-instance clusters, whether it is requests from external clients or requests between services within the micro-service system. Some books also call these two kinds of load balancing as server-side load balancing and client-side load balancing, and their representative implementations are Nginx and Ribbon respectively.

API Gateway: after an external request comes, we need to know which service the request is sent to, that is, we need a request routing function, such as a request for / cm/*, a request for customer management, a request for om/*, and an order management service. In addition, not all requests can be processed by our system, we need to determine whether the request carries some necessary authentication information, and authenticate it, that is, the function of request filtering. And API Gateway plays these two functions, it is like the facade of the entire micro-service system, all requests must be processed by it before they are forwarded to the corresponding service.

There are many derivative components of the micro-service system, such as the distributed configuration center for configuration management of each service, the message bus for message communication between various services, and the message-driven mechanism (Message Queue in the figure above).

Third, the vision of service

"Micro Services" is a popular buzzword in the industry in the last two or three years. Most of the migration to micro services architecture emphasizes these benefits:

Loose coupling

Independent release

Fast iteration

Fault isolation

Increase reuse

After the split of the service, the single application, which is so complex that it is difficult to move, is divided into multiple services that can be deployed independently, and the complexity of a single service is far less than that of the whole, so that developers of different services can develop in parallel, thus improving development efficiency; because of the fine granularity of services, assign can assign responsibility to a specific person and expand the service directionally as the business grows. At the same time, because of the isolation of the service, it can isolate the fault and improve the overall stability.

4. Split based on SSO

RPC (remote procedure call) is the foundation of the service-oriented architecture, but slowly we find that RPC is not the only choice for split. The horizontal split based on RPC will introduce the middle level and increase the link of joint adjustment, so for the new business of rapid development, the additional cost of co-adjustment can not be ignored.

The inspiration we get here is that the split of services is not impossible to RPC. Instead, we want to see less RPC and more cohesion. Fewer RPC interfaces mean smaller service boundaries, more stable interfaces, and less break change. Cohesion means allowing the independent evolution of functional requirements, minimizing the impact on other businesses, and also means that within the cohesive business module, caching can be fully utilized to optimize performance.

How to demarcate the service boundary

In an ideal world, the service boundary matches the business boundary. However, engineers have to bear the pressure of business requirements first, so they can only take the time to restructure and split, and the business boundaries are not always as clear as new projects.

This means that priorities need to be considered and business boundaries need to be carefully thought about before splitting. Prioritize and consider the benefits and risks of the split. To demarcate the boundaries of the business, we need to think more about how to communicate and cooperate in the future after the split, and then consider the technical factors. At present, we have the following main considerations:

Whether there is an independent team to maintain, or whether it has the potential to develop into an independent business

Around the domain rather than feature, there is a clear maintenance team to avoid being too fine-grained

Can the existing cooperation process be improved after the split?

Can it help to distinguish between core and non-core businesses and improve stability

Take feed as an example. First of all, it has independent team maintenance. Through splitting, the feed team is allowed to reconstruct redundant RPC calls between lower-level services and upper-level presentation, and the invocation mode is better than uniform. Under the premise of accepting the final consistency of data at the product level, it can improve performance through TTL cache, and even make more detailed optimization according to its own business scenarios (after optimization, the performance of some of our interfaces P95 has doubled). What is more important is the impact on the mode of collaboration. The vertical business of production information such as future columns and Q & A can only provide a RPC interface to dock the feed stream, without having to be integrated into the master station, so that the participants in the "access feed" process are simplified to both the feed group and the vertical business from the feed group, the vertical business and the master station. In addition, feed essentially redundant a copy of vertical business data through TTL cache. With the use of circuit breakers, the jitter and even collapse of dependent vertical services can be gracefully degraded and maintained normal display on the feed side. Isolating feed from changes in the master station also helps to improve the stability of feed as a core business.

VI. Service layering: business services and public services

In addition to the vertical business, there are also public services that most businesses will reuse, such as users, topics, web crawling, multimedia, push and so on. There are differences in concerns between business services and public services:

We want business services to iterate quickly, respond faster and better to changing business needs, and be more oriented to front-end engineers.

We want public services to be stable and reliable with fewer changes, but SLA is better and more reused for business.

There will be a natural hierarchy: fast business at the upper level and stability of public services at the lower level.

Thank you for your reading, the above is the content of "what are the characteristics of cloud native", after the study of this article, I believe you have a deeper understanding of the characteristics of cloud native, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.