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

     

单服务器:

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

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

     多台服务器:

      后来随着用户数量越来越多,请求数量越来越大,单机的承载能力就达不到要求了。我们考虑提升服务性能(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。

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

原文地址:https://www.cnblogs.com/fer-team/p/10194861.html