车联网上云最佳实践(三)

本文涉及的产品
云服务器 ECS,每月免费额度280元 3个月
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介:

三、云上对标架构及技术详解

我们对传统IDC应用架构进行分析之后,我们发现之前的系统架构存在一些不合理的地方导致了很多的痛点,为了解决这些痛点我们最终考虑上云。开始思考怎样利用云上产品来解决目前遇到的痛点。例如

  •       为了解决我们自建IDC底层基础设施可靠性差的问题,我们改用云计算服务,基础设施可靠性,异地容灾,数据备份,数据安全等问题再也不用担心
  • 为了解决存储性能瓶颈以及用户访问体验问题,我们改用云上对象存储OSS服务+CDN;
  • 为了解决单台数据库性能扩展瓶颈,我们改用云上的DRDS分布式关系数据库;
  • 为了解决大规模的车机上报而导致数据写入延迟问题我们改用云上IOT套件+HiTSDB;
  • 为了解决日常以及节假日流量高峰的问题,我们改用云上弹性伸缩服务+按量付费,以最低的成本完美解决日常及节假日流量高峰;
  • 为了解决大数据存储瓶颈以及降低大数据开发分析工作难度,我们改用云上MaxCompute + HBase;
  • 为了解决运维自动化问题以及提高运维工作效率,我们改用云上codepipeine+云监控+日志服务+容器服务;
  • 为了解决安全防御瓶颈,我们改用云上云盾+DDOS高防IP + web应用防火墙+堡垒机;
  • 为了解决负载均衡以及网络扩容瓶颈,我们改用云上SLB;
  • 为了降低上云迁移复杂性,我们改用云上VPC虚拟专用网络,IP地址可以和原来保持不变;
  • 为了解决数据迁移的稳定性和便捷性,我们采用阿里云数据迁移工具DTS

我们云上新的应用架构即会兼容部分老应用架构的特性,同时会采用云上新技术和云上产品来解决我们曾经的痛点和瓶颈。并且云上新架构需要满足未来2-3年的业务发展规划,能够支撑千万级用户规模的应用系统架构。下图为云上应用架构图。

36a2bad860d869edc2c604a27cb491bfb4c4f746


1云上对标架构介绍

 

1.1安全:

安全这块以前IDC机房的时候防范能力比较弱。为了解决安全防御瓶颈,我们改用云上云盾+DDOS高防IP + web应用防火墙+堡垒机;

 

可以通过配置DDoS高防IP,将攻击流量引流到高防IP,确保源站的稳定可靠。DDoS攻击防护峰值带宽 20 Gbps ~ 300 Gbps 。同时,提供按天弹性付费方案,按当天攻击规模灵活付费。

云盾Web应用防火墙可以防御SQL注入、XSS跨站脚本、常见Web服务器插件漏洞、木马上传、非授权核心资源访问等OWASP常见攻击,并过滤海量恶意CC攻击,避免网站资产数据泄露,保障网站的安全与可用性。

关于DDOS高防IP和web应用防火墙产品介绍请详见文章附录第7.1&第7.2小结。

 

另外选择用堡垒机来替换原来的开源堡垒机,相比开源的产品,阿里云堡垒机多了一些审计合规,高效易用,多协议支持,追溯回放等功能。

 

1.2负载均衡集群:

为了解决负载均衡以及网络扩容瓶颈,我们改用云上SLB负载均衡。阿里云的SLB负责均衡提供四层(TCP协议和UDP协议)和七层(HTTP和HTTPS协议)的负载均衡服务。四层采用开源软件LVS实现负载均衡,并根据云计算需求对其进行了个性化定制。七层采用Tengine实现负载均衡。Tengine是由淘宝网发起的Web服务器项目,它在Nginx的基础上,针对有大访问量的网站需求,添加了很多高级功能。更多关于阿里云负载均衡介绍请详见文章附录第2.2小结。

 

负载均衡实例规格选型:

根据当前业务量来看五百万用户,最高峰期间并发最大连接为50万,推荐使用

性能保障型规格5(slb.s3.medium)最大连接数50w,每秒新建连接数5w,QPS支持3w。完全满足当下的企业需求,如果后续业务和用户规模继续增长,仍然可以在线扩容到更高级别规格的SLB实例。如果未来达到千万级用户规模,需要大于100万规格的实例可以联系阿里云客户经理开通。

176cc9ff24d3f5d940cd3909d8b0c9ea863616e0

1.3应用服务器集群:

应用服务器采用阿里云ECS云服务器,来部署应用环境。之前提到运行环境主要为JAVA环境和PHP环境,还有少部分Node.js环境。

