您的位置:首页 > 其它

PaaS 平台学习(开源力量OSF)构建千万级大规模、高可靠PaaS平台的技术挑战 学习笔记

2015-01-13 22:07 477 查看
感谢许志强老师的辛苦付出。2015年1月13日 参加云通讯PaaS平台学习,特作此记录。

大纲:

选择Paas平台的考量(我的企业是否适合选PaaS平台,我应该选怎么样的PaaS平台)
基于PaaS平台的开发、测试、部署和迁移的流程、关键技术和注意事项
如何构建能支持千万级用户的大规模PaaS平台?技术挑战有哪些?有哪些经验和教训?
如何实现PaaS平台的高可靠性?
如何保证PaaS平台的安全性?

一、云通讯PaaS平台的挑战

客户业务突然爆发性增长
系统受到DDOS攻击
运营商政策调整,某些呼叫不能落地
IDC机房光纤被挖断
系统升级出现BUG,业务全停
业务主机H突然宕机:

二、可靠性追求

技术挑战

可靠性
扩展性
安全性
可管理性
经济性

可用性标准

5个9的追求:

AvailabilityDowntime/YearExample
90%36days 2hoursPersonal clients
99%87 hours 36 minutesEntry-Level Business
99.9%8 hours 46 minutesISP,mainstream Business
99.99%52 minutes 33 secondsData Centers
99.999%5 mintue 15 secondscarrier-grade Telco,Banking
99.9999%31.5 secondsMilitray defense system

高可用性——High Availability

清除单点故障
故障自动检测
故障隔离
运维操作Web化自动化

消除单点故障原则

常规方案,主备、集群Cluster负载均衡:
数据库分库、分表方案:

初始规划就要考虑。以前做运营商系统通常选择oracle Sybase,而互联网企业多用MySql。经典案例,余额宝,天宏基金早期是Oracle,后来与阿里合作,移植到MySql上。其单机无法与SyBase比,而是用许多数据库服务器进行分库分表。初期就要考虑分库分表,后期改成本会相当高。
大系统小做 :

许多人刚开始策划功能都会想的非常复杂,但其可靠性难以得到保证。设计大的系统一定要往小的做,尽可能降低交互的复杂性,不要设计的非常复杂,交互其中一个环节有问题都会导致故障。

系统里一个小的部分,尽量完成单一职责,不要很多事情一起做。单个服务 高内聚、低耦合。参考文章:http://martinfowler.com/articles/microservices.html。

一个系统过大,不利于扩展,出问题机率大。
尽可能做到无状态:nginx每次响应是独立的,这次请求与上次请求尽可能独立。(原子性)。

不是所有东西都可以无状态,如通信过程,发起、接听、摘机等,必须保存呼叫状态,这就必须有状态。这种情况下要做成分组,或子系统。假如所有有状态的请求能分配到不同组,系统出现故障影响小的分组,分组出问题就切换到另外分组。从分组角度看就是无状态。如A、B、C三组。在连接的时候选择一个服务节点。
异地部署、容灾

对于云服务提供商很重要,IT机房的可靠性也不是非常高,当部署到一个机房的服务不能使用时,对用户影响很大。所以必须要考虑异地部署、容灾。
不能做到无状态就需要分组

一个多机房系统的方案



通过智能DNS。
产生的问题:用户可能用公用的DNS,如谷歌的DNS 或其它开放的DNS,可能会造成判断的区域有问题。一般会做两层,智能DNS只是前置的识别,具体业务节点对真正IP进行二次路由。设置一个折中的时间进行DNS解析。
每个节点要能独自提供服务。

单IDC内部署结构



跨区域数据同步解决原则:



一致性:数据同步
可用性:一台宕机能不能再提供服务
分区容忍性:如北京与广州之间断了,还能不能分别提供服务;事实是要求能分别提供服务,这时对数据一致性要求就没那么高了。一般互联网对数据一致性要求可能不是那么高。
IVR服务:不是所有都全部一致,如果要强一致性,数据同步;
再如账单:也不是强一致性的。在某些系统里 客户查询的余额不必是最终的结果。信用卡线下刷卡的方式,也是一段时间后同步过去。



