Abstract: Compared with the traditional microservice architecture, cloud native and serverless technologies are more flexible and efficient, and can better meet the needs of users.
This article is shared from Huawei Cloud Community's "Phoenix Architecture" Learning and Thinking - Evolution History of Service Architecture in the Cloud Native Era , author: breakDawn.
As the concept of cloud native becomes more and more popular, how the service architecture should develop and evolve has become a topic of concern to many programmers. The author of the well-known book "In-depth Understanding of Java Virtual Machine" released a new work "Phoenix Architecture" in 21 years. From this book, we can see many of the latest technologies or concepts.
1. Evolution history of service architecture
1.1 The original distributed era
DCE (Distributed Computing Environment) distributed computing environment.
The design theme of DCE: "Developers don't need to care whether the service is remote or local, they can transparently call the service or access the resource"
It is a distributed technology system theory specified by OSF very early, and it answers many questions, such as:
- Where is the remote service? ——Corresponding service discovery
- How many to deploy? ——Corresponding load balancing
- What should I do if the request times out? ——Corresponding to fusing, isolation and degradation
- How are method parameters and results represented? ——Corresponding serialization method
- How is the information passed in? ——Corresponding transmission protocol selection
- Service permissions? ——Corresponding authentication and authorization scheme
- How to ensure that the state between different machines is finally consistent? ——corresponding to distributed data consistency
But in the end, it was found that the cost of solving these problems far exceeded the benefits of distribution. In the era when DCE was first proposed (in the 1980s), machine resources did not reach that level, so it was temporarily put on hold.
1.2 Single system
A monolithic system doesn't necessarily mean it's bad or bad.
Benefits of monolithic architecture
Under the premise of the same resources, the performance of a single system is higher than that of a distributed system. All data is in-process communication, and development, deployment, and testing are all processed based on the same object, which is more convenient. The code in a single system is generally layered and divided into modules, and it is also easy to develop agilely and iterate.
Disadvantages of monolithic architecture
However, if a part of the code in the monolithic system has a defect, it may directly consume the process space, or directly crash the entire process, and there is no way to individually upgrade or update a certain code module. Therefore, when the system scale is small, the monolithic system has unique advantages. As the scale of the system becomes larger and larger, each functional module is required to be autonomous and isolated to reduce the explosion range.
From "pursuing as little error as possible" to "pursuing error is inevitable", this is where the microservice architecture challenges and replaces the monolithic architecture.
1.3 SOA - Service Oriented Architecture
SOA (Service-Oriented-Architecture) is called a service-oriented architecture, which is similar to the high consistency of protocols and communication methods between services, and each service follows exactly the same message protocol and management mechanism.
The ultimate goal is to summarize a set of top-down software development methodology. Finally, when a new manufacturer wants to develop a system, stereotypes generally copy the SOA architecture and implementation.
A reference SOA architecture is an event-driven architecture. All services are connected to a unified message pipeline, and receive unified event messages and response mechanisms from the pipeline.
Reasons for SOA's desolation:
- Excessive complexity created by overly strict specification definitions;
- Overly sophisticated processes and theories require professionals who understand complex concepts to navigate.
1.4 Microservice Era
Nine core business and technical characteristics of microservices
- Build around business capabilities : divide fine-grained services and teams according to business;
- Decentralized governance : Each service and each team is responsible for the quality of the service, not affected by other services, and can evolve independently without unified regulation;
- Autonomy through services rather than libraries;
- Product-oriented thinking : All service developers pay attention to the all-round life cycle of the entire microservice. Everyone is not just to complete a certain function, but to provide a service that is continuously improved and enhanced;
- Data decentralization : different storage methods or storage locations are allowed, but the cost of distributed consistency must be considered;
- Strong terminal and weak pipeline : that is, to weaken the communication mechanism similar to SOAP (communication pipeline design is very heavy, all services are mandatory to rely on, and many unnecessary pipeline functions are added), if there is a need for calling, provide the endpoint of the service terminal to call instead of forcing the pipeline use;
- Fault-tolerant design : It is believed that each service can be faulty and will not directly affect the operation of all services;
- Evolutionary design : Not only can it be fault-tolerant, but it can also allow a service to be eliminated suddenly;
- Basic setting automation : through CI/CD and other automated construction, release, operation and maintenance, reducing manual maintenance costs.
Advantages of microservices over SOA
Microservices are not variants or derivatives of SOA. Each part of microservices can freely choose various options, such as RMI, Dubbo, and Rest for remote calls; ZK, Etcd, etc. for service discovery. Also because there are so many choices, it is a very heavy challenge for architects.
1.5 Post Microservice Era (Cloud Native Era)
Replace software solutions with hardware solutions
For issues such as registration, tracking governance, and balance, can it be implemented directly at the hardware level without application code? It didn't work a long time ago because the hardware infrastructure couldn't keep up with the flexibility of software applications. Until the emergence of docker and k8s . The era of microservices is inseparable from the early containerization technology represented by docker . The software-level microservice governance functions supported by the microservice framework springCloud can find hardware-level alternatives in k8s:
Through k8s and related virtualization technology, technical problems that have nothing to do with business can be stripped from the software level and solved directly at the hardware setting level!
second evolution
When it comes to the switch or change of the call link, it is still difficult to rely solely on the hardware level of the DNS to do the switch, which is not as flexible as the software solution. Therefore, the "service grid" sidecar proxy mode is introduced, which is similar to detaching from the application code and deploying a communication proxy server in the container. The fuse, change, and flow control of requests can be controlled through this proxy server. In this way, there is no need to consider any logic related to the above communication processes in the microservice application code, and all are realized through a third-party proxy server!
1.6 Serverless era
Definition of no service
- Backend as a service: databases, storage, logs and other business-independent backends are all stored on the cloud;
- Function as a service: The functions/interfaces for users to call are all running on the cloud, and the caller does not need to consider capacity planning and computing power issues.
Vision without servers
- Developers only need to focus purely on business;
- There is no need to consider technical components, the back-end components are ready-made and can be used directly without considering how to purchase and select models;
- Don't worry about operation and maintenance, the operation and maintenance capabilities are handed over to cloud computing vendors.
Disadvantages of no service
For information management systems, online games, or applications with a high response speed to the back-end interface, no-service is not the best choice, because no-service functions will definitely not always handle high-activity states, and there will be cold starts. It will affect its responsiveness.
summary and reflection
In the architecture or books introducing microservices many years ago, it basically started from monomer -> SOA -> microservices. But now, with the emergence of new concepts such as cloud native and serverless, the development of microservice architecture has become more and more diversified. For developers who need to frequently contact cloud business, these new concepts are even more important. When studying this chapter, you need to pay attention to the reasons and reasons for the evolution of these architectures, such as the advantages and disadvantages of SOA compared to monomers, and how post-microservices gradually lead traditional microservices in concept.
The content of the second half of the book "Phoenix Architecture" focuses more on the important content of cloud native such as containers and k8s.
Like container-based and k8s-based designs, cloud-native technology transfers the complex content of the original software capabilities to the hardware level for replacement. Developers can focus more on business implementation rather than service governance and other complicated content.
For example, Huawei Cloud CCE service is an important part of the cloud-native era for deploying cloud services. CCE service can build a CCE Turbo container cluster for cloud-native 2.0, and accelerate computing, network, and scheduling. Learning CCE service can help developers Learn more about Kubernetes and container technology to improve your microservice development and containerized application deployment capabilities.
And no service is generally implemented based on containers. Users basically do not perceive the underlying hardware resources, and only need to call them, which greatly reduces the learning and energy costs of creation and maintenance. The concept is out-of-the-box. Such as Huawei Cloud Data Lake Exploration DLI , Huawei Cloud Lake Warehouse Construction LakeFormation , etc. are all cloud services based on serverless implementation. Based on these serverless services and combined with Huawei MRS and other big data bases, cloud users can quickly run their own big data jobs or data. Unified management and other capabilities to build the relevant capabilities of digital intelligence integration.
All in all, compared with the traditional microservice architecture, cloud-native and serverless technologies are more flexible and efficient, and can better meet the needs of users.
Click to follow and learn about Huawei Cloud's fresh technologies for the first time~