Java环境:采用Centos7 + JDK1.7 + Tomcat7

PHP环境:采用Centos7 + PHP5.6.11

Node.js环境:采用Centos7 + Node8.9.3

有2种方式快速构建应用运行环境:

1)   购买ECS服务器后安装操作系统,然后手动部署应用环境,最后将应用环境构建成新的系统镜像。

2)   购买ECS云服务器后直接选择云市场的已经封装好的应用环境镜像即可。

356eb0418bb0601450e7a716d7b3498cb604db6a



产品选型

ECS产品根据业务场景和使用场景,ECS实例可以分为多种规格族。同一业务场景下,还可以选择新旧多种规格族。同一个规格族里,根据CPU和内存的配置,可以分为多种不同的规格。ECS实例规格定义了实例的CPU和内存的配置(包括CPU型号、主频等)这两个基本属性。根据此前车联网行业特性来看,前端web应用推荐ecs.c5.xlarge(4核8G)规格实例,而后端应用推荐ecs.g5.xlarge(4核16G)规格实例。

eefe2ab32bcdc50d0abe0cebd0d9869e01f7e76c

7438d02b56b2e3122cd9176aecc28f1e3fb9ca18

1.4分布式服务集群:

分布式服务集群,延用Dubbo + ZooKeeper分布式服务框架。采用7台8核16G SSD磁盘200G ecs.c5.2xlarge规格ECS实例用于构建zookeeper集群。Zookeeper集群节点必须是奇数,因为在zookeeper集群中只要有超过一半的机器是正常工作的,那么整个集群对外就是可用的。

 

1.5缓存集群:

缓存集群采用阿里云数据库Redis版,传统自建Redis数据库通常存在集群节点扩容复杂,管理维护难等问题。所以我们改用云上数据库 Redis 版来替代,它具有性能卓越,弹性扩容,数据安全性高,可用性高,秒级监控,简单易用等优势。云数据库Redis版支持按量付费和包年包月两种模式,按量付费可转为包年包月模式,反之则不可以。可根据自己的需求自主选择更多关于云数据库Redis介绍请详见文章附录第3.2小结。

 

1.6消息队列集群:

消息队列采用阿里云的消息队列kafka服务,因为之前开源的kafka消息队列也经常遇到各种问题,也没有相应的能力去修复bug,选择阿里云的消息队列服务之后就不用担心这些问题,因为阿里云有一支专家团队在维护它的日常稳定运行,如出现官方bug他们有能力第一时间修复bug。更多关于阿里云消息队列kafka介绍请详见文章附录第8.2小结。

 

1.7流计算集群:

云上流计算采用阿里云的流计算服务,相较于其他流计算产品,阿里云流计算提供一些极具竞争力的产品优势,用户可以充分利用阿里云流计算提供的产品优势,方便快捷的解决自身业务实时化大数据分析的问题。产品优势,例如强大的实时处理能力、托管的实时计算服务、良好的流式开发体验、低廉的人力和集群成本。更多关于阿里云流计算介绍请详见文章附录第6.1小结。

de131b406fc8fdae3d198bd7f6bf94635b1d3deb

1.8数据存储集群:

MySQL集群:采用的是阿里云数据库RDS之MySQL版

阿里云数据库 MySQL 版是基于 Alibaba 的 MySQL 源码分支,经过双 11 高并发、大数据量的考验,拥有优良的性能和吞吐量。除此之外,阿里云数据库 MySQL 版还拥有经过优化的读写分离、数据压缩、智能调优等高级功能。当前 RDS for MySQL 支持 5.5、5.6 和 5.7 版本。请详见文章附录第3.1小结。

RDS与自建数据库对比优势:

综合性能对比

 

云数据库RDS

自购服务器搭建数据库服务

服务可用性

99.95%

需自行保障, 自行搭建主从复制,自建RAID等。

数据可靠性

99.9999%

需自行保障,自行搭建主从复制,自建RAID等。

系统安全性

防DDoS攻击,流量清洗;及时修复各种数据库安全漏洞。

自行部署,价格高昂;自行修复数据库安全漏洞。

数据库备份

自动备份

自行实现,但需要寻找备份存放空间以及定期验证备份是否可恢复。

软硬件投入

无软硬件投入,按需付费

数据库服务器成本相对较高,对于SQL Server需支付许可证费用。

系统托管

无托管费用

每台2U服务器每年超过5000元(如果需要主从,两台服务器需超过10000元/年)。

维护成本

无需运维

需招聘专职DBA来维护,花费大量人力成本。

部署扩容

即时开通,快速部署,弹性扩容,按需开通。

需硬件采购、机房托管、部署机器等工作,周期较长。