使用Cassindra分布式NoSql数据库。
kafka消息队列缓冲是什么。
而传统的关系型数据库在处理一些数据时比NoSql更具优势,所以后端需要MySql支持。
关系型数据库与NoSql间要有数据同步,需要程序进行处理。

怎么做故障检测

设计系统时,就要考虑到系统会出现哪些故障。
原则:

在用户反馈前发现系统故障

如用户打电话,第一次打电话打不通,在第二次尝试时要能检测并解决问题。

分层次的故障检测:

最底层是机器的检测:如检测机房故障,转移DNS。检测机器故障,要把机器移除出来。
模块的检测:
业务功用的检测:模拟用户操作进行检测。

防止误检测保护:

检测本身有失误的情况,如IDC整个网络不通,判断故障之前不能整个机器Ping不通,就改了DNS。而要多种渠道确认故障。

运维自动化、WEB、数据化:

手工操作有极大的安全隐患,避免手工操作引起的系统问题,设计之初就要考虑可运维的、可自动运维的。
模块的升级、维护全部通过WEB进行。
通过收集的数据进行运维,设计时要考虑把数据采集进来,进行分析,提前预判一些故障。当发现某台机器ping 响应很久,就预示机器可能会出现故障;或机器的I/O非常高,预测磁盘可能出现问题;或带宽高等。通过运维的手段,使系统的可靠性提高。

灰度发布:



整体更新可能的问题:新功能虽然经过测试,但总可能出现问题,上线后隐藏的BUG可能会引起所有客户的全局故障。采用灰度发布,系统发布的时候是渐进的,整个系统里可能有相同模块、不同版本存在,系统首先在沙盒系统更新,调试、测试。稳定后进入客户组1,等等。。。

三、支持百万、千万、上亿的在线用户

操作系统调优:
采用异步接口:IOCP、epoll
内存数据库缓存、减少数据库操作:
内部采用长连接,如Protocol Buffer、thrift avro protobuf等:系统内部长连接减少连接开销。
节点可并行扩展、Cluster集群:openstack
自动部署新业务节点支持服务:



常规想法:QQ号码,如果有3台,那QQ号除以3,分配到不同服务器。但添加服务器时,负载分配会有很大波动。如果是对于数据库,波大会有很大影响。
分布式系统,很多采用一致性Hash的负载分配,

四、互联网的语音质量保证

语音编码的选择:如silk、sap g.729
网络状况的检测:
自适应码流调整:
网络封包大小的选择:
质量反馈机制:两端通信,知道对端的情况。如果RDPC标准协议能够知道对方情况。
智能IP路由:根据客户端的IP,决定到哪个路径到服务器最短。丢包以后怎么处理,丢弃还是补偿,或用延迟换语音质量。
NACK捎带机制:

五、安全性:

网络DDOS攻击:

一般自己要靠二次平台提供商或IDC帮做这部分功能。像阿里云前端有流量清洗设备,帮助清理一些攻击。如果量很大了,也很难处理。要尽可能找大的服务商,如阿里云。
小流量攻击,可以用iptables等工具处理。

业务的安全沙箱隔离:

像服务器落地资源是有限的,不可能为用户恶意占用,造成其他客户无法使用。每个用户能够使用多少资源是有限制的,包括对接口的调用频度。在系统设计之初就要考虑,防止恶意占用资源。如果是正常的,就要调高其资源阈值。

通话的安全性:

如通话加密的接口,通过这些接口的通话内容,平台提供商也无法解密。一般的用户可能不需要这么高加密级别。

六、构建自己的云通讯平台

开源的成熟方案:
WebRTC:Google开源的,用来作浏览器端即时通讯解决方案;neteq,google收购,在终端一侧大幅提高语音质量。
openfire:IM
opensips:IM
KAMAILIO:
Asterisk:
FreeSWITCH:
mobicents:开源的通讯的方案提供商
telestax:

(容联云通讯提供的免费服务)移动端融合通讯能力API

IM
视频通话
VoIP
视频会议
语音会议
云存储用的阿里云存储。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: