基于并发订课系统的架构演变

     

单服务器：

我们平时开发项目的时候，最擅长的就是本地构建开发应用服务，数据库也安装在本地。静态资源和应用程序在一个根目录的形式。如下图所示：

 

 这种形式放在生产服务器上也就是最简单的单机架构，部署简单，维护也方便。

     多台服务器：

      后来随着用户数量越来越多，请求数量越来越大，单机的承载能力就达不到要求了。我们考虑提升服务性能（QPS）的方式，有两种方式，增加硬件配置+增加服务器数量。

 增加硬件配置，比如以前是4核的可以提升16核，4g内存的可以提升到32g等等，但是提升服务器是有瓶颈的，也需要考虑性价比。通常考虑增加服务器。

    可以考虑把应用程序放一台服务器，文件系统放一台服务器，数据库放一台服务器。

 

 

 基于这种架构后，服务器性能会得到很大提升。这种也称为分布式服务，即多台服务器完成一台服务器的工作。

 注意：分布式第一定律：就是不要使用分布式，说明分布式是由代价的。

 使用缓存：

接下来业务继续增长，当前服务无法满足要求的时候，我们接下来可以考虑做的事情是使用缓存。我们在做系统优化的第一步最好先确认有没有使用缓存，如果没有使用缓存，说明我们所有的数据都是从数据库读取的，这种数据获取既费时间，又不经常改变的，可以用缓存优化，性能会得到很大提升。

 

集群负载均衡：

  集群（Cluster），使用多台服务器完成一台服务器的工作，每台服务器都能独立工作。

  负载均衡：把客户端的请求转发到集群。我们可以用nginx做负载均衡，也可以通过DNS做负载。

      DNS负载：部署多个对外的独立IP。DNS服务器配置对应多个IP，域名访问时到DNS服务器进行转发。

      硬件负载均衡：通过专有的硬件服务器做负载，包括F5，Array，NetScale等。

      软件负载均衡：LVS->Linux Virtual Server,HAproxy,Nginx。

 

通过集群负载后，会碰到一个问题，就是用户登录的信息如何保持在登录的那一台服务器。这就涉及到用户持久化的问题。可以通过下面三个方面解决：

      1）我们可以在做负载的时候通过IP Hash会话粘滞策略保证用户登录后请求的服务器都是同一台服务器，但这种方案不是最优的。

      2）我们可以通过session共享，像asp.net可以通过stateServer，SqlServer存储session，还可以基于redis存储。

      3）基于HttpHeader请求， Cookie，Token（JWT，identityServer4)。

 

数据库读写分离：

   最简单的理解就是一个主库，多个从库。增删改在主库上操作，查询在从库。另外有一种的是数据库负载均衡，多个数据库是均等的，都同时增删改，查询通过某种策略分发到某台数据库，给用户的就是一台数据库，比较成熟的是moebius。

 表分区，分表，分库等方式。按业务可以把数据库拆分成一个个小的模块构成数据库。也可以按某一原则切分数据库，数据库结构一样，数据不一样。