高性能、高可用平台架构演变史

开篇概述

在如今移动互联网、互联网+、大数据的时代,各类的互联网网站、平台异常突起,如同雨后春笋,有种“忽如一夜春风来,千树万树梨花开”感觉。
对于移动互联网时代的平台来说,用户的体验感是否良好?平台的稳定性是否良好?估计是对所有互联网平台来说两大头等要素吧,的确,移动互联网时代,流量就是市场价值,说白了就是收益,就是RMB,失去了流量,那么你也就失去了赚取收益的机会与机遇。

高性能、高可用平台架构演变史

因此,对于互联平台或网站来说,网站的高可用、不间断服务也是平台运营过程中的一个重大决定因素,比如说某平台,三天两头的故障,打不开,又或者说,经常性的出现错误、访问超时等等问题,那么用户的流失机率就会随之增加。
那么今天我们就来聊一聊各类高可用架构的一个演变过程到底是如何的?此文民工哥用时三小时总结写作完成,希望对大家有所帮助,欢迎大家拍砖、留言、点赞、转发分享以支持。

什么是高可用?

“高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。简而言之,就是不间断对外提供服务。

架构之初

架构图

高性能、高可用平台架构演变史

架构简述

这类架构比较适用于初创企业或流量较小的平台。
此种架构一般都是在平台运行之初所用到的架构,日均PV不大,简单的架构足以能够应对用户的流量请求,比如前端网站使用Apache/nginx都可以,APP服务器直接使用JAVA环境如tomcat应用,互联网平台的数据库大部分使用Mysql,备份服务器一般都备份一些常用的配置、代码、数据库数据的备份文件等。因此,民工哥称它为架构之初。

架构中期

随着用户数量的增长、访问量的增加,随之而来的问题就是单台服务器已无法承受用户的访问流量,因此前期的基础架构就需要面临一定的调整,大概调整如下

架构图

高性能、高可用平台架构演变史

架构简述

这类架构就此引入了负载均衡的概念,关于应用的负载均衡,前面也有相关的文章介绍,具体文章链接如下
nginx负载均衡与反向代理
Nginx+Tomcat多实例及负载均衡配置

负载均衡的开源软件较多,通常会有以下两种方式
  • 硬件负载——F5 7层或者4层网络代理
  • 软件负载——nginx、haproxy开源负载均衡软件
负载均衡的算法通常有:
  • 轮询法
  • 随机法
  • 源地址哈希法
  • 加权轮询法
  • 加权随机法
  • 最小连接数法

具体使用何种方式,一切以企业实际需求、投入与产出比(成本考虑)为主,但是此类架构也有一定的缺点存在,暂时不考虑前端负载设备的高可用,比如用户的上传与查看文件问题(通过A服务访问上传,然后负载查看时是通B服务器的,就会造成用户无法查看的问题),APP服务器同理;数据库服务器存在主、从库单点问题,一旦故障,可以手工进行故障切换,但是可能会造成数据丢失或不统一,并且会在一定程度上给用户造成不好的体验;因此仍需演变。

架构图

高性能、高可用平台架构演变史

架构简述

此架构在上面的架构基础,以应对各类问题做出的修改,增加了数据存储服务器(NFS共享存储Linux系统NFS网络文件系统),对于存储架构及源件,其实挺多的,具体有以下几种开源软件服务

  • 1、NFS网络共享存储文件系统
  • 2、FastDFS 轻量级网络文件系统(参考文章:分布式文件系统FastDFS详解)
  • 3、分布式文件系统MooseFS
  • 4、GlusterFS文件系统

并配置负载均衡、并且还解决了单点故障的问题,对于数据库服务器做出了一定的架构调整,为双主多从的架构,对于数据库的各种高可用架构,前面也有文章做过分析,具体如:
浅谈MySQL集群高可用架构

MySQL集群高可用架构之MHA

但是所有架构都是要以实际需求(如对数据完整性、一致性的要求为主),从而解决主库单点问题、从库读取量大的性能问题,保证在一定量用访问时的平台性能与高可用

架构终期

架构图

高性能、高可用平台架构演变史

架构简述

架构演变到一定程度,仅通过平行的扩展或增加服务器数量可能已无法解决相关的性能问题,因此

第一,在用户访问初始阶段就会使用CDN加速技术,来提高用户的访问体验度;

第二,按照业务来拆分成不同的服务,通过拆分服务、相同服务布署多个实例的架构来达到扩展的目的,来提高一定的性能,也能保证平台的高可用性;服务拆分后,也能一定限度的解决发布问题,因为服务之间彼此独立,服务之间耦合性不强,也比较方便平时的维护;

