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