资源利用率

按实际结算,100%利用率。

考虑峰值,资源利用率很低。

 

成本对比

 

云数据库RDS

自购服务器搭建数据库服务

硬件

费用

和备

品配

件消

以如下实例规格为例:

内存1200MB、存储空间50G(IOPS能力可达到600)的费用是2040元/年。

l  至少需要2台据库集群,每台IOPS能力达到600的服务器费用大约是6000元。

l  1台用于连接前端Web服务器的内网交换机(便宜的1U非网管交换机为1000元左右),后期硬件损坏和更换至少还要消耗30%费用。

l  硬件花费:(6000 × 2 + 1000)× 130% = 16900元。

l  每年费用:16900元/3 = 5633元(硬件按照3年折旧计算)

机房

托管

费用

服务商负责,无需付费。

1U机柜空间托管费用为3000元/年,共有2台1U服务器和1台1U内网交换机需要计费。

机房托管费用:3000 × 3=9000元

带宽

费用

同一地域内,ECS和RDS可以通过内网互通,且不收取费用。但若在不同地域,ECS和RDS可以通过外网互通,需收取外网流量费用,详细收费标准请参见云数据库RDS详细价格信息。

这里假设只用于内网,不产生公网费用。因为各个运营商的网络价格不是很透明(注:在实际使用过程中网络带宽也是一笔不小的费用。)

数据

库运

维工

程师

费用

数据库维护由服务商负责,无人员成本。

                                             

1个初级DBA工程师月薪至少5000/月,如果按照当前项目占用该工程师30%的工作量:

人员成本:5000 × 12× 30% = 18000元

每年

总费

2040元/年

 

32633元/年

 

 

HBase集群:采用的是阿里云数据库HBase版

传统架构中的MongoDBS用来存储车辆上报的原始数据的,这些数据通常情况下写多读少,原始数据的保存可以有利于特殊情况对问题的追溯。或者是数据丢失的情况下可以用原始数据来进行弥补。原来MongoDB集群在达到一定规模之后性能出现断崖下降,因为对MongoDB掌握不够深,没有正确使MongoDB导致。这里改用云上数据库HBase版来替换原来的MongoDB集群。HBase的高并发大数据量等特性非常适合海量数据存储,业务大屏,安全风控,搜索等场景。

HBase主要优势有两点:1)扩展性要强,HBase是专门的列式数据库,具有高并发,低时延的处理能力,支持数据从200G~10PB都适合。数据存储在HDFS,默认具备多副本可靠性和自动扩展能力。2)HBase是天生的hadoop生态系统中的组件,选择HBase,就是选择整个Hadoop生态。云HBase自带的Phoneix组件,支持SQL能力,二级索引等,非常适合IoT实时业务,并且支持带少量更新的TP操作。HBase和MapReduce,spark天然的结合,同一份数据,支持实时业务的同时,可以完成大数据的分析,以及还有时序组件OpenTSDB等。更多关于云数据库HBase介绍请详见文章附录第3.4小结。

 

         为什么我们不自建HBase而选择云数据库HBase呢?云HBase和自建HBase对比有哪些优势呢?

 

云HBase

自建HBase

产品

阿里巴巴集团5年使用

全托管、SLA

开源软件、半托管、无SLA

双活

支持双活

不支持

性能

性能提升50%-300%

没有优化

专业运维

7*24小时专家运维

缺乏

产品打通

CDP\Blink\ODPS

打通

不支持

成本

综合成本低,而且部署灵活

(冷热分离,计算存储分离多种产品形态)

成本高,而且部署不灵活

 

自建和服务更多的对比 ,可以参考以下文章:

https://yq.aliyun.com/articles/176102?spm=5176.124785.838505.1.1ba352c0NSfA6X

 

Elasticsearch集群:采用阿里云的Elasticsearch

传统自建Elasticsearch集群存在性能不足,集群节点扩容复杂,管理维护难度大等问题,因此我们改用云上Elasticsearch服务,它具有丰富的预置插件(IK Analyzer,pinyin Analyzer,smart Chinese Analysis Plugin,Mapper Attachments Type plugin等等),还包括集成X-pack插件提供企业级权限管控,实时监控等强大功能。它的特点和优势如下:

  • 分布式的实时文件存储,每个字段都被索引并可被搜索
  • 分布式的实时分析搜索引擎
  • 商业版X-pack插件,提供企业级权限管控、实时系统监控等强大服务
  • 可弹性扩展到上百台服务器规模,处理PB级结构化或非结构化数据
  • 支持IK analyzer插件
  • Elastic官方技术支持团队7*24小时技术支持

