System Architecture Series: Architecture technology to solve the problem?

System Architecture Series (six): the technical architecture to solve the problem?

•  

Technical architecture common understanding and agreement in the industry did not form, different people understanding is not the same, some people believe that the introduction of middleware technology architecture. I do not think so, if that is the case, just the middleware stack together is the technical architecture, technical architecture that is waking up. In similar business scenarios similar technology architecture is possible, but definitely not a technology infrastructure can contain all architectures. This article is to explore what is the technical architecture, technical architecture to solve any problem, and finally to high concurrency scenarios, for example to draw technical architecture diagram.

 

First, what is the technical architecture

Technical architecture is the architecture of a design, in other words, it is an example of the system architecture, then it should be a common feature with system architecture, in the first article already mentioned, the system architecture to solve a specific problem = + elements + connection , with this formula, to define a technical architecture: technology architecture = solve technical problems on the technical solution + business + technology components  , and then refined at the following:

• Solve technical problems on the business : In addition to basic business functions in the operating environment, it is also a system, there is an important feature of the system is to emerge , what does that mean? Originally usually non-issue now becomes a problem, give a simple example, a simple login function, the user name and password for authentication in the background, the validation is successful jump to home, failed to jump error page. This function is too simple, however, and placed under a common business scenarios, this is certainly not a problem, but with Taobao to log on, you see, still before operating it? Here we may understand, the technical architecture must solve the technical problems on the business, in general, technology infrastructure problems to be solved are: high concurrency, high availability, high performance, scalability ... .

• Technical solutions : for the above technical problem, then design technology program, where the program should be a systematic program, definitely not a problem with one or several middleware can be solved. So in the design, to find the nature of the problem, take high concurrency is concerned, I believe that it is of limited resources to deal with a large number of requests , the contradiction is obvious, that is, limited resources and the large number of requests, if you go to solve this problem ? From the conflict, each resource in the processing request and fuss, so from the front end, the network, the rear end can be designed out a systematic scheme.

• Technology components : technical solutions which involve the use of the technology component, such as a distributed cache, the message queue, the distributed regular tasks and network communication, which is a technical component, the technical solution will select one or more techniques as needed components to complete the goal. Purely technical component itself is no technical value, it should be placed in the appropriate business scenarios will reflect the value of the past.

With a picture below to summarize the relationship between all three of them, we can see is the soul of the role of technical solutions, technology components is the basis of ability, middleware is the basis of ability, but it is not all, the technical architecture of the soul of the technical architecture It is a technical solution .

Second, high concurrency technology architecture

High concurrency for everyone concerned is no stranger, even college students also can give a number of high concurrency, caching, message queues ... these are mentioned, not who is right, like caching, message queues, which are highly specific solutions one of concurrent means, in this article, we hope to solve real problems by thinking scene technology architecture.

2.1 high concurrent nature of the problem

I have always emphasized the nature of the problem, because in order to really understand the problem, so as to solve the problem, even if the problems are not catch, how can it solve the problem. High concurrent nature of the problem I think is the limited resources to deal with a large number of requests (I will mention a point in time with new people, about three years of work, to be able to raise 10 most representative of their own skill level, then, very refined techniques revealed The essential problem). So it's quite clear contradiction to: How to use limited resources to deal with a large number of requests, the solution is to resolve this contradiction.

2.2 Systematic Thinking on Solve Conflict

According to our thinking, we can roughly to think from the perspective of the following:

• Resource capacity strength : before the resource processing capacity is weak, it can not become strong?
• Fewer resources : resources can not increase it?
• Request more problems : the request can not reduce it?
• Processing speed : If you can handle requests faster processing will be more.

Note that the above there is a word of resources , resource here contains two meanings: First, a hardware resource, such as machine nodes, memory size, and so on; the second is business resources, such as the number of commodities spike at the scene. So fewer resources and not simply to increase the resources can be solved, the spike is so small number of commodities.

2.3 way to deal with high concurrency

We assume that the scene is the large number of users to access (not spike scene, spike scene has its own approach), or ways to cope analysis then down from above.

2.3.1 resource capacity strength

One of the most simple way is to enhance the capacity of resources, it is to enhance the performance of the machine, which is to enhance the hardware configuration, this is the easiest way, but it has a certain cost. For example the author before such a scene is empirical, Mysql data stored on the hard disk and stored on the machine SSD, processing speed thereof is large to distinguish, without any optimization code, its performance can be provided doubled. Of course there must indicate that a large number of IO read and write existing business, it is replaced by solid-state drives can play an immediate effect.

