Preface
The distributed service framework not only includes the core runtime class library, but also includes service division principles, service-oriented best practices, service governance, service monitoring, service development framework, etc. It is a complete set of solutions to assist applications Do service-oriented transformation, and guide users how to build a service-oriented system suitable for their business scenarios, so as to maximize the value of service-oriented.
Based on the distributed service framework, the business can finally devote all its energy to the logic development of the application layer, and the research and development efficiency and system reliability have been greatly improved. At present, almost all Java systems of Huawei Telecom Software’s main solutions are based on a distributed service framework, and the underlying basic framework is unified.
In recent years, with the development of DevOps and container technology headed by Docker, microservice architecture has gradually become popular. The popularity of microservice architecture has its inevitable historical reasons. It is agile development, infrastructure servitization, DevOps and rapid Internet industry. The integrated product of development. Amazon AWS, Netflix, etc. are all successful practitioners of microservices. It is believed that more and more large-scale applications in China will evolve to microservice architecture in the future.
Huawei Software's Java architecture has experienced the traditional MVC vertical architecture-RPC framework-distributed service framework, and is currently evolving in the direction of Docker+microservices. The evolution of the entire service-oriented architecture is also a microcosm of technological changes in the industry.
Therefore, distributed service frameworks and microservices are both important cornerstones and indispensable technologies for the road of architects. Friends should pay attention to the learning of this piece of content.
Just today, I prepared these two pieces of technical knowledge for everyone, I hope you can like to forward it and let more people benefit!
We will introduce these two parts of knowledge one by one from the table of contents, content and specific chapters, everyone should study carefully!
First of all, the first piece of content to introduce to you is the principle and practice of distributed service framework
1. Directory
2. Main content
Chapter 1, Application Architecture Evolution
With the development of business, the scale of applications continues to expand, and there are more and more Big Mac applications inside the system. Conventional vertical application architectures can no longer cope with various challenges brought by complex services. By abstracting business common capabilities into atomic services, complex applications are horizontally split and service-oriented, and service consumers and providers are decoupled. The extraction and reuse of public capabilities can effectively reduce the cost of repeated development and construction of public modules.
The core of the traditional vertical architecture transformation is to transform the application into a service, and the core technology architecture used in the service transformation is the distributed service framework.
This chapter analyzes the evolution history of application architecture, so that readers can have a clearer and comprehensive understanding of the historical evolution process of application architecture and the development direction of future architecture.
Chapter 2, Introduction to the Distributed Services Framework
In an ever-evolving large-scale application, new business requirements and functions continue to increase, and technology is constantly evolving. The functional subsystems built by different teams use a variety of technical architectures, and the development, deployment, and operation and maintenance modes between subsystems are also There is a big difference. If the enterprise does not have a unified service framework for technical integration, the efficiency of development and operation and maintenance will be greatly restricted.
The core of the traditional vertical architecture transformation is to service applications, and the core technology used in the service transformation is the distributed service framework.
Chapter 3, Communication Framework
After the local method call of the stand-alone version becomes the remote service call, a high-performance general communication framework becomes an essential part of the distributed service framework.
The communication framework involves Socket communication, multi-threaded programming, protocol stack and other related knowledge, which is difficult to master in the Java technology stack. This chapter will explain the principles and design points of the communication framework in detail, so that everyone can be familiar with the design points of the communication framework as soon as possible and use them flexibly in actual work.
Chapter 4, Serialization and Deserialization
Service providers and consumers communicate through the network. Objects need to be serialized and deserialized. There are many common serialization and deserialization methods. How to choose is the key and difficult point.
Chapter 5, Protocol Stack
Different services use different protocols for transmission in performance. For example, when connecting heterogeneous third-party services, public protocols such as HTTP/Restful are usually selected: for service calls between different internal modules, binary private protocols with higher performance are often selected.
Chapter 6, Service Routing
Distributed service framework. When it is online and running, it is cluster networking, which means that there is a multi-instance deployment of a service in the cluster. How consumers choose the appropriate service provider from the service list to call, which involves services routing. The distributed service framework must be able to meet the flexible routing needs of users.
Chapter 7, Cluster Fault Tolerance
After the cluster service call fails, the service framework needs to be able to automatically fault tolerance at the bottom layer. There are many fault tolerance strategies, which are suitable for different scenarios. This chapter will explain in detail the function and design of cluster fault tolerance.
Chapter 8, Service Invocation
In addition to the commonly used synchronous service calls, the distributed service framework also needs to support several other forms of service calls. This chapter will explain these call methods in detail.
Chapter 9, Service Registry
For service providers, it needs to publish services. Due to the complexity of the application system, the number and types of services continue to expand; for service consumers, it is most concerned about how to obtain the services it needs. For service providers and service consumers, they may also have both roles: they need to provide services and consume services.
How to effectively manage service subscription/release and avoid hard-coding address information is a problem that the distributed service framework needs to solve. Through unified management of services, the process and management of service publishing/use by internal applications can be effectively optimized. The service registry is a configuration management node specifically used to manage service subscription/publishing.
Chapter 10, Service Publication and Reference
Service providers need to support publishing local interfaces as remote services through configuration, annotation, API calls, etc.: For consumers, remote service providers can be referenced in a peer-to-peer manner to achieve service publishing and quotation.
Chapter 11, Service Grayscale Publishing
Gray release refers to a release method that can smoothly transition between black and white.
AB test is a gray release method: let some users continue to use A, and some users start to use B; if users have no objection to B, then gradually expand the scope and migrate all users to B. Gray release can ensure the stability of the overall system, and problems can be discovered and adjusted at the initial gray level to ensure its impact.
Chapter 12, Parameter Passing
When communicating between service consumers and providers, in addition to the request parameters defined by the interface, it is often necessary to carry some additional parameters, such as the IP address of the message provider, the tracking ID of the message call chain, etc.; these parameters cannot be passed through the business interface. To pass,
The underlying distributed service framework is required to support this parameter transfer method.
Chapter 13, Service Multiple Versions
After the service goes online, with the development of the business, it is necessary to change the function or fix the online BUG; after the service is upgraded, it is often necessary to adopt multi-version management for the service.
Service multi-version management is an important feature of distributed service framework, which involves service development, deployment, online upgrade and service governance.
Chapter 14, Flow Control
When resources become a bottleneck, the service framework needs to limit the flow of consumers and activate the flow control protection mechanism. There are many strategies for flow control, the more commonly used ones are: static flow control for access rate, dynamic flow control for resource occupation, connection control for the number of concurrent connections for consumers, and concurrency control for the number of concurrent accesses.
In practice, various flow control strategies need to be used comprehensively to achieve better results. This chapter explains the flow control design principles and practices of distributed service frameworks.
Chapter 15, Service Degradation
During a big promotion or business peak, in order to ensure the SLA of the core service, it is often necessary to stop some less important businesses, such as product reviews, forums, or fan points.
Another scenario is that some services are unavailable for some reason, but the process cannot directly fail. It needs to be implemented by the local Mock server to make the process clear. Taking book reading as an example, if the user's login balance authentication service does not work normally, the business needs to be cleared, the consumption bill is recorded, and the user is allowed to continue reading instead of returning failure.
In the above two scenarios, an important service governance function of the distributed service framework is used: service degradation. Service degradation mainly includes two modes: fault-tolerant degradation and shielded degradation. Below, we will explain the two service degradation strategies and designs.
Chapter 16, Service Priority Scheduling
When the current resources of the system are very limited, in order to ensure the normal operation of high-priority services and guarantee the service SLA, it is necessary to reduce the scheduling frequency of some non-core services, release some resource occupation, and ensure the smooth operation of the system as a whole.
There are many scheduling strategies for service priority. For a distributed service framework, it needs to be able to support the setting of priority strategies when the service is released, and when resources become a bottleneck, the service is scheduled to execute according to the priority strategy configured by the user.
Chapter 17, Service Governance
With the development of business, there are more and more services. How to coordinate the various services running online and guarantee the SLA of the service is a big challenge to the service architecture and operation and maintenance personnel.
With the continuous expansion of business scale, problems such as the waste of small service resources have gradually emerged. It is necessary to be able to perform capacity management based on the performance KPI data of service calls, reasonably allocate the resource occupation of each service, and improve the utilization rate of the machine.
When an online business fails, it is necessary to perform service degradation, flow control, and flow migration for the failed business to quickly restore the business.
With the continuous expansion of the development team, the launch of services has become more and more random, and even services with the same function and different service names will be launched at the same time. It is easy to go online and difficult to go offline. In order to standardize the online and offline of the service, the service pre-release process needs to be followed before the service is released. The architect or project manager will review the release of the service that needs to go online, and only those who pass the review can go online.
In order to meet offline management and control of services and ensure efficient online operation, a unified service governance framework is required to uniformly and effectively manage services to ensure efficient and healthy operation of services.
Chapter 18, Distributed Message Tracing
With the development of business distributed architecture, the system calls between systems are becoming more and more complex. Taking the purchase of goods from e-commerce as an example, the purchase operation of the front-end interface involves hundreds of service calls at the bottom, and the middleware involved includes:
◎Distributed service framework
◎Message queue.
◎Distributed cache
◎Distributed data access middleware
◎Distributed file storage system
◎Distributed log collection
◎Its.....
If the back-end distributed calls and dependencies cannot be effectively cleaned up, fault demarcation will be very difficult. Using the distributed message tracking system can effectively solve the operation and maintenance challenges faced by the system after servicing, and improve the operation and maintenance efficiency.
Chapter 19, Reliability Design
Compared with traditional local Java API calls, cross-process distributed service calls face a higher risk of failure.
1) Network faults: link flashing, reading and writing timeout, etc.
2) Serialization and deserialization failed.
3) Malformed stream.
4) Service call failure caused by server flow control and congestion protection.
5) Other abnormalities.....
For applications, the distributed service framework needs to be robust enough to intercept and shield failures at the bottom of the platform. The business only needs to configure fault tolerance strategies to achieve high reliability.
Chapter 20, Microservice Architecture
In the past ten years, SOA (Service-Oriented Architecture) architecture has been widely used. Now, with the rapid development and application of cloud computing, mobile Internet, Docker container and other technologies, the “Micro Service Architecture” The new architecture style has attracted more and more attention from everyone, and more and more enterprises and platform service providers are trying and using it to solve specific business problems in practice. The popularity of microservice architecture has become one of the future technology development trends. .
Chapter 21, Servicing Best Practices
Before servicing, business is usually local API calls, and the performance loss of local method calls is small. After servicing, the use of remote network communication between service providers and consumers increases additional performance loss, and the delay of business calls will increase. At the same time, the risk of distributed call failures due to network flashovers will also increase. . If the service framework does not have sufficient fault tolerance, the business failure rate will increase substantially.
In addition to performance and reliability issues, cross-node transaction consistency issues, the difficulty of fault delimitation caused by distributed calls, and the increase in the operation and maintenance costs of massive microservices are also problems that must be solved by the distributed service framework. In this chapter, we will analyze the challenges faced after servicing and give solutions and business best practices.
Secondly, I will introduce you to the second piece of content-microservice design
1. Directory
2. Main content
Chapter 1 Microservices
With the popularity of domain-driven design, continuous delivery, on-demand virtualization, infrastructure automation, small autonomous teams, and large cluster systems, microservices have also emerged. It was not invented, but a trend or pattern summarized from the real world. But without these concepts mentioned earlier, it is difficult for microservices to emerge. In the rest of this book, I will try to integrate these concepts to give a panoramic view of how to build, manage, and evolve microservices.
Many organizations find that fine-grained microservice architecture can help them deliver software faster and have more opportunities to try new technologies. Microservices give us great freedom in technical decisions, allowing us to respond more quickly to inevitable changes.
Chapter 2 Evolutionary Architect
As you can see so far, microservices provide us with many choices, so we also need to make many decisions. For example, how many different technologies should be used, whether different teams should use different programming specifications, should they merge multiple services or split one service into multiple. How should we make a decision? These architectures support changes at a faster pace in a frequently changing environment, so the role of the architect needs to be changed accordingly. The views on the responsibilities of architects in this chapter are my personal opinions, and I hope to launch the final attack against the definition in the tooth tower.
Chapter 3 How to Model Services
Now that you know what a microservice is, I hope you understand its main advantages. You may already be eager to implement it, right? But where do you start? In this chapter, we will discuss how to determine the boundaries between services in order to maximize the benefits of microservices and avoid its disadvantages. But first, we need to have a product as a vehicle for discussion.
Chapter 4 Integration
In my opinion, integration is one of the most important technologies related to microservices. If you do it well, your microservices can maintain autonomy, and you can modify and publish them independently: but if you do not do it well, it will bring disaster. I hope this chapter can help you avoid the problems you have encountered in SOA during your microservice journey.
Chapter 5 Decomposing Monolithic Systems
The previous chapters discussed what a good service is and why a small service can achieve better results. It also discussed the importance of the evolvability of the system. But in fact, we may already have a lot of code bases in our hands, and they all have not followed the above pattern without exception. How can we decompose a monolithic system step by step?
The formation of a monolithic system is not a day's work. Developers add new functions and new codes to the system every day. After a while, it became a terrifying and huge existence in the organization, and no one wanted to modify it. But don't worry, it is not hopeless. As long as we use the right tools, we can slash this monster.
Chapter 6 Department
The process of deploying a monolithic system is very simple. However, in many interdependent microservices, deployment is completely different. If the deployment method is inappropriate, the complexity it brings will make you painful. This chapter will explain some techniques and techniques to help us better deploy microservices in a fine-grained architecture.
I will start with continuous integration and continuous delivery. These concepts are not the same as the topics we will discuss below, but they are related. Understanding them can help us make better decisions when considering what to build, how to build, and how to deploy.
Chapter 7 Testing
Since I started programming, the world of automated testing is changing with each passing day, and new tools and technologies appear almost every month, constantly pushing the world forward. However, how to efficiently and effectively test the functions of distributed systems remains a challenge. This chapter will analyze the problems and challenges faced by the fine-grained system, and propose some solutions to help you release new features with more confidence.
The coverage of testing is very wide, and even if only automated testing is discussed, there are many considerations. After using the microservice architecture, the complexity of the test has increased. Faced with such challenges, it is very important for us to understand the different types of tests. It can help us achieve the balance between delivering software as soon as possible and maintaining high quality of software, because sometimes fish and bear's paws are not compatible.
Chapter 8 Monitoring
As I have shown before, breaking the system into smaller, fine-grained microservices brings many benefits. However, it also increases the monitoring complexity of the production system. In this chapter, I will take you to look at the challenges faced by fine-grained systems in system monitoring and positioning problems. At the same time, I will introduce some countermeasures to let you have both!
Imagine a scenario like this: On a quiet Friday afternoon, the team is looking forward to sneaking to the bar early and starting a weekend away from work. However, I suddenly received an email: The website is working abnormally! Twitter is full of news about problems with your company's website, and your boss is chattering on the side, and a quiet weekend is gone.
What is the first thing you need to know? Where is the problem?
In the world of monolithic applications, we must at least be very clear about where to start the investigation. Slow website? It's a monolithic application problem. Is there something wrong with the website? It is a monolithic application. CPU occupancy rate is 100%? It is still a problem of single block application. Burning smell? You know, a single point of failure can greatly simplify the investigation of the problem!
Now, let us return to the microservice-based system. The functions we provide to users are composed of multiple small services, some of which need to integrate more services to complete the functions. This method has many advantages (this is good, otherwise this book is a waste of time?), but in the surveillance world, we are facing a more complicated problem.
We now have multiple services to monitor, multiple logs to filter, and multiple places may have problems due to network delays. How to deal with it? We have to sort it out, otherwise it may lead to chaos and become a mess, and this is the last situation we want to face on Friday afternoon (or at any time!).
The answer here is simple: monitor small services, and then aggregate them to see the whole. We start with the simplest system, one node, to show how to do it.
Chapter 9 Security
We have heard too many stories about security breaches in large systems that exposed data to various dangerous individuals. The recent Edward Snowden leak has made us more aware of the value of user information held by the company and the value of data stored in the system built for customers. This chapter will briefly outline some of the issues that should be considered in terms of safety when designing a system. Although it is not possible to cover all aspects of security, some major options will be listed for you to provide a good starting point for further research.
We need to consider how to protect data during the transmission from one point to another, as well as how to protect it in other situations. We need to consider the security of the underlying operating system and network. There are too many points to consider, there are too many things that can be done! How safe is it? How do we know what is safe enough?
We also need to consider the human factor. Who is using our system and what will he do? And what does this have to do with how our server interacts? Let's start here.
Chapter 10 Conway's Law and System Design
So far, most of the content of this book has focused on the technical challenges faced when moving towards a fine-grained architecture. But in addition, we also need to consider organizational issues. In this chapter, we will learn about the dangers of ignoring the company's organizational structure.
Our industry is still young, and it seems to be constantly reinventing itself. However, some key laws have withstood the test of time. For example, Moore's Law, which states that the number of transistors that can be accommodated on an integrated circuit will double every two years. The law has proven surprisingly accurate (although some predict that this trend has slowed down). There is another law that I find almost universally applicable and more useful in my daily work, and that is Conway's law.
Chapter 11 Scaled Microservices
When you deal with the small examples in the book, everything seems simple, but the real world is much more complicated. What will happen when our microservice architecture becomes more complex from the simple one? When we have to deal with multiple independent services that fail, or manage hundreds of services, what should we do? When there are more microservices than people, is there any response mode? Let's find the answer together!
Chapter 12 Summary
In the previous chapters, we have discussed a lot of content, from the definition of microservices to how to divide its boundaries, from integration technology to security and monitoring. We even discussed what the role of the architect should look like under the microservice architecture. Although each microservice itself is small, its impact on the architecture is very wide and great, so there are still many things to learn. In this chapter, I will try to summarize some key points throughout the book.
to sum up
Because of the limitation of the content of the article, the editor will not do too much introduction here. Those who need the full version of the actual technical documentation of these two parts can forward the following editor, directly view the picture below, scan the code to add or private message the editor [Technology] Come get it! !
I have no time to participate in your past, but I will stay with you in your future!
Continue to share technical knowledge with you, I hope you will like it! !