1.9文件存储集群:

            文件存储:采用阿里云对象存储OSS

原来自建的NFS文件系统,在扩展和访问速度方面随着文件数量的增加响应也越来越慢,这一块采用阿里云的OSS+CDN解决方案,应用也需要进行小小的改造。

文件系统迁移改造方案请看2.2章节。

阿里云对象存储服务(Object Storage Service,简称 OSS),是阿里云提供的海量、安全、低成本、高可靠的云存储服务。它具有与平台无关的RESTful API接口,能够提供99.999999999%(11个9)的数据可靠性和99.99%的服务可用性。可以使用阿里云提供的API/SDK接口或者OSS迁移工具轻松地将海量数据移入或移出阿里云OSS。数据存储到阿里云OSS以后,推荐选择标准类型(Standard)的阿里云OSS服务作为移动应用、大型网站、图片分享或热点音视频的主要存储方式,也可以选择成本更低、存储期限更长的低频访问类型(Infrequent Access)和归档类型(Archive)的阿里云OSS服务作为不经常访问数据的备份和归档。更多关于阿里云对象存储服务OSS介绍请详见文章附录第4小结。

1.10 大数据计算平台

      大数据计算平台:采用阿里云大数据计算服务

智能车联网平台每天会采集海量车行驶数据,例如车辆发动机状态,驾驶行为,油耗,公里数,行驶轨迹等等,我们需要对这些海量数据进行加工和分析。例如用户每天行驶里程统计,油耗统计,用户驾驶行为月报告等等。因初期数据量相对较小,使用Kettle进行抽取数据等工作,ETL的工作大部分在MySQL数据仓库中完成。多种数据源使用Presto(集群)作为查询中间键进行相应的数据分析。但随着业务的疯狂增长,数据表单表达到数亿后,磁盘容量达几百GB时,数据要求的复杂度逐步提升,使用MySQL作为基础数据仓库的基石已经不足以应付,常出现查询响应时间等待过长,甚至内存崩溃导致执行失败的情况,极大的影响了工作效率。所以云上我们改用阿里云MaxCompute大数据计算服务来构建我们公司大数据开发和分析平台。MaxCompute能够为我们提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决海量数据计算问题,有效帮助我们公司降低成本,并保障数据安全。Dataworks则提供了一站式的数据同步,数据开发,数据管理和数据运维等功能。更多关于阿里云大数据计算服务介绍请详见文章附录第6.2小结。

 

1.11运维管控集群:

之前的传统运维,基本都是靠人肉运维,脚本运维,运维自动化程度很低,导致故障频发,故障定位难,我们的运维同学大量时间花在了重复的升级发布工作上,花在了填坑以及解决故障上,长此以往运维同学自身发展受限,信心受挫,人员流失比例高的恶性循环的结果。我们迫切希望这种状况可以得到较好的解决。对比之前大量采用开源的监控工具相比,大部分阿里云的产品本身就自带web控制台,也有一些比较实用的运维管控产品,例如云监控,堡垒机,数据管理,数据迁移,容器服务,域名等等。以前的运维痛点可以通过阿里云的运维产品可以很好的得到解决。

日志管理:采用阿里云日志服务解决日志收集,日志分析,日志搜索等问题。

阿里云日志服务是针对日志类数据的一站式服务,在阿里巴巴集团经历大量大数据场景锤炼而成。无需开发就能快捷完成日志数据采集、消费、投递以及查询分析等功能,提升运维、运营效率,建立 DT 时代海量日志处理能力。具有全托管,实时性强,生态丰富,完整API等特点。更多关于阿里云日志服务介绍请详见文章附录第5.7小结。

 

弹性扩容:采用阿里云弹性伸缩ESS,低成本解决日常以及节假日流量高峰问题。

在车联网行业中有个比较明显的行业特性就是早晚高峰是平时流量的3倍甚至更高,但是平常要应付这么高并发的流量意味着资源投入也要3倍以上。在传统IDC架构中,我们通常是按照平常最高峰流量的1.2倍(1.2倍是为应对特殊情况预留的buffer)来准备相应的服务器资源,在平时资源闲置比较明显,资源利用率不到30%,意味着平常可能100台应用服务器就足够了,但是为了应对高峰流量不出问题我们需要准备360台服务器应对6个小时的高峰流量,其余18小时可能只需要100台服务器。为了确保系统稳定,提升用户体验,当时我们只能投入比平时多几倍的服务器资源。所以在云上我们采用阿里云弹性伸缩服务,它是一种根据业务需求和策略,自动调整其弹性计算资源的管理服务。在满足业务需求高峰增长时无缝地增加ECS实例,并在业务需求下降时自动减少ECS实例以节约成本。更多关于阿里云弹性伸缩服务介绍请详见文章附录第1.2小结。

 

         域名管理:采用阿里云域名服务,一站式解决域名购买,管理,备案等问题。

         以前的老万网被阿里云收购之后,变更为阿里云域名服务,它集域名注册、交易、解析、监控和保护为一体的综合域名管理平台。更多关于域名服务介绍请详见文章附录第5.6小结。

 

