当前位置: 速途网 > 互联网 > 互联网资讯

融云杨威:移动端 IM 开发如何拥有SaaS 级体验


发布: 晖哥  2016年04月27日19:31  来源: 速途网 我要评论(0)

  QCon 北京2016全球软件开发大会已于4月23日在北京国际会议中心顺利闭幕。在23日进行的“移动开发与即时通讯”专场活动中,来自融云的技术副总裁杨威,分享了他多年工作当中所获得的心得与经验。

  融云作为全球最大的即时通讯云服务商,截至2月份,已经累计服务包括土豆、秒拍、百姓网、优信二手车、驾考宝典、大智慧、战旗 TV等在内的 App 逾8万款,日活跃用户量超过2000万,日消息量超过12亿条。在艾瑞咨询最新发布的《2016年中国 IM 云服务行业白皮书》中,融云即时通讯云稳居市场第一。

  当前,移动开发者无论是构建用户生态,还是丰富业务场景,亦或是打造移动办公,所以如何使用即时通讯云,也成为了企业或者开发者必须关注的议题,此次分享,融云杨威的演讲内容涉及融云 IM SDK 架构、IM SDK 实现过程中的经验等,为正在移动端开发的技术人员提供了大量的技术参考与实践经验。

  以下是演讲精彩内容:

