第一章技术方案
3.1. 工程概述
? 工程名：
? 建设单位及项目负责人：
3.1.1.
工程背景
随着移动互联网的爆发式发展，手机上的沟通变得越来越重要，即时通讯作为当今互联网时代的一个重要通信手段，互联网时代的人、企业等已基本接受和习惯即时通讯带来的各种便捷服务，各种即时通讯工具、聊天软件应用也如雨后春笋层出不穷，用户也越来越习惯利用在手机APP中植入的即时通讯功能服务进行在线即时聊天互动，获取产品或服务的信息，或进行人与人之间的沟通互动，当前四川电信通过积极探索实践，在移动互联网领域也创新地开发出一些行业重量级的业务应用，对即时通讯能力服务需求非常急迫，无专属即时沟通工具，买家与卖家间无即时沟通，订单及物流通知未及时送达；QQ、微信等第三方即时通讯工具，只能解决交流的问题，而无法对用户体验和平台无缝性带来帮助，没有与自身产品线进行的深度集成，应用需求无法真正满足。
因此建立一套统一的IM平台以及专属的聊天产品，对应用的推广与发展有非常重要的意义。
3.1.2.
需求概述
鉴于电信自主运营应用对IM即时通讯能力服务有相应的集成需求，需要构建一套云即时通讯服务平台，为需要IM即时通讯的应用提供基础的即时通讯能力服务，支持嵌入到电信自主运营开发的业务应用中提供即时通讯服务，实现即时通讯基础服务能力平台化、SDK类型丰富化，支持多应用接入。
同时基于IM即时通讯平台可以定制一套专属于自己的IM通讯软件，对数据的保密性、安全性以及功能的多样性都能很好的满足。
.
3.2. 建设目的及原则
构建一套云即时通讯服务平台，为需要IM即时通讯的应用提供基础的即时通讯能力服务。同时基于IM即时通讯平台可以定制一套专属于自己的IM通讯软件，对数据的保密性、安全性以及功能的多样性都能很好的满足。
3.2.1.
总体建设原则
11.2.1.1 系统可用性原则
系统可用性（Availability）是用来衡量一个平台系统能提供持续服务的能力，它表示的是在给定时间系统或者系统某一能力在特定环境中能够满意工作的概率。
采用先进的技术和方法，满足和适应移动互联网技术更新速度，在满足开发时间节点的要求下，满足用户的交互体验和功能需求，采用智能化的处理特色，满足运营管理的效率要求。
在系统运行当中可能会影响到系统可用性的因素：
1.操作人员和组织
其实这个地方平台在使用中的管理员，他是否重视运维?组织是否已经认识平台带来的价值，把平台的可用性当作自己的一个核心能力来看待。是否把面向用户的业务能力和运维很好的对接?是否建立起用户质量的组织文化。
2.业务流程
业务管理平台的流程梳理多个角色自己的关系和职责。我们第一个要去看这个流程在面对故障的是否起到了积极的作用，比如说能够确保故障信息的准确送达，同时保证处理人的角色和职责是清晰的。其次不断去检查流程是否可以自动化驱动，而非人为驱动。人是不可靠之源!我们最终希望形成是一个自动化、标准化的流程，这样的流程不容易被异化，且能保证预期执行结果一致。
3.后期的运维技术
.
.
很多时候大家看到的技术是运维技术，其实恰恰相反对于业务来说，对其高可用的影响，因此在其中需要遵循很多原则，有一些原则需要有普适的参考价值。比如说服务降级、过载保护、服务公共化等等。这些方法论是否已经融入到研发和运维的架构设计之中。业务功能需求优先，而非可运维性优先，可运维性最终就是业务的质量。
4.业务管理
把你的平台的业务能力标准化，你可以转换成我们多个业务指标，比如说质量、可用性、用户体验、用户满意度、成本，有了这些业务导向性指标，才能把IT能力和业务更好的对接起来。否则很容易在组织内，形成运营维护共同认识，而非创造价值部门。这一点还有一个重要性，就是让维护人员也要足够的认识到，他们的能力直接和业务相关，需要增强业务敏感度。
在系统运行当中为了保障系统的可用性所采用的策略：
1.故障发生前，建立运维质量仪表盘
我们一定要建立运维数据看板，这个看板的数据并且要在业务、测试和运维人员对平台的情况达成一致，让大家足够重视这份数据，这样数据便有了推动力。建议这个地方的核心数据指标不要太多，因为涉及到多个团队，大家不能够一致理解，特别是传达到管理层，太多的指标，容易失去关注的焦点。
通行的做法，就是用可用性来做运维的数据看板。可用性的计算方法有简单的方法，也有复杂的方法。简单的方法就是在监控系统中搞一些探针来模拟用户监控，最后我们能得出故障的时长和可用性的时间，这样我们可以建立每天、每周、每月、每Q的可用性，可以做到分业务、分服务(更细粒度)等等;复杂的方法在模拟数据的基础上，可以把事件系统记录的时间数据拿过来作为评估的标准。另外可以把可用性上升到质量层面，这个里面涉及到的评估维度(成本、用户体验、满意度)就更多了，数据获取的来源也变得更多，有些是来自于客服系统，有些是来自于舆情监控，有些是来
.
.
自于运维容量系统，有些是来自于事件系统等等，不过最终呈现的指标就是一个---质量。
2.故障发生前，设定技术准则和要求
运维需要和研发建立整体的技术标准和规范要求。因此从保障系统可用性的角度来说，我们需要设定一个路线图，最终服务于这个平台运行的可用性。比如说之前我提到的影响系统的因素里面讲到了先做标准化，然后做公共服务化、最终服务无状态化。运维一定要把标准化作为核心要务来推进，建立标准化的运维环境，建立标准化的技术栈，建立标准化的高可用方法论，最终这个业务的可用性一定是有保证的。
3.故障发生时，恢复是第一要务
故障发生的时候，恢复必须是保证系统可用性所必须要时刻记住的。
在故障的当下，定位故障原因是大忌，这往往让故障时长变得不可控，因为会直接影响MTTR(平均修复时间)，影响用户的业务使用。用一些标准的原则去隔离故障，比如说服务器重启，链路禁用，DNS切换等等。
4.故障发生后即时的排查和复盘问题
每一次故障发生后，运维人需要牵头去复盘故障，刚刚说了我们恢复是第一要务，所以故障的根本原因我们可能还不知道，此时就需要运维、测试和研发一起仔细的去看整个的故障过程，看看到底哪儿有什么问题?基本上也是从刚才说的四个方面来评估。不断的审视我们运维的能力和IT的能力，说“故障是运维最好的老师”的原因也在于此，它能够不断驱使我们走向更高的成熟度。
11.2.1.2 系统可维护性原则
系统采用集中部署便于集中维护，提供分权分级的权限管理机制，不同的系统模块，不同的任务可以设置不同的数据操作、统计和监控查看分析权限。系统采用构件化设计思想，系统框架与业务逻辑分离，具备开放的体系结构。
.
.
系统功能模块均采用插件式方式架构，易于修改，对某一个功能模块的修改，一般不影响系统其他功能的正常运行；系统分析、调度更多采用的是配置模式，易于扩展，新增服务时对系统的修改较少，仅需调整配置文件参数即可；系统具备方便且可定期执行、分析结果的业务测试功能。
11.2.1.3 系统可靠性原则
系统可靠性指在规定条件下和给定时间内平台能正确运行的概率。系统可靠性用下列四个标准来判断:平台在运行的过程中不为故障所破坏或停止;平台的业务流程的结果不包括由故障所引起的错误；平台对执行业务的时间不能超过一定的限度；平台运行在允许的网络内。系统可靠性保障主要体现在以下两个方面： ? 系统采用增量备份和全备份相结合的方式定期备份重要的系统数据；
? 系统应具有良好的并行处理机制，对存取冲突的竞争具有有效的仲裁和加锁机制，
充分保证事务处理的完整性，并降低系统I/O 开销，提高并发用户查询和存取的性能。
11.2.1.4 系统可扩展性原则
可扩展性是软件设计的重要的原则之一，它以添加新功能或修改完善现有功能来考虑软件的未来成长。可扩展性是软件拓展系统的能力。
系统采用成熟的框架开发接口服务和后台管理，前端APP可采用Native和HTML5代码混合实现，整体采用分层设计。支持开闭原则设计思想，便于系统的灵活配置和部署；支持插件技术, 便于系统纵向延伸和对新技术的接入。
良好的可扩展性设计应该允许更多的业务功能在必要时可以被插入到适当的位置中。这样做的目的的是为了应对未来可能需要进行的修改，而造成代码被过度工程
.
IM即时通信项目技术方案