持续集成:传统应用升级发布主要靠的人肉升级或者脚本升级,后来尝试过利用开源的Jenkins+docker方式构建一个简单的应用发布系统,我们希望到云上可以继续保持这种发布方式,所以改用云上CodePipeline,阿里云CodePipeline是一款提供持续集成/持续交付能力,并完全兼容Jenkins的能力和使用习惯的SAAS化产品。它无需运维,开箱即用,全量兼容Jenkins插件,支持ECS,容器服务持续部署,快速上手。更多关于codepipeline介绍请详见文章附录第5.9小结。

 

 

         容器管理:采用阿里云容器服务,一站式解决容器生命周期管理及集群管理问题。

阿里云容器服务提供高性能可伸缩的容器应用管理服务,支持用 Docker 和 Kubernetes进行容器化应用的生命周期管理,提供多种应用发布方式和持续交付能力并支持微服务架构。容器服务简化了容器管理集群的搭建工作,整合了阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器运行环境。阿里云容器服务可以提供一站式容器生命周期管理以及集群管理。更多关于阿里云容器管理介绍请详见文章附录第5.5小结。

 

统一配置:采用阿里云应用配置管理,传统IDC架构中我们的应用因为微服务架构的需要全部采用了的统一配置管理,将配置中心化管理,保存在zookeeper当中,通过一个web前端进行配置管理。应用通过本地客户端向服务端请求配置。这样做的好处是应用配置可以集中存放,统一配置,方便管理。但是我们的web配置管理中心提供的功能比较简单,甚至不具备权限管理,配置快照,备份和恢复等功能。在云上我们改用阿里云的应用配置管理ACM产品。云上应用配置管理是一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。基于该应用配置中心产品,可以在微服务、DevOps、大数据等场景下极大地减轻配置管理的工作量,增强配置管理的服务能力。阿里云ACM 是分布式系统的配置中心。通过提供配置变更、配置推送、历史版本管理、灰度发布、配置变更审计等配置管理工具,ACM 帮助集中管理所有应用环境中的配置,降低分布式系统中管理配置的成本,并降低因错误的配置变更带来可用性下降甚至发生故障的风险。更多关于阿里云应用配置管理ACM介绍请详见文章附录以及官方网站。

 

监控系统:采用阿里云监控服务,传统IDC架构中我们的监控系统是自建的zabbix监控系统,随着公司业务快速发展,监控项也急剧增加,由最初的500个监控项增加到3w个监控项,监控系统数据库性能跟不上,查询很慢,告警延迟和误报的现象逐渐增多,监控需求越来越多样化,定制化。传统监控系统已经不能满足未来业务高速发展。 所以我们云上改用云监控,云监控是一项针对阿里云资源和互联网应用进行监控的服务。云监控服务可用于收集获取阿里云资源的监控指标,探测互联网服务可用性,以及针对指标设置警报。云监控对用户提供Dashboard、站点监控、云产品监控、自定义监控和报警服务。更多关于云监控介绍请详见文章附录第5.1小结。

    

 

         数据可视化:采用DataV, 解决了运维大屏,监控大屏没有UI设计问题

         企业多多少少有些大屏,在公司接待参观考察工作时展示企业形象,企业运营,以及系统运行情况等。为了提升企业形象,有必要针对数据可视化部分进行美化。阿里云的DataV 可以帮助非专业的工程师通过图形化的界面轻松搭建具有专业水准的可视化应用,让更多的人看到数据可视化的魅力。DataV 提供了丰富的可视化模板,极大程度满足会议展览、业务监控、风险预警、地理信息分析等多种业务的展示需求。更多关于阿里云DataV数据可视化介绍请详见文章附录第5.2小结。

 

         数据库运维:采用阿里云数据管理DMS,解决数据库运维管理问题

阿里云数据管理支持MySQL、SQL Server、PostgreSQL、MongoDB、Redis等关系型数据库和NoSQL的数据库管理,同时还支持Linux服务器管理。它是一种集数据管理、结构管理、访问安全、BI图表、数据趋势、数据轨迹、性能与优化和服务器管理于一体的数据管理服务。更多关于阿里云数据管理DMS介绍请详见文章附录第5.8小结。

 

