创业公司解密谷歌、FB和苹果都盯上的后端云服务：能省几千万创业成本

创业公司解密谷歌、 FB 和苹果都盯上的后端云服务：能省几千万创业成本

 

随着互联网科技的发展，互联网行业的分工也会像其它行业一样逐渐细化，后端服务也是这样被抽象出来，即 BaaS （后端即服务）。在移动后端服务系统（ MBaaS ）中，云服务公司为移动应用、智能设备开发者提供整合云后端的边界服，包括文件数据存储、实时推送、即时通讯等实现难度较高的功能，以帮助开发者快速开发应用。

为什么 Facebook 、苹果和 Google 都盯上后端云服务？

 

物联网时代，在国外 BaaS 服务已经受到巨头的重视， Facebook 收购 Parse 、苹果发布了 CloudKit 、 Google 收购了 Firebase ： Parse 、 CloudKit 、 Filrebase 都是国外知名的 BaaS 类产品，巨头们都希望通过 BaaS 服务来完善生态。在今年三月举行的谷歌全球云用户会议上，谷歌云服务高级副总裁黛安·格林（ DianeGreene ）表示，“这将是一个长期性、永久性业务”。

 

除了国外巨头，国内也有数家创业公司瞄准于后端服务市场。云巴就是这样一种后端云服务产品，主要面向智能硬件提供跨平台、跨设备的实时消息交换服务。

 

云巴 CEO 张虎表示，对于开发者而言，有了后端服务，他们只需专注于具体业务和逻辑的实现，无需关心后端基础设施构建、运维、服务器托管、网络、性能调优等工作。对各巨头来说，则各有各的布局：

 

对于 Facebook 来说，

 

 

在收购 Parse 后，该公司创始人 IIyaSukhar 已经成了仅次于马克·扎克伯格的角色。在这次会议上， Facebook 希望结束应用之间的信息孤岛状态，让不同应用之间的内容能够互通和无缝跳转，于是就发布了一个名为 AppLinks “协议”，但这个协议背后则需要 Parse 这样的后端服务提供数据存储、计算能力、 Push 通知等一系列技术支撑。

 

 

 

但很不幸的是，在激烈的云服务竞争中， Parse 战况不利， Facebook 也于今年初关闭该服务。

 

而对于苹果来说，

 

 

CloudKit 可以提供完善且有弹性的后端解决方案，帮助开发者减轻编写服务器代码和维护服务器的需求。很明显，苹果此举也是为了降低开发 iOS 应用的成本，维护 iOS 生态圈的繁荣。

 

除了收购 Firebase ， Google 还在去年 10 月收购应用开发平台 Divshot ，并将其整合至 Firebase ，使得应用开发变得更为简单。

 

 

就像 Firebase 创始人 JamesTamplin 在博客上说的那样， Firebase 和 GoogleCloudPlatform 可以很好的互补。也许像苹果为 iOS 开发者提供了 CloudKit 那样， Google 也可以利用类似的服务来为 Android 生态圈的开发者们提供便利。

 

归根结底，还是生态系统建设问题。

后端服务解决的是创业公司几千万成本的问题

 

 

比如，做出一个视频的弹幕应用也会困难到要找第三方吗？

 

后端服务出现之前，应用、智能硬件的开发需要为其消息传输、数据统计、储存、实时通讯等功能自行搭建服务器架构，包括搭建数据库与服务器集群等等。但是，产品本身和互联网基础工作关系不大，这些工作属于产品企业的非主流业务，不仅复杂繁重，消耗的经历和资源过多，并将拉长产品最终走向市场的开发周期。张虎透露，一个不熟悉后端服务的应用或智能硬件创业团队，如果要自建后端服务，投入 30 人左右也需要耗时两到三年才能完成，而且效果未必能够专业，比如出现通讯延迟、消息发送成功率较低等。比如，某些通过蓝牙传输的智能手表，在实时显示上存在大约两秒的延迟。而这些投入——包括租用服务器等，甚至要耗费数千万人民币的成本，使得非主流业务成本还高于主产品。

 

所以，除了包办后端搭建，后端服务更重要的是解决效率问题——双向通信、数据采集和统计等过程的快速和稳定。以实时通信功能为例，张虎解释称，在一个家庭的智能水网系统中，后端服务可以实时采集每个感应水流的传感器的数据，然后分析每一段管道的水流速、流量，来达到监测水流是否泄漏的目的，同时可将结果发送到 PC 、手机端。如果发现水流速度和流量数据异常，那么系统可定位找出泄漏的部位。根据传感器的密集程度，最高可定位到米级范围。又比如说，智能儿童手表的对讲功能，一端的用户发出的音频首先经过服务器转录，再到达另一端设备接收，等等。

 

