I. Introduction
With social progress and development, technology, the previous mainframe architectures apparently due to high cost, difficult maintenance and other reasons gradually become less mainstream, replacing it is the hottest moment of the distributed architecture, from large machine to distributed, has gone through several stages, we understand the various stages of architecture, in order to better understand and appreciate the benefits of a distributed architecture, then this article we'll talk about the evolution of the distributed architecture, we can hope bring an impact.
Second, the background note
We all know that a mature system architecture of large sites are not the beginning of the design is perfect, nor the outset with the characteristics of high performance, high concurrency, high availability, security, etc., but with the increased volume of users, extended business functions evolved over slowly improve. In this process, a very big change development model, technology infrastructure, and this will happen with iteration. And for different business characteristics of the system, each will have its own focus, such as Taobao this type of site, to focus on solving the problem is massive product search, order, pay and other issues; such as Tencent's website to solve hundreds of millions of real-time messaging user's level; and as such the company Baidu to be solved is searching vast amounts of data. Every kind of business has a different system architectures.
Let's simulate a simple evolution of architecture. We javaweb example, to build a simple electronic business systems, systems from the point of view of the system evolution. Note that the next demonstration model, is concerned that the amount of data traffic increase, changes in the structure of the site, rather than focus on specific business function point. Secondly, this process is to allow us to better understand some of the issues in the evolution of the site and coping strategies.
If our system has the following features:
- User modules: user registration and management.
- Product module: product display and management.
- Trading Module: Create a transaction and payment settlement.
Third, Phase One: Single Application Architecture
This stage is the beginning of the site, it can be considered an early system architecture as shown in Fig development of the Internet. We often run all our programs and software on a single server. All software and applications are deployed on a single machine, thus completing set up a simple system, the emphasis at this stage is efficiency. The efficiency of life and death.
Fourth, phase II: application server and database server separated
With the on-line site, traffic gradually increased, gradually increase the load on the server, we should not overload the server when it is a good plan to enhance the load capacity of the site. If this time has been no way to continue to improve in the code optimization level, then at the time of the performance bottleneck of a single machine, increasing machine is a relatively simple and easy way to input-output ratio is quite high. At this stage to increase the machine's main purpose is to split off from the web server and database server, do so not only improve the load capacity of stand-alone, but also improve the disaster recovery capability of the whole system.
Five Phase III: Application server cluster
At this stage, as the traffic to continue to increase, a single application server has been unable to meet our needs. I assume that the database server is not experiencing performance problems, then we can be clustered application server by adding application server mode, so that you can be diverted to individual user requests the server to achieve the purpose to continue to improve the system load capacity. At this point there is no direct interaction between the various application servers, they are dependent on each database to provide services.
System architecture development to this stage, the problems will be followed:
-
Users who referred to the request forwarded to the specific application server (who is responsible for load balancing)
-
If every user access to the server is not the same, then how to maintain
session, the purpose of session sharing.
So this time, the system architecture will become as follows:
Load balancing can be divided into hard and soft load load. Soft load we can choose Nginx, Apache, etc., we can choose F5 hardware load and so on. The session sharing problem we can solve shared by configuring the tomcat session.
Six, four stages: pressure becomes large database, the database separate read and write
架构演变到上面的阶段，并不是终点。通过上面的设计，应用层的性能被我们拉上来了， 但数据库的负载也在逐渐增大，那如何去提高数据库层面的性能呢？有了前面的设计思路以后，我们自然也会想到通过增加服务器来提高性能。但假如我们单纯的把数据库一分为二，然后对于数据库的请求，分别负载到两台数据库服务器上，那必定会造成数据库数据不统一的问题。 所以我们一般先考虑将数据库读写分离。
这个架构设计的变化会带来如下几个问题：
- 主从数据库之间的数据需要同步(可以使用 mysql 自带的 master-slave 方式实现主从复制 )
- 应用中需要根据业务进行对应数据源的选择( 采用第三方数据库中间件，例如 mycat )
七、阶段五：使用搜索引擎缓解读库的压力
我们都知道数据库常常对模糊查找效率不是很高，像电商类的网站，搜索是非常核心的功能，即使是做了读写分离，这个问题也不能得到有效解决。那么这个时候我们就需要引入搜索引擎了，使用搜索引擎能够大大提升我们系统的查询速度，但同时也会带来一 些附加的问题，比如维护索引的构建、数据同步到搜索引擎等。
八、阶段六：引入缓存机制缓解数据库的压力
然后，随着访问量的持续不断增加，逐渐会出现许多用户访问同一内容的情况，那么对于这些热点数据，没必要每次都从数据库重读取，这时我们可以使用到缓存技术，比如 redis、memcache 来作为我们应用层的缓存。另外在某些场景下，如我们对用户的某些 IP 的访问频率做限制， 那这个放内存中就又不合适，放数据库又太麻烦了，那这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库。
九、阶段七：数据库的水平/垂直拆分
我们的网站演进的变化过程，交易、商品、用户的数据都还在同一 个数据库中，尽管采取了增加缓存，读写分离的方式，但是随着数 据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我 们可以考虑对数据的垂直拆分和水平拆分。
垂直拆分:把数据库中不同业务数据拆分到不同的数据库。
水平拆分:把同一个表中的数据拆分到两个甚至更多的数据库中，水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈，这时可以采取将表拆分到多个数据库中。
十、阶段八：应用的拆分
随着业务的发展，业务量越来越大，应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑将应用拆分，按照领域模型将我们的用户、商品、交易拆分成多个子系统。
这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来，否则就是一个坑。所以通过走服务化路线的方式来解决。
那么服务拆分以后，各个服务之间如何进行远程通信呢? 通过 RPC 技术，比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通过这些技术能够很好的解决各个服务之间通信问题，但是， 互联网的发展是持续的，所以架构的演变和优化也还在持续。
十一、总结
通过本文，我们通过一个电商的案例，就了解到了分布式架构的演进过程，一环套一环，环环紧密相扣。都是通过业务量和访问量的提升来考虑重构架构设计，以便能够适应当前的环境。不可一蹴而就，也急不来，初创企业必须稳扎稳打，一步一个脚印的走出一条专属自己的路。加油，everybody