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

感谢许志强老师的辛苦付出。2015年1月13日 参加云通讯PaaS平台学习，特作此记录。

大纲：

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

一、云通讯PaaS平台的挑战

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

二、可靠性追求

技术挑战

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

可用性标准

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，等等。。。

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

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

常规想法：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
• 视频会议
• 语音会议

云存储用的阿里云存储。