It is also an occasional opportunity for me to encounter GO language. I do architecture related things at work, and I must pay attention to the hot new language. So I stepped into the world of GO language, GO brought me a new experience;
People who have been doing one thing for a long time tend to get stuck in one thing, and when they start to practice GO, they always feel awkward everywhere, especially when they regard structures as classes and inherit structures. But write more gradually also get used to, even feel more and more pleasing to the eye.
After getting familiar with GO for a period of time, I stopped for a while, thinking about the simplicity of GO (consistent code style, concise and not cumbersome to use, extremely simple deployment, fast compilation), and what changes can be brought to the project system and architecture. But at that time, I didn’t think it would be very helpful. Later, the system gradually began to use GO, and gradually found that:
Yi ~, deployment no longer build dependent environment (do not deploy environment release, at the beginning is really a bit not used to, always feel less to something;
There is no resistance to code written by others. Although some code is not written by myself, when I read it carefully, I feel as if I wrote it myself. When I write JAVA and PHP, I do not reject it from my heart.
Development of a microservice interface everything becomes simple, write a main, write an interface, submit, seconds seconds on the line ~;
The above is mainly about my encounter with GO and the initial impact of GO on me. Just one night, an idea suddenly occurred to me: GO language brings many improvements with simplicity. Can the architecture system I am working on also simplify and reduce the system complexity by using GO? The idea has been in my head ever since IT popped out. Recall, engaged in architecture related things first time, a see, what is the principle of middleware can optimize the performance improvement is very excited, hard grind until he felt on top of (now will, of course), and then to use in the system, the more feel system architecture with middleware components, the better, the more the look yourself how great architecture. But the more you do it, the more you realize that the system works, you can’t just build for architecture’s sake. Subtracting from the traditional technology stack also requires deep foundation, because only fully know the technical principle can replace, also dare to think dare to do, no problem. As the saying goes: Mainland “all roads lead to Rome”, from a personal point of view architecture should be suitable for the business, at less cost to complete as many things as possible even if reached the target of architecture design, the same server resources such as consumption circumstances can support several times or even dozens of times request, achieve the same amount requested, implementation and deployment is very simple to operation, etc. GO’s thoughts have been influencing me imperceptively during this period of time.
Until we decided to do microservices as a company, we started doing microservices in Java. Later, I thought about whether other languages can also do micro services, and naturally CAME up with GO. After some difficulties and difficulties, I felt that I could write some micro services with GO. After writing, I found that Golang was quite easy to write micro services, with high efficiency, and did not need to package Tomcat (it is particularly inappropriate to put it in jar package). Binary can run in Docker without system dependence (don’t believe you try), so from the bottom of my heart, I like GO more and more, and I want to use GO reconstruction for the subsequent system (write more Java, meet so convenient is really a feeling of spring)GO has deeply influenced the view of the system architecture.
But what exactly is architecture, and how is an architect made? Here are the eight hardships that architects have forged:
The first paragraph: moving bricks can be divided into good bricks and only moving bricks (a group of people stay in moving bricks, the rest continue to develop);
The second paragraph: can move the brick can be divided into to understand the principle and programming is to move the brick;
3. Those who understand principles are divided into those who study them and those who only half-understand them.
Continuous research can also be divided into two types: depth and breadth;
Paragraph 5: The depth and breadth of the divided into pure technology and business (began to differentiate);
Paragraph 6: The business type requires good communication, to the system and requirements have a certain design control ability;
7. It’s easy for junior architects to build “architecting” systems using heap middleware alone.
It is very important to consider problems carefully, comprehensively and communicate well. Do the underlying implementation, understand the underlying principle, from the business, research and development, testing, deployment, maintenance upgrade angles, adjust measures to local conditions by the “architecture” is for the sake of development efficiency, in order to run efficiency, in order to develop the quality, for the sake of business flexibility and stable running, convenient to maintain and so on, can be called the architect (recall experience in this respect, How many architectures are beautiful on the surface but painful to use).
When working on a seckill system, the traditional stack that comes to mind first and most easily is distributed session, Redis cluster, distributed cache, NGINx reverse proxy nGINx deep optimization, machine optimization, message queuing. Yes, Cap teacher also thought of these at that time, and also believed that these “mature” technology can be applied to our second kill system no problem, and the internal discussion of the company felt that these problems are no problem. And did in-depth research like:
1. Distributed Session We have made great efforts to use Nginx+ Web + Redis cluster to save sessions to achieve the purpose of Session authentication. The architecture of single point Session is as shown in the figure below:
At first glance, there is no problem, it is always done this way, really large traffic comes, add Nginx, web server, also meet horizontal expansion, but after the traffic reaches 100 million level, our cost is a little big, back and forth network request session time we also want to squeeze (always feel something wrong at that time), Nginx also has 504 from time to time under high traffic.
2. Distributed cache, which looks very simple, but is a very complex thing in a large flow and high concurrency system, mainly can meet the following problems;
1) Cache consistency (if this is used, it will be oversold if not handled properly);
2) Cache penetration;
3) Cache avalanche;
4) Cache black hole problem:
5) Dog post effect;
. There are many other things that need to be noted. In short, distributed cache is widely used and valuable, but to establish a distributed cache system that can meet high concurrency and large traffic needs strong technical team support, and its implementation is particularly complex, which will not be repeated here;
However, our seemingly problem-free solution has huge problems and the bar is very high to achieve. The resource cost is also quite high. Session must meet horizontal expansion, Web cache must meet horizontal expansion, including Redis cluster, which can only be added continuously.
As a simple example (excluding other factors, to illustrate the importance of architecture), suppose we have a single machine with 5000QPS of interface capacity (8 cores, 8G) and hundreds of millions of seconds of traffic to process. The instantaneous traffic at the start of the second kill is estimated at 300W, and the average wait time is calculated at 7 seconds (the interface can tolerate up to 3.5Wqps). The result is that our system needs nearly 90 sets of interfaces, not counting other supporting servers with the same requirements. These supporting servers are simply described as follows.
1. First of all, nginX level should have the same level of processing capacity (each unit is not optimized about 2WQPS, estimated to be about 20 units);
2. The Web interface should also be extended to the corresponding level (an estimated 90);
3.Reids cluster has left and right in the case of multiple goods (single goods, cluster is useless in the case of a large number of visitors);
The above is the machine requirements to meet the distributed Session, not counting the distributed cache, students can probably feel how difficult it is to build and build a seckill system, the complexity of deployment has not taken into account. Implementation is really complicated, 4-5 years of experience, one or two people in a short time really can not complete. Can you think of another way to simplify it? The answer is: yes. The first is to understand the principle, and the second is to subtract from the architecture. No need to optimize.
Where do you optimize?
1)Session can be omitted according to the principle of permission verification in the second kill concurrency;
2) We can dispense with distributed caching (interfaces instead);
3) Save nginx (easier to operate and maintain);
4) Redis cluster can also be omitted;
How do you do that? Using Java and PHP is not impossible to achieve, but the implementation can be more difficult, but now can combine the GO language features to give us new ideas;
1. You can omit Nginx and use GO to start the port to expose the service.
2. Cookie mode or WT mode is adopted to replace distributed Session scheme, and server-side code level verification;
3. Overselling adopts interface form instead of Redis cluster;
4. Load balancing using cheap SLB(avoiding Nginx);
After seckill optimization, the presidential architecture can be displayed as the following structure. For details, please refer to Go High-concurrency Seckill Practice:
From the results of transformation, we are mainly listed as follows:
1. Web applications deploy base files using Go, and centos servers do not need to follow any dependency (greatly convenient deployment) :
2. Use SLB cheap utility to avoid nginx reverse proxies, even advanced Lua scripts;
3. Redis cluster is also avoided here, using interface to provide services;
The entire stack only needs to know: GO, RabbitMQ, Mysql to complete a high concurrency seckill system, which is attractive for ease of operation; The following can be deduced from the adjusted architecture (the current stand-alone GO provides web interface, which can reach about 2WQPS without optimization) :
1. The performance of stand-alone GO interface permission verification is improved by 4 times, and the deployment complexity can be said to be close to zero (no Nginx, no Redis cluster, and no dependent environment for operation);
2. With the continuous improvement of traffic level, only need to add web server and quantity control server, no other service overhead (scalability can be said to reduce the cost as much as possible, proportional growth mode, and no performance bottleneck);
3. Compared with the traditional scheme, the number of servers is reduced by more than 4 times (you can calculate it on the original basis);
The above solution is implemented on the basis of the simplicity of the GO language, which happens to be convenient to deploy and improve the ease of implementation, and just happens to be able to provide Web services to reduce external dependencies (its own web service performance is also high). With GO’s two proper features, it is difficult to subtraction operations in coordination with the architecture to make the whole implementation of the seckill system. Of course, Java and PHP can do the adjusted seckill architecture shown in the above figure, but from many aspects, the president still has the obvious advantages of GO.
Looking back at the scheme, I feel that Go drives the change of thinking mode, its simplicity drives the simplicity of implementation, and its efficiency and stability drives the optimization of architecture. A good system architecture should be simple, efficient and easy to implement.