Said above, it is to spend some hardware upgrade costs, so as a manager is concerned, can not change the configuration, do not change the configuration, but it does have significant performance gains.

2.3.2 fewer resources

Above the beginning has been mentioned, the scene here is not spike scene, so we can respond by increasing machine nodes, 1w if there is a request, a machine processing 100 requests, 100 machines get, if only 10 machines, that a machine 1000 requests to be dealt with, this method is called machine level expansion .

当然要做到能够水平扩展，必须是无状态的。 无状态简单理解就是请求之间没有记忆功能，但有时一个请求又涉及到多个涉及到多个操作，如下单、库存、支付等，用户信息肯定要携带，如何做到无状态呢？常见有几种做法：

• stick 粘滞：对同一个用户请求转发到同一台机器上
• 集中式存储：如 session 共享就集中存储在一个集群上，每台机器去集群上 get 信息就行
• token：相比集中式存储，token 就显得比较轻巧，它是不需要额外的存储，利用的是加密、解密的思想，在请求中就携带了相关信息，所以就不需要再去查了。

2.3.3 请求多的问题

既然请求过多，怎么做到请求少呢？注意并不是不让请求。一般有几个思路处理：一是错峰处理，避免集中请求，这里就可以分流，压力自然就减少了；二是排队，整体集群的能力是一定的，所有的请求先入队列，集群从队列中取请求就行；三是限流，这是稳定性常用的手段，具体在高可用中会讲解。

2.3.4 处理速度

“天下武功，唯快不破”，处理快很关键。所以现在我们在快上做文章。一般的请求轨迹：前端访问 -> 前置逻辑判断 -> 业务处理 -> 数据存储 -> 结果响应返回。

这里有几个点：网络开销、CPU 处理、IO，把这几个耗时关键点降下来，整体效果就比较明显。

• 网络开销：能不能没有网络开销呢？有的，完全可以静态化放在 CDN 上，双 11 晚会承接页就是放在 CDN 上，只有实际变化的数据才会请求后端，其它的数据都是静态化的，处理速度非常快，当时的 QPS 达到 10W。有的不能完全没有网络开销，可以合并请求减少请求访问，能一次访问获取到结果的，不要再发一次请求，可以不发请求的就一定不要发请求。虽然每次请求就 10 几 ms，在量大的情况下，这就是压死骆驼的一根稻草。

• 前置判断逻辑：这个过程一般是查询，每次查询不管是访问 db 或者是文件，都会有 IO 消耗，如何避免呢？存在缓存中可以提高访问速度，访问速度快慢顺序：本地内存 > 远程缓存 > db，但要注意一点，如果使用到了缓存，一定要考虑缓存数据的一致性，一致性问题包括多级缓存和缓存和数据库中的一致性。

• CPU 处理：在业务处理过程中，包括了很多步骤，如果操作步骤没有依赖关系的，完全可以并行处理，最后通过 java 中的 Future 获取各个步骤的结果；还有一种是操作过程中并不是实时要处理的，如发通知等，完全可以异步执行，这样也能节省时间。

• IO 处理：IO 速度相对内存而言是慢的，IO 有两种情况，一是读，另一种是写，如果是读，自然想到通过缓存来提速，也可以把请求打散到不同的机器，如 Mysql 的主从模式，可以从不同的从服务器上读数据；写数据的时候可以延迟写，在高并发的场景下，不要直接与 IO 打交道，可以放要处理的数据放在消息队列中再慢慢处理落地到数据库中。

通过上面的分析可以看出，我们在应对高并发是可以从多个不同的角度来考虑，只要思路打开了就会形成系统性的解决方案。

2.4 高并发的应对方法总结

下面通过思维脑图的方式整理归纳应对高并发的解决方法。

2.5 高并发技术架构图

三、总结

This article discusses what is the technical architecture, technical architecture of the formula given: technical architecture = technical solutions to solve + + technology components, and the relationship between the three technical problems on the business. To see technology components is the basis, technology is the soul of the program, using different technology components together to resolve implementation issues. Similar scenes have similar technical architecture, the key is what the technical architecture to solve the problem is, captures the essence of the problem, and then from the conflict, systematic propose solutions.

Reference article:

"System Architecture series (a): how to define the concept with the formula? " "
System Architecture Series (2): The way to deal with the concept of the "
" system architecture series (three): Business Architecture combat Part I "
," System Architecture series (four): business architecture next combat, "
" System Architecture Series (five ): high technology architecture design and implementation of the system can be extended. "