第三,对于用户与数据库之间的瓶颈问题,考虑加上缓存技术来提高一定的访问性能与高可用性,让用户的访问流量在到达数据库之前直接过滤掉一部分,甚至一大半,从而减轻数据库访问压力,在查多写少的场景,非常适用使用缓存来提升查询服务的性能,减轻对数据库的压力。通常使用redis作为缓存服务器,redis的一些集群机制能很大程度上保证缓存服务的高可用性(Redis集群生产环境高可用方案实战过程),缓存服务故障时,还能从数据库获取信息。然后对于备份服务器也简单的做调整保证数据的完整性,一方面也能及时保障应用的高可用性;其实一些大型分布式的系统在缓存这块还是比较倾向于memcached服务(Linux系统Memcached服务介绍),比如像一些用户的登录信息同步到其它系统此种场景,一般布署在前台应用层与数据存储层中间,应对前端应用大量请求与快速响应,从而减少数据库的访问压力,也能提高用户的访问体验度。

也有一部分平台架构是采用分层的方式

前端应用层:

  • 给用户提供页面展示、查找、搜索的界面及相关的最终结果显示页面
    后端服务层:
  • 一般包括像常用的后台服务、用户管理、接口管理、支付管理等,都是给前端应用提提供服务的
    数据存储层:
  • 这个就很容易理解,像数据库、文件系统、缓存等一系列提供数据访问与存储的

所以因此也有下面的这类架构产生

高性能、高可用平台架构演变史

最终总结

高可用、高性能只能说是一个阶段、一个时期的,没有完美的架构,只有不断演变、不断完善的架构。因此,今天所说的高性能、高可用架构,可能不尽完美,但归根结底总结成一句话:“让用户的访问流量尽量靠前,一步步分层去过滤用户流量,快速响应用户的请求,从而达到比较好的用户体验”。

