目录
一、单台服务器+数据库(原始)
二、增加反向代理
三、引入负载均衡器
四、扩展数据库
五、微服务
六、缓存和内容分发网络(CDN)
七、消息队列
八、总结
一、单台服务器+数据库(原始)
原始架构
二、增加反向代理
反向代理
代理是一个接收和转发请求的过程。正常情况下,「正向代理」代理的对象是客户端,「反向代理」代理的对象是服务端,它完成这些功能:
- 健康检查功能,确保我们的服务器是一直处于运行状态的
- 路由转发功能,把请求转发到正确的服务路径上
- 认证功能,确保用户有权限访问后端服务器
- 防火墙功能,确保用户只能访问允许使用的网络部分等等
三、引入负载均衡器
引入负载均衡器
反向代理还有另外一个功能:他们也可以充当负载均衡器。
Nginx经过配置,可以反向代理多台服务器。
部署多台Nginx(反向代理服务器),防止宕机,提升系统运行稳定性。
Nginx反向代理以及负载均衡配置参考:
四、扩展数据库
扩展数据库
数据一致性的问题。
(1)主从模式或者单实例写多副本读
读多写少的情景。
I、如何进行同步?
同步机制
通过使用消息队列进行异步数据同步,来实现数据的最终一致性。当然消息队列的各种异常也会造成数据不一致,所以我们又引入了实时监控服务,实时计算两个集群的数据差异,并进行一致性同步。
II、主从模式弊病
主从模式架构
当主库DB1出现问题时,DBA会将DB2切换为主库,并通知项目组,项目组使用DB2替换原有的主库DB1,重启web服务器,这样web服务将使用新的主库DB2,而DB1将不再被访问,整个数据库服务得到恢复,等DBA修复DB1时,再将DB1作为DB2的从库即可。
这里有个很大的问题,就是不管主库或从库出现问题,都需要DBA和项目组协同完成数据库服务恢复,这很难做到自动化,而且恢复工程也过于缓慢。
所以数据库如何做到高可用呢?
高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。
数据库高可用架构
如上图所示,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包,降低了复杂性,但是随着规模的增加,事情会变得复杂和低效,更多的开发人员加入进来,在同一台服务器同一个项目代码里面进行开发,造成的冲突会越来越多,互相依赖性太高,同时不利于新入开发人员阅读理解代码。
这时候微服务架构产生了。
微服务架构
- 每个服务都可以单独扩展,更好地适应需求
- 开发团队之间相互独立,每个团队都负责自己的微服务生命周期(创建,部署,更新)等。
- 每个微服务都有自己的资源,比如数据库,进一步缓解了数据库的问题。
微服务的划分大多是基于业务进行拆分,实现低耦合。
六、缓存和内容分发网络(CDN)
缓存架构
网络应用的很大一部分由静态资源构成,如图片、CSS样式文件、JavaScript脚本以及一些针对特定产品提前渲染好的页面等,通过使用缓存,对于一些客户的请求,不一定都去重新处理一遍,使用缓存,提高访问速度。
缓存的加强版叫内容分发网络(Content Delivery Network),遍布全球的大量缓存。 这使得用户可以从物理上靠近他们的地方来获取网页内容,而不是每次都把数据从源头搬到用户那里。
七、消息队列
消息队列
将客户的任务请求放到一个队列当中,进行管理任务,优点:
- 解耦了任务和处理过程。有时需要处理大量的图片,有时很少。有时有大量服务可用,有时很少可用。简单地把任务添加到待办事项而不是直接处理它们,这确保了系统保持响应并且任务也不会丢失。
- 可以按需扩展。启动大量的服务比较耗时,所以当有大量用户上传图片时再去启动服务,这已经太晚了。我们把任务添加到队列中,我们可以推迟提供额外的处理能力。
八、总结
大道至简,不管采用什么方案,优化的根本都是分而治之,大事化小,小事再化小,没有啥是一个中间件解决不了的,如果有,那么再加一个!