大型网站技术架构系列1：网站架构演化阶段

网站架构需要工程师从全局把握一个网站的前台、后台，要知道什么地方会有瓶颈，

对网站的可扩展性、安全性等需要有一个成熟的把握。

下面说的几个阶段可以了解网站架构演化。

1）单机部署

最简单的情况，可以把各个进程放在同一个服务器上，这就好比我们平时写程序，

就一台笔记本，那就各个进程放在一个PC上跑，好了，只管基础功能。

可能包括：应用程序服务器，文件服务器，数据库服务器。

问题：内存不够，硬盘不够，CPU竞争。

如何解决？

2）多机部署

为了解决上面的问题，把 应用程序服务器，文件服务器，数据库服务器 分别放在3个PC上

各司其职，这样就解决了内存、硬盘、CPU竞争的问题。

解决了旧的问题，还是有问题。

对一个系统来说，可能会大量访问数据库，比如是mysql数据库，

这样很容易造成瓶颈，怎么办？就有了下面的方案。

3）引入缓存系统

谁访问数据库，应用程序服务器，

那行，我在应用程序服务器本地上对数据做缓存，或者由专门的服务器作远程缓存服务器。

要知道缓存跟数据库服务器的根本区别在于：前者是一个内存概念，后者是一个硬盘概念。

存取速度不是一个数量级上。

这就解决了数据库服务器的瓶颈。

缓存=本地缓存+远程缓存

但是新的瓶颈出现了，大批量访问，导致应用程序服务器吃不消，

怎么办？

4）服务器集群

可以引入集群，多台应用程序服务器部署下来，

通过负载均衡机制，访问分摊，交给各个服务器解决。

任凭访问量变大，我无非增加应用服务器的个数就好了。

新的问题，假如缓存仍然满足不了应用程序服务器的胃口，

仍然需要访问服务器，怎么办？

5）数据库服务器读写分离

之前的方案，都是数据库服务器负责所有的读写。

现在则读写分离，

怎么个读写分离？

主数据库服务器+从数据库服务器。

写的时候，写到主服务器，主服务器会与从服务器同步，保证数据的一致性。

读的时候就读从服务器，不影响主服务器。

这里需要保证同步的即时性。

必要时考虑分片。

6）反向代理

如果反向代理服务器能够提供用户的资源，则直接返回给用户，

否则提交给真正的服务器，这个可以结合负载均衡处理。

7）引入nosql机制

目前网络的需求很多，对后台的要求也会变多

这个时候考虑引入nosql数据库，可有效解决部分问题。

8）业务拆分

之前只是从技术上解决了一些东西，实际上还有涉及到业务的。

将一个网站拆分成各个子系统，每个系统由一个小组解决，然后拼接在一起。

中间可以通过共用数据库，或者消息队列等方式来糅合。

保持子系统的关联性。

各个子系统以分布式的情景执行。

9)补充：

比如对于数据库服务器来说，主从机制解决不了主服务器宕机的问题。

这个时候要引入服务器集群，保证主服务器宕机后，有一个从服务器上升为主服务器。

保证系统365*24小时的运行。

 

必要时引入分布式文件系统和分布式数据库。

 

推荐一篇博客：http://my.oschina.net/wyyft/blog/169117