转载于:https://blog.51cto.com/mingongge/2112561

 OpenGL-自主高性能三维GIS平台架构与实现/第二季:实现三维GIS球体+ 高程数据章节名称DEM基础1DEM基础知识1.介绍基本的DEM知识2.什么是DEM,作用是什么2DEM数据1.如何获取/ 传统测量/激光扫描/无人机测量/ 点云数据/ 倾斜摄影2.如何使用/局部小规模(栅格数据,图片/tif),3. 组织方式4. 根据使用目的不同,介绍多种优化方法3DEM图层的实现原理14DEM数据结构定义struct  V3U3N4顶点数据的生成和计算WGS84投影计算5wgs84 投影球体被切成一个个小圆弧,一共60个投影带,分别为01,02.........60WGS的最新版本为WGS 84(也称作WGS 1984、EPSG:4326),1984年定义、最后修订于2004年。接口定义坐标转换Wgs84 数据加载6瓦片编号计算生成算法1. 经纬度到大地坐标的转换2.大地坐标到经纬度坐标转换3. 根据经纬度获取瓦片编号框架重构7智能指针重构框架1. 基类定义(所有的类继承自基类),基类派生自 std::enbale_shared_from_this2. 实现智能指针的动态转换接口3. 实现向下转换4. 已有的类实现全部使用智能指针重构5. 任务系统(多线程加载任务)8引入图层(Layer)1. 介绍图层的概念以及重要性2. 图层类实现3. 修改框架(使用图层的方式重构框架)9Layer-bug排查(绘制过程中出现错位,偶发)1. 框架重构后遇到问题(绘制结果错误)2. 瓦片索引方式发生变化,多线程中引起内存问题3. 修改索引方式,解决绘制偶发错误问题10引入数据源(TileSource)1. 数据源的作用与设计目的2. 当前存在的问题,数据调度中存在问题3. 数据源(TileSource)类实现11数据格式管理(FormatMgr)1. 数据格式管理(FormatMgr) 提出的目的,需要解决的问题2. CELLFormat基类接口抽象3. 实现几个标准格式类4. 修改框架流程,使用FormatMgr重构流程5. 扩展支持,后续支持任务格式数据加入系统12Task(任务)优化1. 任务中低耦合数据结构,目的是让Task更加的通用2. 修改任务读取代码与任务处理代码,完善处理流程DEM高程13DEM-数字高程定义1. 什么是数字化高程数据2. 当下GIS系统中有哪些常见的高程格式3. 课程体体系中使用的哪种格式4. 高程类定义以及实现,并加入到FormatMgr 管理系统中14高程瓦片数据读取1. 介绍GIS系统相关的工具(在数据转换)数据生成方面可以解决大量时间2. 自定义高程瓦片格式说明3. 自定义高程格式文件解析,并以智能对象的方式引入到系统中4. 完善框架代码,适配高程数据15高程瓦片文件的读取1. 实现基本的读取算法2. 增加格式化组件,并加入到系统中3. 配置高程图层以及高程数据源,并加载数据,验证数据正确性16瓦片数据结构重构1.顶点生成2.UV坐标计算3.面数据生成17DEM重构绘制流程1. 修改绘制数据结构,去除无用字段2. 增加Mesh类,实现光栅数据转换成三角面数据,计算UV数据,提炼接口3. 修改系统调度,实现顶点数据,UV数据,以及面数据的生成与更新4. 按需更新数据,而不是每一帧更新18DEM-数据精度问题(CPU)1. 因为瓦片数据使用大地坐标作为系统输入,造成瓦片坐标很大,单浮点数据精度不够2. 使用局部坐标的方式解决单浮点精度问题3. 调整相机参数,解决投影矩阵数据计算深度精度问题4. 修改绘制shader 实现对瓦片数据的绘制19DEM-数据精度问题(LogDepth)1. 使用对数深度(log depth )算法在GPU中 计算解决单浮点经纬计算问题2. 修改shader ,增加对(logDepth)算法支持3. 修改C++端代码,实现对shader数据的输入20DEM-数据结构优化1.当下使用CPU端数据通过接口的方式传递给GPU,速度慢2. 使用Instance 方式降低Vertex Buffer 的大小,优化渲染系统21DEM-GPU缓冲区优化1. 使用Vertex Buffer Object / Index Buffer Object  / Instance  方式优化渲染系统2. 修改绘制接口,使用DrawElementsInstanceBaseInstance方式提升系统性能内存池与对象池22瓦片生成优化/对象池1. 相机移动过程中会频繁的建立与释放瓦片,对CPU有较大的消耗2. 引入内存池,避免频繁的内存申请与释放,降低CPU时间3. 改造智能指针对象,对象释放通知到内存管理,回收对象内存23改造任务系统支持对象池1. 任务系统是一个公用模块,被多个模块使用,避免频繁的内存操作,引起的内存碎片2. 实现对象池,并应用到任务模块法线计算24法线计算1. 修改现有顶点结构,增加法线支持2. 修改shader,增加法线顶点输入,使用平行光光照模型3. 修改绘制流程,支持光照计算,使用探照灯作为光源输入25顶点法线计算/共享法线计算1. 增加数据结构保存顶点数据被多个面共享的次数2. 计算面法线,并累加到顶点法线中3. 根据顶点被面共享的次数做平均法线计算4. 修改流程,按需更新法线数据26法线数据压缩1. 法线数据使用3 * float 数据存储,大大的增加了系统的数据2. 实现算法,将3 * float 数据压缩成4字节数据3. 改造绘制代码,支持压缩数据输入27GPU中计算产生法线数据(去掉CPU中计算)1. 引擎支持 Geometry Shader 阶段2. 编写 Geometry Shader,实现法线计算系统功能优化28重构CPU拾取流程1. 当下的拾取流程,只支撑二维数据拾取,无法准群的拾取三维数据2. Terrain中增加拾取接口,输入射线,输出拾取到顶点数据29绘制拾取结果1. 增加一个绘制点的方法,实现绘制代码2. 修改shader,增加logdepth3. 调试代码,花费了很多时间排查错误,最总排查到是因为uniform参数笔误写错造成。30任务系统完善,避免任务队列无线膨胀1. 任务系统中,没有限制队列的大小,生产者的能力远大于消费者的能力,造成任务队列膨胀2. 处理办法,限制生产者的生产能力,而不是限制任务队列大小(这种方式会造成业务逻辑异常复杂)3. 使用sleep休眠方式(这种方式是严重错误的)31如何避免瓦片数据抖动1. 产生瓦片抖动的原因 ? 分裂算法与回退算法中间没有过度2. 引入过度流程,避免内存抖动,参数因子是一个重要的数据,需要谨慎使用3. 有必要结合瓦片自身数据动态计算参数因子32瓦片数据管理-fepk文件格式支持-全球数据加载1. 支持fepk文件格式,增加fepk读取组件,适配fepk文件2. fepk管理数据方式:一般情况选择全球前10级别作为基础级别,因数据量不大(1G)左右,后续以8级作为基础级别,全球19级别数据被划分为 2^8 * 2^7(512 * 256)个块。每个块中包含了256 * 256 张小瓦片33fepk高程数据读取 34高程分裂处理当瓦片没有高程数据,那么子节点以及其他后代节点该如何共享父节点的数据35lesson-734-高程瓦片分裂处理(2)-算法实现高程数据分裂算法实现实现对高程数据的切分,并对特殊数据进行处理36高程瓦片分裂处理(3)-问题排查 37高程瓦片分裂处理(4)-(后代节点更新问题)当一个瓦片高程数据更新后,他的儿子节点,孙子节点...该如何处理?38瓦片视锥裁剪错误高程数据更新后,没有技术计算瓦片包围盒信息,造成包围盒错误,进而引视锥计算错误39http支持1.引入三方库 Libcurl2.http类封装,支持http读取数据40fepk.server使用 生成三维地球41改造四叉树-统一使用经纬度输入42地形网络生成算法重构 43引入球体坐标系 44使用球体坐标改造瓦片 45多图层(加载标签数据) 课时截图:镜头拉近后,显示细节数据加载矢量SHP国界线数据:加载矢量三维白膜数据截图高程数据加载点云数据 加载倾斜摄影数据 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值