1.12 尝试新产品解决老问题

问题1:海量车机设备的接入导致网络延时高,设备管理困难,安全性差

解决方案:阿里云物联网套件(iot套件),解决大规模车机管理,数据上报问题。

物联网套件是阿里云专门为物联网领域的开发人员推出的一站式设备管理平台。性能强大的IoT Hub方便设备和云端稳定的进行双向通信;全球多节点的部署让全球设备都可以低延时与云端通信;多重的防护能力保障设备云端安全;功能丰富的设备管理能力帮助用户方便进行远程维护设备;稳定可靠的数据存储能力方便海量设备数据存储和实时访问。物联网套件还提供规则引擎与阿里云众多云产品打通,用户通过规则引擎只需在web上配置规则即可实现数据采集+数据计算+数据存储等全栈服务,灵活快速的构建物联网应用。更多关于阿里云IOT套件介绍请详见文章附录。

c248dffc1ea4aff36d56b0e5fd8f2512ae54c0c2

问题2:车联网大多应用场景对数据实时性要求非常高,但是目前在数据采集过程中由于数据库写入性能不够,经常出现大量数据写入延迟情况。

 

解决方案:阿里云高性能时间序列数据库HiTSDB,解决海量数据写入延迟问题。

为什么说时间序列数据库能解决呢?

据有关机构测试发现一辆联网汽车每小时能收集25GB数据常规数据库在设计之初并非处理这种规模的数据,关系型数据库处理大数据集的效果非常糟糕;NoSQL数据库可以很好地处理规模数据,但是它比不上一个针对时间序列数据微调过的数据库。相比之下,时间序列数据库(可以基于关系型数据库或NoSQL数据库)将时间视作一等公民,通过提高效率来处理这种大规模数据,并带来性能的提升,包括:更高的容纳率(Ingest Rates)、更快的大规模查询(尽管有一些比其他数据库支持更多的查询)以及更好的数据压缩。有兴趣了解更深层次原因的朋友可以参考这个链接:

http://www.infoq.com/cn/news/2017/07/Why-time-series-database

https://qz.com/344466/connected-cars-will-send-25-gigabytes-of-data-to-the-cloud-every-hour/

 

阿里云高性能时间序列数据库 (High-Performance Time Series Database , 简称 HiTSDB) 是一种高性能,低成本,稳定可靠的在线时序数据库服务;提供高效读写,高压缩比存储、时序数据插值及聚合计算,广泛应用于物联网(IoT)设备监控系统 ,企业能源管理系统(EMS),生产安全监控系统,电力检测系统等行业场景。

HiTSDB 提供百万级时序数据秒级写入,高压缩比低成本存储、预降采样、插值、多维聚合计算,查询结果可视化功能;解决由于设备采集点数量巨大,数据采集频率高,造成的存储成本高,写入和查询分析效率低的问题。后续文章会详细介绍HiTSDB性能测试内容。更多关于HiTSDB介绍请详见文章附录第。

 

问题3:车联网行业是典型的大数据行业,有大量的大数据分析应用场景需求,但是自建大数据平台成本高,维护困难,大数据人才不好招。

解决方案: MaxCompute + Dataworks + 云数据库HBase版

阿里云大数据计算服务(MaxCompute,原名 ODPS)是一种快速、完全托管的 GB/TB/PB 级数据仓库解决方案。MaxCompute 提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决海量数据计算问题,有效降低企业成本,并保障数据安全。

同时,DataWorks 和 MaxCompute 关系紧密,DataWorks 为 MaxCompute 提供了一站式的数据同步,任务开发,数据工作流开发,数据管理和数据运维等功能,帮助企业专注于数据价值的挖掘和探索。普通开发人员也可以胜任大数据开发任务。

云数据库 HBase 版(ApsaraDB for HBase)是基于 Hadoop 且100%兼容HBase协议的高性能、可弹性伸缩、面向列的分布式数据库,轻松支持PB级大数据存储,满足千万级QPS高吞吐随机读写场景。阿里集团在10年开始研究HBase并使用在生产之中,目前阿里集团有10000台左右的HBase机器,数百个集群,服务数百个业务。是一款久经沙场的大数据产品。

 

       

        问题4:单机MySQL数据库遇到IO性能瓶颈和容量扩容瓶颈,如果业务和用户规模继续增长将面临单机数据库扩展困难。

        解决方案:阿里云分布式关系型数据库服务DRDS

        阿里云分布式关系型数据库服务专注于解决单机关系型数据库扩展性问题,具备轻量(无状态)、灵活、稳定、高效等特性,是阿里巴巴集团自主研发的中间件产品。DRDS 兼容 MySQL 协议和语法,支持分库分表、平滑扩容、服务升降配、透明读写分离和分布式事务等特性,具备分布式数据库全生命周期的运维管控能力。DRDS 主要应用场景在大规模在线数据操作上,通过贴合业务的拆分方式,将操作效率提升到极致,有效满足用户在线业务对关系性数据库要求。DRDS提供了丰富的功能:

