架构之路（一）网站架构演化

随着不断的学习，我们接触的技术越来越多，比如RPC、MQ等等，但是更多的时候我们只是从一项技术的角度上去学习，因此也带来了一定的局限性，以MQ为例，可以用来做任务队列、日志系统、流量控制。但是对于其在整个系统的地位没有一个清醒的认识，会导致我们掌握的很多知识只是零散的，没有形成体系。我想真正应该做到的是，利用你所知，能够独立设计部署一个完善的系统，对于系统的每一部分都有清晰的认识，必然会让你更进一步。

好了，闲话少说，我们进入今天的正题，要想清晰的认识一个系统，必然要了解他的发展历程。我们从最基础的单体应用开始说起，

性能驱动演化

一、简单演化

• 单体应用
  我想大多数同学都是从单体应用（也就是最开始的LAMP或者Tomcat）开始做起的，这时候的应用几乎没有架构可言。应用程序以War包方式打包放在Tomcat中，文件可能存储在同一台服务器中，同样的数据库也是在同一台服务器中，这样做的优点对于小型应用或者小型公司来说，部署方便，不需要太多的运维人员，也方便管理，但是缺点也很明显，性能会越来越差，另一方面动一发牵全身。

  
  图片.png
  

  对于大多数小型应用来说，这样的网站架构方式是足够的。

• 应用与数据分离
  随着业务的不断发展，数据量越来越大，单台服务器可能无法满足我们的要求，这时候数据库可能成为了我们的瓶颈，于是这时选择应用与数据进行分离，如下图：

  
  图片.png
  

  ，这时候很明显，三台服务器各司其职，不会因为IO请求占用大量业务处理时间，数据库和文件存储能力得到了很大的拓展，网站的业务得到了更多的支持。

• 增加缓存服务器
  随着网站用户的增加，网站的用户体验显然成为了一个问题，以电商行业为例，大量用户涌入购买商品，用户是不会选择一个需要等待很长时间的网站的。这个时候，即使数据库服务器进行了单独部署，但是大量用户的请求也会给数据库带来很大的压力，对于业务服务器来说，压力可能没有明显的大（举个例子来说，一个新的购物网站，大家浏览的可能性要远远大于购买的可能性，另一方面来说，你总是会选择好评多的商品进行购买），这时候要考虑如何给用户更好地体验，显然，缓存是一个很好的解决方案，用户无需等待很长时间。

  
  图片.png
  

  这个时候，可能我们考虑使用Redis做了一个缓存服务器，缓存一些热点数据，大大减轻了数据库的压力，同时优化了用户体验，这是一个很正确的选择，同时考虑到业务服务器的扩展，我们又增加了本地缓存，放置于应用服务器中，缓存一些常用业务数据。这个时候，一个优雅的架构已经初具雏形了。

集群化演化

业务的进一步发展，此时可能做一些软件上的优化效果已经不够明显，或者说软件的优化效果远远不如增加硬件，我们开始考虑向集群化发展（更换一台性能更加强大的服务器可能远远不如集群化带来的效果好，虽然集群化部署更加复杂），这时候网站已经开始着手于解决高并发与大数据等问题。

• 应用服务器集群化

  
  图片.png
  

  通过独立的负载均衡设备或者软件，将用户的请求分发到不同的应用服务器之上，这也是实现网站可伸缩集群架构最简单的方式，当然不仅仅是应用服务器的集群化，其他的缓存服务器等都是同样的道理。

• 数据库服务器集群化
  在前面，我们增加了缓存服务器，包括本地与远程，对于热点数据而言（业务中的绝大多数数据）完全可以避免访问数据库，但是随着网站的不断发展，缓存系统可能有了新的问题，例如缓存并发与缓存过期导致的缓存穿透与缓存崩溃（这里只给大家做了解）以及大量的写操作可能导致数据库成为了新的瓶颈。这时候，我们考虑使用数据库集群来均衡单个数据库服务器的压力，即我们所说的读写分离，所有的写操作请求主数据库，所有的读操作访问从数据库，主数据库负责异步的同步数据到从数据库。

  
  图片.png
  

  这时候的架构已经可以应付大量数据了，但是对于后台开发来说，有一点需要注意的是，数据库的读写分离对于应用程序来说应该是透明的，也就是说，集群部署，对于应用来说应该是透明的，无需关心访问的目标是谁，这一点可以通过Nginx以及网关等等来解决。

• 反向代理与CDN
  业务不断地发展，从本省发展到了全国，这时候对于外省的用户来说，访问速度必然是不如本省的，我们开始考虑如何让不同地区的用户拥有相同的体验。于是有了反向代理与CDN的出现，两者本质是一样的，都是缓存，但是不同的是CDN需要专业的机房，也就是说需要在全国各地部署机房，用户在请求资源时，可以从最近的机房中获取数据，反向代理则部署在企业的中心机房，用户首先访问反向代理服务器，缓存命中则返回，否则访问应用服务器。

  
  图片.png
  

  使用CDN和反向代理的目的都是尽可能的优化用户体验，同时也减轻了一部分后台服务器的压力。

分布式演化

数据库进行读写分离之后，依然无法满足要求，这时候开始考虑使用分布式数据库，同理，文件服务器也是。
分布式数据库即我们所说的分表，但是通常情况下，我们一般采用业务分库的方式，只有单表数据非常大的时候才会使用。同时我们可能会采用一些辅助措施，例如Redis等 NoSQL数据库，以及搜索引擎等缓解数据库压力。
到这个时候，可能从技术上讲，基本的优化手段已经使用，但是可能依然无法应对巨大的业务量。我们开始考虑从业务角度进行优化。

业务演化

目前常用的SOA理论以及微服务也是为我们提供了从业务角度考虑的思想。

• 业务拆分
  面对日益发展的业务系统，众多的业务越来越耦合，导致性能以及维护十分困难，要考虑进行业务的拆分，即模块化的思想。整个网站可能划分成几百个小业务，考虑业务之间的重用（例如数据访问模块），当然从微服务的角度来说，业务的划分可能更加细致（考虑服务之间的解耦，每个服务有自己的数据访问模块），以用户服务为例，可能注册、登录、管理等各自为一个微服务，这里不讨论详细的微服务，只是单纯的说分布式的服务拆分。

  
  图片.png
  

  到这里，大概的架构演化差不多了，关于微服务后面会详细说，只是给大家做一个大概的描述，对如何实现网站的高可用、高并发、大数据等有一个大概的想法。