感谢许志强老师的辛苦付出。2015年1月13日 参加云通讯PaaS平台学习，特作此记录。
大纲：
- 选择Paas平台的考量（我的企业是否适合选PaaS平台，我应该选怎么样的PaaS平台）
- 基于PaaS平台的开发、测试、部署和迁移的流程、关键技术和注意事项
- 如何构建能支持千万级用户的大规模PaaS平台？技术挑战有哪些？有哪些经验和教训？
- 如何实现PaaS平台的高可靠性？
- 如何保证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，等等。。。
三、支持百万、千万、上亿的在线用户
- 操作系统调优：
- 采用异步接口：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
- 视频会议
- 语音会议
云存储用的阿里云存储。
扫一扫
421
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