在这些场景下，信息传输的速度和稳定性成为了决定设备服务性能好坏的关键因素。张虎表示，如今智能硬件早已不限于手机、平板、可穿戴的范畴，也加入了机器人、智能家居等等，面对逐渐增长的场景和海量数据，降低通讯延迟、保证推送稳定等提高通讯效率的做法就成为了后端云服务的主要任务。目前，国外顶尖的水平是， PubNub 公司创造的全球网络范围内最大 250 毫秒的延迟，相对而言，云巴面对国内网络则做到了 60 毫秒以内的延迟（注意是国内网络）。

智能硬件与移动应用后端云服务有何不同？

 

以往，后端云服务主要针对于应用，张虎在创立云巴前，就主导创立了专注于为移动 app 提供后端服务的极光推送。而随着物联网和智能硬件的兴起，属于张虎第二次创业的云巴则针对智能硬件的实时通讯领域。

 

张虎表示，对比移动应用，智能设备开发对消息延迟更加敏感，对流量功耗上要求更高。在云巴的客户中，主动申请付费服务的更多来自于智能硬件用户。“移动应用的使用门槛较低，损失代价较少，消费者和开发者对其的期望较低。智能硬件不同，每一件产品都需要一定价格或成本来生产、买入，如果因为功能服务表现不佳，则更容易引来消费者的投诉，智能硬件商为了保证产品体验，宁愿选择付费。两者的差异是互联网的产品特点决定的。”这些选择付费的客户，云巴会为其提供通信的独场通道。

那么问题来了： 60 毫秒的通信延迟是如何做到的？

 

张虎表示，目前两个终端之间的通讯需要经过网关、路由等组成的二三十次跳数，那么保证消息的准确发送、快速发送，就需要减少网关的跳数，且突破单机限制。张虎表示，除了给付费用户提供独场通道这样的普遍模式，云巴做得更多的是“细活”，从架构上进行调整。

将服务器分成多个集群

 

“也许我们都发现一个有趣的现象，一般游戏房间、聊天室等等一般最多容纳 300 或 500 人，这个特别的数字主要来源于：对一台服务器来说， 300 人的数据量是能够维持较好体验的水平。”张虎表示，一个架构的设计，即物理基因已经决定服务器的最佳容量，“但我们可以想办法突破这个单机限制，把数据分布到不同的服务器上，让通讯终端突破 300 人的限制。”

那为什么不可以把服务器变得更强大？

 

“其实最理想的方式也是把通讯降低到一跳，即所有任务在一个服务器完成然后发送，但这样有一个悖论：当把一个服务器做到强大时，一旦这个服务器出现问题，那么所有服务都将失效。”为此，云巴把服务器按照业务逻辑分成若干集群，当一个集群由于压力或者其他一些因素导致服务出现问题，那么另一个对等的集群就可以替代顶上，使服务稳定下来。

 

据悉，云巴目前使用的 Cache 集群是 Couchbase 集群和 Redis 集群。其中 Couchbase 可以让数据自动在多个节点备份，单节点小，不会影响业务，而且支持业务自动分片 (autosharing) 。所谓自动分片，就是把同类型的业务自动分配到不同的机器上。

Erlang 语言支持大量并发

 

每一个优秀的产品除了技术上的完善，还需要根据业务场景的打磨细节，根据细节做出一些取舍。比如，语言方面，云巴选择了非常冷门的 Erlang 语言。

 

Erlang 是一种面向并发和消息的函数式编程语言。 Erlang 设定的是竞争式的协程，在 Erlang 编程语言中， Erlang 进程是并发并且独立执行的，轻量并且有自己的堆栈空间。也就是说，每一个 Erlang 进程完全是私有的，两个 Erlang 进程之间的堆栈空间不会被共享。这就好比高架桥和并行的车道，相互是独立的，不能窜道，这样很大程度提高了运输的效率和速度。

 

对比 C++ 、 Java ， Erlang 只在一个小圈子内流行，但是，将线程放在用户空间内自行调度（协程）是为了获得尽可能大规模的并发能力，与 go\nodejs 的协作式不同，竞争式的决策则为大规模的多人开发提供了保证，避免某个协程的死循环或过量运算影响其他任务的进行。同时， erlang 维护和开发了一整套中间层工具 OTP （一次性可编程），而这些工具、框架也正是被用来开发诸如分布式服务器、错误处理、数据库等应用的利器。 Erlang 不提倡防御式编程，它认为程序既然遇到错误就应该让它崩溃，这样一旦出现错误就可以第一时间被发现，加以补救措施，可以将损失降到最小。