目录

一、单台服务器+数据库(原始)

二、增加反向代理

三、引入负载均衡器

四、扩展数据库

五、微服务

六、缓存和内容分发网络(CDN)

七、消息队列

八、总结



一、单台服务器+数据库(原始)


千万级流量架构图 百万级流量_高并发方案发展过程

原始架构

 

二、增加反向代理


千万级流量架构图 百万级流量_千万级流量架构图_02

反向代理

 

代理是一个接收和转发请求的过程。正常情况下,「正向代理」代理的对象是客户端,「反向代理」代理的对象是服务端,它完成这些功能:

  • 健康检查功能,确保我们的服务器是一直处于运行状态的
  • 路由转发功能,把请求转发到正确的服务路径上
  • 认证功能,确保用户有权限访问后端服务器
  • 防火墙功能,确保用户只能访问允许使用的网络部分等等

三、引入负载均衡器


千万级流量架构图 百万级流量_服务器_03

引入负载均衡器

 

反向代理还有另外一个功能:他们也可以充当负载均衡器。

Nginx经过配置,可以反向代理多台服务器。

部署多台Nginx(反向代理服务器),防止宕机,提升系统运行稳定性。

Nginx反向代理以及负载均衡配置参考:

四、扩展数据库


千万级流量架构图 百万级流量_数据库_04

扩展数据库

 

数据一致性的问题。

(1)主从模式或者单实例写多副本读

读多写少的情景。

       I、如何进行同步?


千万级流量架构图 百万级流量_千万级流量架构图_05

同步机制

 

        通过使用消息队列进行异步数据同步,来实现数据的最终一致性。当然消息队列的各种异常也会造成数据不一致,所以我们又引入了实时监控服务,实时计算两个集群的数据差异,并进行一致性同步。

        II、主从模式弊病


千万级流量架构图 百万级流量_数据库_06

主从模式架构

 

       当主库DB1出现问题时,DBA会将DB2切换为主库,并通知项目组,项目组使用DB2替换原有的主库DB1,重启web服务器,这样web服务将使用新的主库DB2,而DB1将不再被访问,整个数据库服务得到恢复,等DBA修复DB1时,再将DB1作为DB2的从库即可。

       这里有个很大的问题,就是不管主库或从库出现问题,都需要DBA和项目组协同完成数据库服务恢复,这很难做到自动化,而且恢复工程也过于缓慢。

       所以数据库如何做到高可用呢?

       高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。


千万级流量架构图 百万级流量_千万级流量架构图_07

数据库高可用架构

 

       如上图所示,web服务器将不再直接连接主库DB1,而是连接KeepAlive虚拟出的一个虚拟ip,再将此虚拟ip映射到主库DB1上,同时添加DB_bak从库,实时同步DB1中的数据。正常情况下web还是在DB1中读写数据,当DB1宕机后,脚本会自动将DB_bak设置成主库,并将虚拟ip映射到DB_bak上,web服务将使用健康的DB_bak作为主库进行读写访问。这样只需几秒的时间,就能完成主数据库服务恢复。

       同样的,web服务器将不再直接连接从库DB2和DB3,而是连接LVS负载均衡,由LVS连接从库。这样做的好处是LVS能自动感知从库是否可用,从库DB2宕机后,LVS将不会把读数据请求再发向DB2。同时DBA需要增减从库节点时,只需独立操作LVS即可,不再需要项目组更新配置文件,重启服务器来配合。

(2)分库分表操作

       参考:

                  https://www.jianshu.com/p/32b3e91aa22c

五、微服务

        将所有服务放在一个服务器上,放在一个JAR包,降低了复杂性,但是随着规模的增加,事情会变得复杂和低效,更多的开发人员加入进来,在同一台服务器同一个项目代码里面进行开发,造成的冲突会越来越多,互相依赖性太高,同时不利于新入开发人员阅读理解代码。

       这时候微服务架构产生了。


千万级流量架构图 百万级流量_分布式系统演变_08

微服务架构

 

  • 每个服务都可以单独扩展,更好地适应需求
  • 开发团队之间相互独立,每个团队都负责自己的微服务生命周期(创建,部署,更新)等。
  • 每个微服务都有自己的资源,比如数据库,进一步缓解了数据库的问题。

微服务的划分大多是基于业务进行拆分,实现低耦合。

六、缓存和内容分发网络(CDN)


千万级流量架构图 百万级流量_分布式系统演变_09

缓存架构

 

       网络应用的很大一部分由静态资源构成,如图片、CSS样式文件、JavaScript脚本以及一些针对特定产品提前渲染好的页面等,通过使用缓存,对于一些客户的请求,不一定都去重新处理一遍,使用缓存,提高访问速度。

       缓存的加强版叫内容分发网络(Content Delivery Network),遍布全球的大量缓存。 这使得用户可以从物理上靠近他们的地方来获取网页内容,而不是每次都把数据从源头搬到用户那里。

七、消息队列


千万级流量架构图 百万级流量_分布式系统演变_10

消息队列

 

 将客户的任务请求放到一个队列当中,进行管理任务,优点:

  • 解耦了任务和处理过程。有时需要处理大量的图片,有时很少。有时有大量服务可用,有时很少可用。简单地把任务添加到待办事项而不是直接处理它们,这确保了系统保持响应并且任务也不会丢失。
  • 可以按需扩展。启动大量的服务比较耗时,所以当有大量用户上传图片时再去启动服务,这已经太晚了。我们把任务添加到队列中,我们可以推迟提供额外的处理能力。

八、总结

       大道至简,不管采用什么方案,优化的根本都是分而治之,大事化小,小事再化小,没有啥是一个中间件解决不了的,如果有,那么再加一个!