Preface
There are three challenges to building a good open platform. The first is from stability challenges, with billions of requests per day, some from merchants, some from external developers, and some from external partner platforms, API requests. In addition to simple Key-Value reading and writing, there are also multi-dimensional data write requests and complex queries. How to ensure that some API services fail to affect the entire gateway system? How to ensure the high availability of core services and core requests at the moment of traffic peaks?
The second comes from the developer’s experience challenge. Developers here include developers who provide APIs and developers who use API. People tend to ignore the developer’s experience, but they are real customers of the open platform and determine the development of the open platform. And the future. How can developers who provide APIs manage and publish APIs more efficiently? How can developers who use APIs use APIs to develop their own applications more conveniently and efficiently? How to debug if problems occur? How to release management applications automatically?
The third challenge comes from security, which can be said to be the biggest challenge. E-commerce data is multi-dimensional, including product management, order production, after-sales customer service processing, financial settlement and various marketing management, etc. Basically every scene involves data processing and authorization. How can we ensure that users’ private information and platform business data are not leaked or abused while being open? There is also a contradiction in that the more open the data, the more prosperous the platform. What kind of technical security and protection are needed here? Mechanism? These issues are directly related to whether the open platform can continue to be done!
The solutions to the above technical challenges can only be iterated through continuous polishing in work practice. In this article, the author considers and summarizes these technical practices, and tells everyone from the simpler to the deeper, I believe it will bring you more Think and gain.
table of Contents
main content
The content of this article is divided into 10 chapters. It will take you in-depth interpretation of IO multiplexing technology, interpretation of NIO model in Tomcat, interpretation of where the time of an RPC call goes, and details of various functional scenarios of MQ. Real knowledge from practice.
Chapter 1 The Way of the Gateway describes the past and present of the gateway and the capabilities that a mature gateway should possess;
We need a gateway. After implementing microservices, we need a unified entrance and exit to "command" the interfaces of many microservices. This is especially true for open gateways, which need to empower the capabilities of the enterprise organization in the form of APIs. In this way, the gateway has two outstanding features, one is the large amount of visits, and the other is the dependence on the system. Then the stability and in-depth governance of the gateway system are particularly important. Readers can combine the knowledge of the chapter on fault tolerance to deal with this Two characteristics bring risks to the gateway system. This chapter starts with the understanding of API gateways, has been introduced to the traditional gateway system has several "dead" methods, and then introduced the fully asynchronous gateway. This chapter focuses on the core technologies of building a gateway, such as generalization, pipeline, asynchrony, and caching. I hope readers can use it as a reference when building a gateway system.
Chapter ⒉ The Open Road is mainly introduced around the API based on the gateway;
When the size of an enterprise reaches a certain level, it will consider the business direction of opening to the outside world. This amount includes two aspects, one is the amount of visits, and the other is the amount of data. If you have exclusive use, then business development will be restricted to a certain extent. If you open up to the outside world, opening this amount of business and data to third parties in the form of APIs will bring greater business development. The three-party developers jointly build an open business ecosystem, form an API economy, bring more benefits, and achieve the goal of win-win and even multi-win. To build an open platform, it is necessary to provide a sandbox environment based on an open gateway. At the same time, open and secure construction must be done. Openness and security have always been a pair of contradictions. This requires companies to carefully balance them.
Chapter 3 Distributed Road focuses on knowledge in common transaction, lock, and current limiting scenarios; the architecture of distributed systems has a long history, and the system architecture of Internet companies must conform to the design ideas of distributed. This chapter focuses on the differences between clusters and distributed systems, transactions in distributed systems, current limiting, locks, and measures such as QPS and TPS for a system. It also introduces how to make good use of these indicators.
Chapter 4 The Tao of MQ has been introduced from the basics to the common functional scenarios of MQ; message middleware is one of the essential basic components of Internet enterprises, which can bring time decoupling and space decoupling between application systems. This chapter starts with the understanding of JMS, gradually introduces various concepts and principles of MQ, and also describes in detail the use of various functional scenarios of MQ. A separate section introduces the role of MQ in data heterogeneity, and finally we return to the concept and principle level, thinking about why we need message filtering, message retry points, why messages are out of order, etc. We usually use it easily Some knowledge ignored.
Chapter 5 The Way of Message Push introduces the practice of message push in the production system by HTTP and TCP respectively;
News push is a very economical channel or way to reach users. Whether APP application or PC application, enterprise business information is sometimes promotion information or announcements, they can all be delivered through push message user. This chapter introduces two technologies for implementing message push, one is based on HTTP, and the other is based on Netty's TCP. Readers can use them for reference. After implementing message push, we also need to pay attention to the performance of the server, from the maximum number of connections supported to the thread resources used, we need to consider. We also introduced the generation of weak networks, as well as the communication and implementation methods with APNs.
Chapter 6 The Way of RPC focuses on thinking and analyzing from the underlying principles of RPC;
A mature RPC framework assumes the mainstay responsibilities in the overall system architecture of the enterprise. Whether we are doing distributed systems or implementing microservices, we cannot lack the use of RPC. In this chapter, we first understand RPC, then introduce the basic principles of RPC implementation, and then think about the stages in which RPC time is spent, and finally introduce the knowledge of asynchronous RPC. We already know that for pure IO applications like gateways, asynchronous RPC calls will improve system performance. However, in most business call relationship scenarios, RPC is still called synchronously. In some scenarios, we still need to consider whether asynchronous methods can be used to achieve better results.
Chapter 7 The Way of IO In-depth analysis of multiplexing technology and the NIO model in Tomcat;
In the "Interpretation of TO Multiplexing Technology" section, we already have an understanding of this technology. At that time, we also introduced user mode and kernel mode. If the thread executes user code, then the current thread is in user mode; if the thread executes code in the kernel, then the current thread is in kernel mode. At a deeper level, the operating system has four levels of privileges for the code, but modern operating systems only use two levels, 0 and 3. The switch between 0 and 3 is the switch between user state and internal state.
The I/O multiplexing model is synchronous non-blocking, where non-blocking refers to IO read and write, which corresponds to recvfrom operation, because the data message is ready and does not need to be blocked. It is said to be synchronous because the execution of a request is in one thread. Sometimes it is said that it is blocking. In fact, it means that it is blocked on Select and must wait for network events such as read ready and write ready! Earlier we also learned that IO multiplexing is multiplexing, where multipath refers to multiple links, and each link corresponds to a channel. In other words, multiple channels are multiple channels. Reuse means that multiple connections reuse a thread or a small number of threads.
Chapter 8 The Way of Microservices uses two practices I have personally experienced as cases to introduce how microservices are implemented; in this chapter we talk about the knowledge of microservices and does not expand from the "technical" dimension, such as implementations like Spring Cloud Framework, but combining the author's own two practices, one is how to do a system split after microservices, and the other is how to do a database split in the direction of microservices. In addition to developing new systems in our daily work, in most cases we want to manage online production systems. How do these systems de-microservice? If they are already microservice-oriented, how to do a system review to find unknown problems ? Readers can combine these two cases to think from the application layer and database layer.
Chapter 9 The Way of Fault Tolerance combines the knowledge of the previous chapters to focus on the common methods of system fault tolerance, as well as the technologies commonly used by my company in preparing for the big promotion;
In this chapter, we have introduced a series of fault tolerance methods such as current limiting, thread pool isolation, fast failure and fusing. Attentive readers may have noticed that some of the fault-tolerant methods we talked about are based on synchronous calls in some scenarios, so there may be questions about why not use asynchronous calls? Basically mature RPC will support asynchronous calls, and everyone still There are several reasons for the widespread use of synchronous methods. First, synchronous calls can meet most business scenarios. Secondly, asynchronous methods need to pay more attention to memory monitoring and order issues. In addition, synchronous calls are more direct in coding habits. There is no need to add methods such as monitoring callbacks. The asynchronous method will only be used when it is considered that there is indeed a need for asynchronous scenarios. For example, the gateway system will receive better results if the asynchronous method is adopted. We also introduce it in the Gateway Road chapter The idea of asynchronous.
The two most important elements for the operation of online systems are, one is to operate stably, and the other is not to let the local influence on everything. We build online systems in an attitude of not making mistakes in our work, but the cruel reality has proven time and time again that system problems frequently exposed online. Therefore, we must put a large part of our energy on system fault tolerance, that is, not allowing local problems to affect the whole. For example, in the aforementioned system, a problem with an external dependency causes the entire system to refuse to request service. This is a terrible failure, and once it occurs, it is a catastrophic accident. The fault-tolerant measures introduced in this chapter can effectively prevent problems that cannot be eliminated. For example, the incident of Netflix's online system in the early years, and the occurrence of such incidents that locally affected all in recent years.
In addition to Chapter 10 Programs, I combined my real feelings to describe the insights between fitness exercises and programs, as well as the programmer's hardware equipment.
First-line big cows highly appraise this article
I hope that everyone can apply what they have learned, apply this knowledge flexibly to actual work, and strive to improve the depth and breadth of their skills, and make themselves more valuable. This is also a big leap for your future.
For those of you who need to share the training methods of architects online by senior architects of JD.com, and those who practice core technology training documents, there is a free through train below!
