《近匠》融云，自主研发真正不丢消息的IM云服务
移动互联网时代的即时通讯技术已与互联网时代完全不同，弱网络、丢消息等问题天然存在。融云即时通讯云源自飞信团队，核心创始成员拥有8 年 IM 技术积累，却推倒重来，从第零行开始写代码，自己做一套全新的通讯协议和服务端架构，并将逐步落实 SDK 开源计划。本期《近匠》专访融云即时通讯云 CTO 杨攀，听他讲述矢志做即时通讯行业老大，把即时通讯做穿做透的融云是如何做到不丢消息、快速迭代，专注为用户提供 IM 云服务的。
图：融云即时通讯云 CTO 杨攀
CSDN：请介绍一下您以及团队主要成员的从业经历？
杨攀：融云创始团队的所有核心成员几乎都来自于神州泰岳飞信团队，原本都是负责飞信业务的高级管理人员、核心产品和技术人员。CEO 韩迎原本是飞信的 VP，负责市场销售和运营，另一个联合创始人是我们的首席架构师李淼，原本在飞信负责即时通讯、社交产品，COO 毛炜之前则是从事企业级应用软件服务业务。
我个人很早就开始写程序了，从 94 年开始到现在已有二十多年，一直都在和 IM、社交打交道。曾参与微软 MSN Messenger Mobile China 业务的开发和管理工作，负责过时光网架构升级和改造工作。2008 年加入神州泰岳飞信团队后，先后负责了飞信社交平台、飞信开放平台、飞信即时通讯平台业务的管理工作和研发管理工作。
CSDN：请具体讲讲融云是什么？
杨攀：融云很简单，我们做的是即时通讯云服务，这是一个 2014 年新生的行业。之前大家看到的即时通讯服务都是一些to C的产品，比如QQ、微信、飞信、旺旺、YY、陌陌等，而即时通讯核心技术也都掌握在这些大厂商手里，从事 IM 的小厂商寥寥无几，即使涉足也可能都是企业级，其支撑的并发用户量远远无法和to C的产品相比。
其次，移动互联网时代的即时通讯技术和互联网时代已完全不同，移动互联网时代的通讯面临着网络不稳定的问题，我们曾做过数据统计，一款手机一天内断网可能会高达三百多次，其难度相对而言也更高，IM 技术需要大幅革新。而从2012年时基本没有人会去接入第三方SDK到2014年为大众所接受，开发者服务的理念也日趋成熟。
因此对我们而言，就是把自己的核心业务做好，普惠开发者，让开发者能够通过 SDK +云服务的形式能够很简单地在自己的业务中集成即时通讯能力，将原本一个非常难、非常高大上的“阳春白雪”的技术一下子就变成零门槛。我们的方式是提供一个 SDK，开发者只需将其嵌入到App中，融云会在云端提供服务器来负责消息传输等，便能实现端对端的聊天。除一对一的单聊之外，我们还提供群聊、音视频通话、公众服务等功能。
CSDN：融云的公众服务与微信公众账号有什么关联或不同吗？
杨攀：融云的公众服务是帮所有使用融云 SDK 的应用搭建一套公众账号平台，就相当于每个App都有自己的一个公众账号平台，可以自己给自己的 App 开发公众账号，也可以找别人开发并接入到自己的平台上给自己的 App 使用，让每一个 App 都可以变成一个“微信”。
微信本身的理念是中心化，成为一个操作系统，所有的业务都可以直接做一个公众号嵌入到微信里，开发者也无需再劳心劳力地开发 App。而我们做的事儿则是“去中心化”，我们帮助微信之外的其他 App 厂商具备这种能力。
CSDN：融云为开发者提供了哪些核心服务？
杨攀：我们对于公司的定位非常单纯，就是一家纯技术的公司，核心产品就是做即时通讯。也有很多客户会问我们：你们做不做社交、朋友圈、论坛、地理位置定位、短信验证码等？我们觉得这些并非自身长处所在，我们要做的就是把核心领域做透做穿，也是可以成功的。所以我们做的通讯就是单聊、群聊、聊天室、音视频通话、客服平台、公众服务等，全都属于即时通讯的范畴。
CSDN：与其他IM云服务提供商相比，融云在即时通讯技术、功能、成本等方面各有着什么样的优势与不同？
杨攀：融云的研发团队是业内唯一一家做 IM 出身的团队，这是其他厂商不具备的最大优势，即时通讯技术是一套非常复杂的体系，不是说一两个人挑大梁就能做好的，必须要靠一个团队去把它搞定。技术上的不同就在于，不少竞争对手采用的都是一些开源的解决方案，因为没有经验，直接在开源的基础上进行修改并提供服务。但开源的解决方案都存在一些问题，首当其冲的便是这些方案都是为 PC 互联网设计的，而非移动互联网，在移动互联网领域，弱网络、丢消息等问题天然存在。
图：融云即时通讯云架构图
其次，这些开源的解决方案都是企业级的解决方案，这也就意味着一旦用户过多，无论怎么改，系统都撑不下去。所以我们推倒重来，参考微信公开的设计理念，从第零行开始写代码，自己做一套全新的通讯协议和服务端架构。
CSDN：从开发者角度，选择一项IM云服务都包含哪些关键因素？
杨攀：现实地说，开发者往往很容易被市场宣传所左右，绝大多数开发者都不会非常细致地去研究到底谁家的技术方案好，更多的时候是凭广告、宣传营销这些感性的认识。但对于比较理智的开发者，通常会考虑服务的稳定性、消息的可靠性等因素，比如消息丢不丢、重不重复、乱不乱序等，服务宕不宕机？使用开源解决方案的服务商总是会碰到频繁宕机的问题，并且很难完全掌握整个解决方案，而融云自主开发服务架构，即使偶尔出现小故障也都是局部的，能快速解决，而且我们也不会存在一宕机整个系统就挂了的问题。
另外，支持和服务也很重要。客户有问题，反馈能够多长时间得到响应并解决？这是开发者非常看重的。其实现在整个互联网行业都比较快，大家一边出产品，一边迭代，没有说花一两年的时间写一个项目，然后突然拿出来，那个时候可能机会已经过去了。现在我们做到的就是快速迭代，每周一晚都会发布一个新版本，保证用户这周提出一个问题或需求，下周二便可以拿到。如果用户觉得版本更新太快，可以不更，这完全由用户自己来控制，融云不会促使用户必须升级。
为了更好地解决客户问题，我们将 SDK 分为不同版本，有既改 Bug 又加功能的开发版，不加功能只改 Bug 的稳定版，以及非常稳定的发布版，既满足快速迭代的需求，又能够让用户得到稳定的版本。
CSDN：在开发、更新、运营、维护过程中，是否遇到过一些比较头疼的问题？如何解决的？
杨攀：现在最大的问题就是客户每天反馈的大量信息，包括需要去跟踪客户提出的新需求、跟踪用户反馈的 Bug 等。这也就直接造成如何让客户的问题得到最好的追踪和解决，这成为我们很重要的问题。每天每个人脑子里过的信息量是一般的研发团队无法想象的，各种信息接踵而至，我们经常做一些并发性的工作，但既然我们选择了给开发者提供支持就一定会努力完成。从另一个侧面来看，这可能就是所谓幸福的烦恼。
CSDN：那顶着这么大的压力是否有行之有效的解决方案？
杨攀：我们几乎每天都会对流程、工具、支持方式进行一些细微的改进，并不断尝试新的方法，不断地去优化，思考怎么去更好地提供支持。比如最近我们发现，用户在提出问题时，很多问题描述并不清楚，然后我们会问他，这样一来二去就浪费了大量的时间。然后我们就会想些办法，在节省沟通成本的同时，也能让开发工程师在短短的十几分钟内就能修改完善，在提高效率的同时也能很好地提升质量。
CSDN：产品从最初的开发到现在有着怎样的开发思路？
杨攀：先讲移动端 SDK，我们将 SDK 分为两层，底层的通讯库用于满足自己定制通讯 UI 交互界面的高级客户需求。另外我们也考虑到其实更多的开发者并不愿意在聊天界面上投入太多的精力，我们就做了一个 UI 组件，开发者几乎不用写代码，可以使用该组件直接调整设置。其实这对于我们而言也是非常有挑战的，既要满足功能，又要设计结构去实现调整和扩展，代码量几乎都耗在这些地方。
CSDN：如何计费？采用什么样的盈利模式？
杨攀：PaaS 厂商通行的标准计费模型是按量付费，请求多少次 API 就付多少钱，然后阶梯定价，但我们在刚起步时便思考了商业模式究竟应该是什么。如果按照 PaaS 平台的通行模式来走的话，友商之间就会打起价格战，这个非常没意思。并且，我们对自己的定位就是一定要做这个行业的老大，拥有自主开发的核心技术，再加上这么多年来在 IM 领域的长期摸索和实践，我们自信在成本上可以比其他友商有几倍的竞争优势，用户可以直接免费使用我们的 SDK 和基础服务。
此外，融云还提供付费增值服务，以满足用户的个性化运营需求，因为这其中包含的许多功能特别费磁盘存储、服务器的计算资源、带宽流量，我们需要为此付出巨大的成本。未来，我们不仅仅只是简单地提供能力，更希望能够帮助使用融云的开发者，靠我们的平台实力来帮助他们解决实际面临的问题。
CSDN：对于大规模的故障，融云是否有应急预案？
杨攀：云服务厂商出问题很是常见，即使如微软亚马逊等也不能例外，但值得细细思量的是能有多快的时间去响应和修复，与开发者沟通是否到位？目前，融云正在着手建设双活的双数据中心，已进入部署阶段。这也就意味着即使任一数据中心发生意外，另外一个还可以正常使用，两个数据中心同时出现问题的概率非常小。同时，双数据中心也需要付出双倍的成本，但能为客户提供更高质量的服务还是物有所值，我们对于稳定性的追求是非常苛刻的。
CSDN：融云在GitHub、GitCafe上托管了许多Demo源码，请问在开源方面是否还有其他考量？
杨攀：在高速发展阶段，我们对公司的定位是商业公司，许多内部的东西在自身觉得不够好并本着对用户负责的前提下，还是一个相对保守的态度。截止发稿前，我们已经将 JavaScript SDK 开源，在核心部分已非常稳定的情况下，动用社区的力量来帮助我们继续完善问题，大家一起来找Bug并进行维护，除此之外，我们针对其他第三方平台（如 Cordova、React 等）提供的 SDK 插件也会全部开源。
来源：CSDN