融云杨威:移动端 IM 开发如何拥有SaaS 级体验  

  大家好,首先介绍一下我自己,我是北京邮电大学通信工程本科硕士毕业,前通信圈人士,曾从事11年手机研发,现在融云担任技术管理工作,主要负责 Android,iOS,Web 端的即时通信 SDK。融云是一家提供即时通信(IM)云服务能力的厂商。我们的核心技术团队主要来自于前飞信的后端团队,和来自三星的移动端团队。我们的前端团队以前主要负责多媒体技术和通信RCS技术,RCS 是一种电信级领域的即时通信 IM 技术。所以也都是这个领域内的资深从业人士。

  从电信领域转到互联网领域做社交 IM,我们发现互联网行业的特点是快,开发快上线快。对即时通信的需求很大。互联网圈的朋友们,开发者,架构师,对即时通信技术一般都兴趣很高。今天的主题,背后有一个核心思想,就是关于技术选择”。对于我们每一位研发工程师,架构师,技术管理者,你的每一次技术选择,对自己,对公司,都是价值千金,每一次选择都影响着很多资源的投入。做出正确的选择需要信心,需要成功的经验用来参考。今天我分享的是基于我们众多工程师十几年研发经验,几万开发者得来的宝贵经验,我们愿意分享给大家,让大家在 IM 技术研发上做出最好的选择。最近几天我也参与了大会的其他一些分享,其中也涉及即时通信消息,看了之后我更加确信我们融云在这件事上真的是很专业,有很多值得分享给大家的经验,但时间有限,所以我简单的介绍。

  我们这次要分享的内容是,首先介绍一下融云,然后介绍一下融云 IM SDK 架构,第三部分是分享一下 IM SDK 实现过程中那些价值千金的经验,最后分享通过 IM 社交如何实现 SaaS 级的服务。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验  

  首先,融云提供了一个 IM 的云服务平台,这是一个公有云平台。其次,融云提供了一个前端 SDK。这两部分是这个图里面绿色的部分。通过我们的云平台和 SDK,App 之间可以通过收发消息进行互动。最后,我们基于这个平台,提供了一些 SaaS 级的软件服务。对于即时通信平台,我们很多研发人员都是很有情怀的,都像自己做一次 IM,同时有微信这种巨头的存在,很多 App也都有梦想去做一个微信。但总的来说,消息要做到高并发,不丢消息,实时性是非常难的。有些业务,你通过延迟来解决并发问题,或者通过丢包来解决,但对于消息,是一条也不能丢不能延迟的。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验  

  今天的分享我们主要是移动前端。SDK 前端架构是三个部分,协议栈,IMLib,IMKit。我们选用了 native 语言,即 C++ 来实现协议栈部分,并封装了两个 SDK,一个通信能力 SDK,一个界面组建 SDK,通过通信能力 SDK,你可以简单的收发消息,通过界面组件 SDK,你可以在短时间内迅速的搭建一个整套 IM 社交软件。这三部分的划分应该说是比较经典的,曾被很多业内伙伴的所借鉴。

  这里额外聊一下我们对 SDK 在移动端开发的趋势。第一,云服务+SDK 的模式在移动互联网领域,经过一段时间的发展,已经趋于非常成熟了。App 通过嵌入 SDK,实现云服务能力,可以实现快速上线,节省大量的研发运维费用,同时云服务企业自己发展在技术和资金上也越来越强大,大家可以放心选用。第二,核心功能组件通过 SDK 进行封装,是一种基本的技术实践能力。各个公司也都是这么实践的,封装 SDK 的过程本身就是解耦合的过程,资深工程师都知道解耦合是提高软件性能的一个必要过程。其次,封装 SDK 可以提高项目源代码管理的编译消息。最后,可以提高跨部门研发的沟通消息,大家知道程序员最高效的沟通效率是什么吗,就是不沟通。不要说话,不要解释,不要互相说服,你写的 API 我能看懂然后我去调用就可以了。当然这是个笑话,当然是越多沟通越好,比如来参加 QCon 大会听听大家的分享。

  接下来分享我们第一个有价值的经验,IM 协议的选择。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验  

  我参与过一些活动和社群里,我们发现大家都对如果实现一个 IM 有很高的兴趣。第一个面对的选择就是如何去选择和实现 IM 协议,有了协议才有后面的一切。很多人都在关心,我该选择 XMPP 还是私有协议呢。我个人的看法是,移动互联网和计算机技术发展到今天,已经可以替 XMPP 宣告死刑了,到目前为止所有的大型商业机构采用 XMPP 搭建的通信网络要么替换了要么关闭了,运行中的也有一些不多。所以,大家不要去选择 XMPP 构建自己的商业 App IM 功能,当做自学还是很不错的,毕竟服务端都是开源的。XMPP 的两个主要问题是,第一基于 XML 的协议体比较重,对其压缩和解析又耗费内存,第二是其后端设计和开源架构有一些问题,当你的用户体量大了之后非常耗费服务器资源,而且常见在十万用户数量级上频繁的重连和丢消息。这个数据主要来自于一些我们客户的经验,并不是绝对准确。那么我们选择什么呢,我们推荐使用 MQTT,或者参考其思路去设计自己的私有协议。序列化我们推荐 ProtoBuf,这也是 Google 推荐的。选择私有化协议的优点是轻量,轻量处理起来就快,节省前后端资源,省电,这都是移动互联网 App 和核心需求。此外私有协议也会相对更加安全。

  商业 IM 软件还要考虑跨平台。要支持 Android,iOS,WP,PC,Web 端,甚至 Linux 设备。因此在设计和选择之初就要考虑到,否则未来每一个平台和语言都要重新开发一次。我们的协议栈使用 C++开发,基于 Linux,因此可以无缝的兼容几乎所有平台。注意这个图里我们把业务和数据库放到了 native 协议栈部分,这个核心优点是跨平台统一,可以保证每一个细节甚至是响应时间,都可以在多平台一致。业务和数据是否放在 native 对于架构师是比较重要的一个选择。数据库和业务层跟 natvie 协议栈在一起还有一个重要的原因,就是更快的响应和处理消息,当接收到消息的时候,我们会首先给服务端发响应包,这样服务器更快的释放资源。然后移动端在继续进行后续的处理。业务数据和协议都通过 native 实现,可以更好的处理这部分逻辑。凡事有利就有弊,这个缺点也是有的,在 Android 上由于 NDK 编译会导致库文件比较大,而国内 Android App 一般对体积要求比加大。解决办法是不断的优化更新减少尺寸。这部分稍后还会介绍。

  第二个有价值的经验是 SDK 的实现。我们封装了两个 SDK。IMLib 和 IMKit,其中 IMLib 主要负责能力,建立连接和发送消息等功能。IMLib 实现的是一个跟微信风格类似的界面。相比之下很多产品一般只会选择一个类似 IMLib 这样的能力 SDK。做出这个选择的根源是我们希望节省开发者的时间,共同的部门实现一次就可以了,不需要第二次第三次反复开发,既然80%的 IM 社交界面都是类似的,那么融云实现了提供一个标准的模式就可以了。开发者的创意是无限的,还有20%的需求我们满足不了,那么使用我们的通信组件 IMLib 就可以了。我们做这个界面 SDK 基于一个价值观:所见即所得。客户看到我们宣传的界面是这样的,集成了 SDK 之后得到的也是这样的。不会像有的产品宣传的无所不能,其实只是方便面包装上的效果图,都要等着客户自己去实现。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验  

  介绍一下IMkit组件的架构,大家看图即可。主要是封装了两个界面:会话列表和会话。Android 和 iOS上设计架构略有区别。有很多工程师也纠结这个问题,是否应该让 Android 工程师和 iOS 工程师使用同样的设计模式,我们的经验是让各种的工程师使用各自的架构,在业务上划分好就可以了。MVC,MVVM,MVP,本质上就是显示层、控制层和数据层的划分。重要的是划分好层次即可。让一类工程师去学习另外一类工程师的开发习惯效果不好。这个经验来自我们融云几万开发者。第二条经验是融云自己内部的经验,我们不适用第三方组件,比如说HTTP 和数据库的第三方组件。第三条是持续的优化结耦,这也跟今天所有类似经验一样,选择之后一定是有利有弊,针对弊端,要不断的去优化。

  我们为什么选择做一个界面SDK 呢,因为实际上在移动端,UI 的开发量是极大的,一般占 80%以上。输入区,表情,图片选择器,会话界面,消息展现等等,一般需要一个工程师1个月的时间开发,1个月的时间调试。两个端就是4~6个月。而且老板和产品经理还觉得很容易,虽然确实是不难,但是其实细节上做出来性能效果差别都很大的。我们的一个价值观就是:我们每多做一些,开发者就少做一些,所以我们选择把界面封装起来替客户做完。当然也有缺点,IMKit 是一个非常重的封装模式,接口很多,使用方式复杂,我们选择不断的去优化,未来我们会进一步解耦合把核心的部分再次封装。另外我们融云的客户支持服务工作做的很好,可以提工单像我们咨询。我们每天有很多研发工程师回复200个左右的客户工单问题,在此也感谢我们融云这些工程师。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验

  再介绍一下IMLib的架构,同样大家看图理解吧。我们封装了两个核心象,Conversation,Message,这个对象是跨平台一致的。lib提供了像 connect、sendMesage这样的接口,同时我们做了很多工作,让网络连接更加稳定性。不需要客户去做重连。很多朋友关心长连接和稳定和优化,其实长连接就是通过发送心跳包维持,并没有什么秘密。最差的结果就是多重试几次,但我们不能这样,我们必须确保客户得到的版本性能是最优的,所以关键是持之以恒的优化,发现问题并解决问题。我们每个版本都监控电量、流量、内存。确保性能最优。

  第三个有价值的经验是正确的版本迭代姿势。也是今天的点睛之笔。前面介绍的技术选择,不能说绝对正确,但也都是基于我们融云资深团队这么多年的经验,几万开发者的集成经验。有优点也有缺点,那么通过什么方式弥补优点就很重要。比如使用 native 语言实现协议栈,优点很多,但缺点是 Android 上的包比较大。那么解决的办法就是不断优化每一行代码去优化包的大小。提供 IMKit 的优点是节省了用户的时间,但是缺点就是支持使用复杂,那么我们就进一步去拆解和封装。技术选择只是第一步,之后的不断持续优化才是一切。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验  

  这张图是融云至今为止发布的 220 多个版本道路中的一部分,横轴是从2015年1月到2016年4月也就是现在,纵轴是我们衡量的一个性能参数,基于尺寸,电量,性能综合评价。在这里我们分享一下我们成功经验,也分享一下不那么成功的经验,融云于创业之初发布了1.0版本,最初版本的要求一定是快速上线,快速支持客户。但是在业务量体量到一定规模的时候,你的架构可能是支撑不住的,所以一定要做一次架构的重构,这个情况在很多人身上都出现过。当时我们采用了一次大的架构更新。导致了 1.0 和 2.0 两个版本在几个月内并行,架构升级一定是性能的提高功能的增加。但这次升级并不能成为成功,因为长时间版本并行,给客户带来了一定的烦恼。这个现象融云遇到了,很多人也遇到了,即使现在我们的圈内伙伴内还在进行类似的升级。那么正确的姿势是什么呢,我们可以看到从2015年8月开始到现在,我们的整体功能增加了 32%,协议栈包降低了 75.7%,Android/iOS 源代码量减少了 36.8,电量优化了 36% ~ 77% 不等。而用户完全无感知。我们的版本号没有变化,但其实代码已经大变样。我认为身为一个架构师,不应该让用户通过版本号增加去感知你架构的改变。这是我们很骄傲的一件事,我们在一年的时间内通过不断迭代、追求卓越的的互联网精神,持续的提高着软件质量,给客户带来更好的性能,更小的尺寸,更加省电。这才是我们正确的开发者服务精神。

  所以结合起来说就是,做出正确的选择,通过不断的迭代努力去优化自己的产品,永不停止。

  第三部分,我们讲一些融云如何实现 SaaS 级的体验和服务。SaaS = Software as a Service,软件即服务,在互联网时代,SaaS 的核心是“一经要求,即可使用”,最佳实践是通过浏览器,打开一个网页就可以使用。在移动互联网时代,实现 SaaS 服务的难度相对大了一些。我认为移动互联网时代的 App 就是互联网时代的浏览器,同样是入口,区别是移动互联网上的入口多了一些。用户进入一个 App,进行他的核心体验的同时,也会发消息,也会打电话,购物,发红包,这些体验可以在 App 内闭环完成。这对 App 厂家们来说是一种核心需求,对用户来说也是一种最佳体验。要实现这些功能和能力,仅靠 App 厂家自己是不行的,这意味要重复建设很大的研发团队。因此需要集成第三方服务,需要集成 SDK 发布版本,这一步是无法跳过的,但在集成之后,服务是可以反复体验的。所以我们融云的目标是提供一种 SaaS 级的体验,一经集成,即可使用。

  融云在这方面有比较好的实践经验,融云提供的是即时通信 IM,是一种通信能力,我们并不做具体的 SaaS 业务,比如客服。但我们的很多客户都需要客服,需要一个完整功能强大的客服工作台,于是我们选择了跟市面上最优秀的一些厂商合作,通过融云 SDK,让客户可以在移动端使用 IM,在 PC 端使用客服工作台。这个技术方案大概如图,首先要在客户端实现功能抽象化,把标准的客服功能抽象化为具体的消息,然后通过在服务端实现一个消息转 API 的适配层,直接访问客服合作伙伴的服务器。这个实践模式看起来简单,其实这并不是唯一选择,但他是最优的,效率高性能好,合作伙伴不需要改变自己的设计架构。我们可以同时支持多家客服后台,而移动端抽象化之后,对后台使用的是谁完全无感知,只是基于标准的信令去做处理。而对客户来说,服务端可以动态的控制和调整使用哪个后台,增加了更多的选择。

融云杨威:移动端 IM 开发如何拥有SaaS 级体验

  客服是我们的第一类实践,我们的第二类实践是对音视频产品能力的整合,对于有些客户需要的视频电话,视频直播聊天室等能力,融云也选择了市场上最好的产品,替客户封装好。区别于客服的实践场景,移动端必须使用两个 SDK,在移动端增加适配层。这类产品融云现在支持比较好的直播聊天室,因为融云的 IM 聊天室能力非常强大,今年视频直播业务火爆之后,非常多的客户找融云提供可以支持超大量并发的聊天室,因此我们把聊天室跟视频直播进行了一个比较好的封装和整合,方便客户更加容易的使用。介绍这两种优秀的实践模式,除了适合企业开发领域,其实更加适合各个 App 厂商去根据自己的需求集成第三方服务,可以更加灵活的把第三方 SDK 和云服务集成到自己的 App 里。

  最后谢谢主办方,谢谢大家。

分类:  互联网资讯   用户:  晖哥    关键词融云 杨威

速途网探营丨问卷网创立三年深耕网络数据调研服务