l  分库分表

支持 RDS/MySQL 的分库分表,在创建分布式数据库后,只需选择拆分键,DRDS 就可以按照拆分键生成拆分规则,实现数据水平拆分。

l  透明读写分离

通过使用 RDS 只读实例或者 MySQL 备机实现读写分离,帮助应用解决事务、只读实例或者备机挂掉、指定主备访问等细节问题,对应用无侵入,在 DRDS 控制台即可完成读写分离相关操作。

l  数据存储平滑扩容

当出现数据存储容量和访问量瓶颈时,DRDS 支持在线存储容量扩展,扩容无需应用改造,扩容进度支持可视化跟踪。

l  服务升降配

DRDS 实例可以通过改变资源数量实现服务能力的弹性扩展。

l  分布式运维指令集

DRDS 提供独有分布式数据库运维指令集,如 SHOW SLOW、TRACE、SHOW NODE 等指令,有助于快速发现和定位问题。

l  全局唯一数字序列

DRDS 支持分布式全局唯一且有序递增的数字序列。满足业务在使用分布式数据库下对主键或者唯一键以及特定场景的需求。

l  数据库账号权限体系

DRDS 支持类单机 MySQL 账号和权限体系,确保不同角色使用的账号操作安全。

l  分布式事务

DRDS 支持分布式柔性事务,保证分布式数据库数据一致性。

l  监控报警

 DRDS 支持对核心资源指标和数据库实例指标的实时监控和报警,如实例 CPU、网络 IO、活跃线程等,帮助实时发现资源和性能瓶颈。

        更多关于阿里云分布式关系数据库DRDS介绍请详见文章附录第3.5小结。

 

2数据迁移策略

2.1 数据库迁移策略

数据库迁移是整个上云过程中最重要的一环,难度也最大,因为我们在迁移的时候要尽可能的减少业务本身的影响,最好是不停机不中断现有业务。需要制定非常详细的计划和迁移策略:

l  迁移工具:推荐阿里云数据传输服务DTS

DTS 是阿里云提供的一种支持 RDBMS(关系型数据库)、NoSQLOLAP 等多种数据源之间数据交互的数据流服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、异地多活(单元化)、跨境数据同步、实时数据仓库、查询报表分流、缓存更新、异步消息通知等多种业务应用场景,助构建高安全、可扩展、高可用的数据架构。

DTS 支持多种数据源类型,例如:

Ø  关系型数据库:OracleMySQLSQLServerPostgreSQL RDS For PAASDRDSPetaDataOceanBase

Ø  NoSQLMongoDBRedis

Ø  OLAPODPSADS、流计算。 

 

l  迁移时间:推荐在业务流量最低峰时段例如每天0点至5点

 

l  迁移方法:

一般情况我们的业务数据库都是有主备的,那么选择从数据库作为源数据库对云上数据库进行同步,这样做的目的是为了减少对主库的影响,有条件的话选择单独的从数据库专门用作对云上数据库进行全量同步迁移。完了之后再切换到主数据库开启增量数据同步(利用DTS可以轻松完成数据库的增量同步)。这样就可以保证线下数据库和线上数据库的一致性了。具体迁移步骤请参考官方文档:

https://help.aliyun.com/document_detail/35732.html?spm=a2c4g.11186623.6.638.5X8oE7

 

2.2 文件系统迁移策略

之前采用的是自建NFS文件系统用于存储图片和文件。随着文件越来越多,图片访问速度越来越慢,搬到云上之后,可以利用阿里云的OSS和CDN服务,构建如下的web端直传OSS存储方案,架构如下:


926504d44d19c50861b6150ff402ee31ed57e713

用户的请求逻辑:

1)   用户向应用服务器取到上传policy和回调设置。

2)   应用服务器返回上传policy和回调。

3)   用户直接向OSS发送文件上传请求。

4)   等文件数据上传完,OSS给用户Response前,OSS会根据用户的回调设置,请求用户的服务器。

5)   如果应用服务器返回成功,那么就返回用户成功,如果应用服务器返回失败,那么OSS也返回给用户失败。这样确保了用户上传成功的照片,应用服务器都已经收到通知了。

6)   应用服务器给OSS返回。

