PaaS 平台学习（开源力量OSF）构建千万级大规模、高可靠PaaS平台的技术挑战 学习笔记
感谢许志强老师的辛苦付出。2015年1月13日 参加云通信PaaS平台学习，特做此记录。html
大纲：
- 选择Paas平台的考量（个人企业是否适合选PaaS平台，我应该选怎么样的PaaS平台）
- 基于PaaS平台的开发、测试、部署和迁移的流程、关键技术和注意事项
- 如何构建能支持千万级用户的大规模PaaS平台？技术挑战有哪些？有哪些经验和教训？
- 如何实现PaaS平台的高可靠性？
- 如何保证PaaS平台的安全性？
1、云通信PaaS平台的挑战
- 客户业务忽然爆发性增加
- 系统受到DDOS攻击
- 运营商政策调整，某些呼叫不能落地
- IDC机房光纤被挖断
- 系统升级出现BUG，业务全停
- 业务主机H忽然宕机：
2、可靠性追求
技术挑战
- 可靠性
- 扩展性
- 安全性
- 可管理性
- 经济性
可用性标准
5个9的追求：
| Availability | Downtime/Year | Example |
| 90% | 36days 2hours | Personal clients |
| 99% | 87 hours 36 minutes | Entry-Level Business |
| 99.9% | 8 hours 46 minutes | ISP,mainstream Business |
| 99.99% | 52 minutes 33 seconds | Data Centers |
| 99.999% | 5 mintue 15 seconds | carrier-grade Telco,Banking |
| 99.9999% | 31.5 seconds | Militray 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，等等。。。
3、支持百万、千万、上亿的在线用户
- 操做系统调优：
- 采用异步接口：IOCP、epoll
- 内存数据库缓存、减小数据库操做：
- 内部采用长链接，如Protocol Buffer、thrift avro protobuf等：系统内部长链接减小链接开销。
- 节点可并行扩展、Cluster集群：openstack
- 自动部署新业务节点支持服务：
常规想法：QQ号码，若是有3台，那QQ号除以3，分配到不一样服务器。但添加服务器时，负载分配会有很大波动。若是是对于数据库，波大会有很大影响。
分布式系统，不少采用一致性Hash的负载分配，
4、互联网的语音质量保证
- 语音编码的选择：如silk、sap g.729
- 网络情况的检测：
- 自适应码流调整：
- 网络封包大小的选择：
- 质量反馈机制：两端通讯，知道对端的状况。若是RDPC标准协议可以知道对方状况。
- 智能IP路由：根据客户端的IP，决定到哪一个路径到服务器最短。丢包之后怎么处理，丢弃仍是补偿，或用延迟换语音质量。
- NACK捎带机制：
5、安全性：
网络DDOS攻击：
通常本身要靠二次平台提供商或IDC帮作这部分功能。像阿里云前端有流量清洗设备，帮助清理一些攻击。若是量很大了，也很难处理。要尽量找大的服务商，如阿里云。
小流量攻击，能够用iptables等工具处理。
业务的安全沙箱隔离：
像服务器落地资源是有限的，不可能为用户恶意占用，形成其余客户没法使用。每一个用户可以使用多少资源是有限制的，包括对接口的调用频度。在系统设计之初就要考虑，防止恶意占用资源。若是是正常的，就要调高其资源阈值。
通话的安全性：
如通话加密的接口，经过这些接口的通话内容，平台提供商也没法解密。通常的用户可能不须要这么高加密级别。
6、构建本身的云通信平台
开源的成熟方案：
WebRTC：Google开源的，用来做浏览器端即时通信解决方案；neteq，google收购，在终端一侧大幅提升语音质量。
openfire：IM
opensips：IM
KAMAILIO：
Asterisk：
FreeSWITCH：
mobicents：开源的通信的方案提供商
telestax：
（容联云通信提供的免费服务）移动端融合通信能力API
- IM
- 视频通话
- VoIP
- 视频会议
- 语音会议
云存储用的阿里云存储。