7)   OSS将应用服务器返回的内容返回给用户。

a601a00e47efa5238e49fa0b3bbd5a34b4f26ef2


利用阿里云OSS存储代替原来的自建NFS文件系统,优势很明显:

对比项

对象存储OSS

自建服务器存储

可靠性

- 服务设计可用性不低于99.95%。

- 规模自动扩展,不影响对外服务。

- 数据设计持久性不低于99.999999999%。

- 数据自动多重冗余备份。

- 受限于硬件可靠性,易出问题,一旦出现磁盘坏道,容易出现不可逆转的数据丢失。

- 人工数据恢复困难、耗时、耗力。

安全

- 提供企业级多层次安全防护。

- 多用户资源隔离机制,支持异地容灾机制。

- 提供多种鉴权和授权机制及白名单、防盗链、主子账号功能。

- 需要另外购买清洗和黑洞设备。

- 需要单独实现安全机制。

网络

- 多线BGP骨干网络,无带宽限制,上行流量免费。

- 无需运维人员与托管费用,0成本运维。

- 存储受硬盘容量限制,需人工扩容。

- 单线或双线接入速度慢,有带宽限制,峰值时期需人工扩容。

- 需专人运维,成本高。

数据处理能力

- 提供图片处理、音视频转码、内容加速分发、鉴黄服务、归档服务等多种数据增值服务,并不断丰富中。

- 需要额外采购,单独部署。

成本

包年包月或者按量付费,按需购买,价格低廉;以标准型存储为例费用为0.12元/GB/月;请求费用0.01元/万次;外网流量费用:0.25元/GB,CDN回源流出流量:0.15元/GB;

需要购买专门存储硬软件设备,初次投入成本非常高。少则数十万元,多则上百万甚至是上千万的投入。

 

OSS服务 配合CDN 服务一起使用,则可以加速文件存储和访问速度,提升用户访问体验。

CDN的工作原理就是将源站的资源缓存到各地的边缘节点服务器(CDN节点)上,用户请求访问和获取资源时,就近调用CDN节点上缓存的资源。这种分布式数据传输方式,使得用户请求的资源不需要都回源站获取,从而避免网络拥塞、分担源站压力,保证用户访问资源的速度和体验。

使用CDN后的http请求处理流程如下图

aaf9a0db9eee891d0c6074af056ff722f355ad65

阿里云CDN在全球拥有1300+ 节点,国内完整覆盖 34 个省级区域,大量节点位于省会等一线城市。海外覆盖70 多个国家和地区。阿里云所有节点均接入 万兆 网卡;具备 90 Tpbs 带宽能力储备。单节点存储容量达 40 TB-1.5 PB,带宽负载达到 40 Gbps-200 Gbps


相关实践学习
Docker镜像管理快速入门
本教程将介绍如何使用Docker构建镜像,并通过阿里云镜像服务分发到ECS服务器,运行该镜像。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
4月前
|
弹性计算 安全 关系型数据库
阿里云上云解决方案参考,多种技术与行业解决方案助力企业上云
对于初次上云的用户来说,参考一份适合自己行业的解决方案可帮助自己快速上手,并根据方案的内容选择适合自己的云产品进行方案部署。阿里云发布各种解决方案是基于众多客户上云的成功案例萃取而成的最优化企业上云指导,涵盖前端Web和移动应用程序开发、网站搭建、网络组网、数据库、迁云等众多上云项目。本文为大家汇总了一些上云解决方案的详情入口,方便大家快速查询与自己场景相符的解决方案。
阿里云上云解决方案参考,多种技术与行业解决方案助力企业上云
|
11月前
|
监控 Kubernetes Cloud Native
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.2 云原生应用架构优势(下)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.2 云原生应用架构优势(下)
117 0
|
11月前
|
消息中间件 运维 Kubernetes
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.2 云原生应用架构优势(上)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.2 云原生应用架构优势(上)
132 0
|
11月前
|
消息中间件 JSON 运维
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(3)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(3)
|
11月前
|
数据库
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(4)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(4)
|
11月前
|
SQL Oracle 安全
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(5)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(5)
|
11月前
|
运维 Dubbo Java
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(1)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(1)
|
11月前
|
运维 负载均衡 Kubernetes
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(2)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(2)
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.3 业务迁移上云最佳实践(2)
|
11月前
|
存储 安全 云计算
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.1 上云背景介绍
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.1 上云背景介绍
|
11月前
|
大数据 云计算
在线教育行业云上技术服务白皮书-在线教育行业云计算应用场景-某客户上云部署方案
在线教育行业云上技术服务白皮书-在线教育行业云计算应用场景-某客户上云部署方案