谢乔：BaaS云的发展现状

个人简介 谢乔：现为野狗科技联合创始人兼首席架构师，拥有8年互联网研发经验，在分布式系统、复杂网络开发、服务性能优化等方面拥有丰富经验，之前曾就职于猫扑网、人人网、奇虎360等公司担任高级研发工程师及架构师，期间负责的工作包括猫扑网架构设计、人人无线Quad架构设计、360智能路由器嵌入式平台架构与服务端架构设计等。

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 大家好，我现在在QCon上海大会的现场，今天十分高兴邀请到野狗科技的架构师谢乔先生接受我们的采访。谢老师请您先做一下自我介绍吧？

谢乔：好，大家好，我是07年参加工作，一直从事互联网工作，曾就职于猫扑网，人人网，后来在360担任架构师。我从后端开发一直到前端开发都有做过，然后系统级开发，还有应用层的开发也都做过，我的志向也是要做一个全栈型的工程师。

   

2. 你们现在在野狗科技是做一个BaaS（Backend as a Service）的服务，能不能先简单介绍一下你们的团队？

谢乔：我们技术团队规模并不是很大，从前端到后端，还有运维人员，大概20人左右，我们也保持精英化的路线，用最小的团队做最高的产出，我们核心成员有来自人人网的，有百度的，360的，还有京东的一位高级工程师，还有一些架构师。

   

3. 像您现在主要就是做后端这块？

谢乔：应该是全站的架构。

   

4. 还有好像IOS等各个客户端也都有？

谢乔：对，对于这些我虽然只是略懂一二，但是主要做整个架构的一个规划。

   

5. 那么能不能介绍一下你们现在做的一些事情？

谢乔：都叫我们是野狗实时，我们主打的也是实时这个特性，所谓实时就是做数据的实时同步，它与消息推送模式的最大区别就是，我们做的是云端的一个数据库，每个客户端可以将数据节点的数据进行一个同步的模式。我们这个BaaS云当时做的时候也是受到美国的Firebase的启发，当时我们也是Firebase的一个用户，Firebase被谷歌收购也是对这种数据同步模式的一个认可。同样，竞争的BaaS云有很多，像Parse当时在美国也是和Firebase竞争的一种BaaS云。我们当时出来创业的时候，也想做一种云的模式，从IaaS到PaaS，到BaaS，再到SaaS，然后选一种，其实其他市场都已经饱和了，非常难做，但是对于BaaS这种在国外，应该说是从11年开始兴起，然后现在进入成熟阶段，而在国内算是从前年才开始发展，落后两到三年，国外的一个大型的分析公司做过一个数据分析，分析BaaS市场是每年成倍增的态势，今年15年的总价值大概在17亿美元左右，预计到17年能达到77亿，所以国外对这个也非常看好，所以我觉得我们国内应该抓住这个机会来做这个BaaS云。

   

6. 你刚才提到你们做的主要是数据同步的方式，而且好像最近几个月，你们一直做的也是实现这个数据同步的方式，那么相比数据推送的方式，它在效果上到底是有什么差别？

谢乔：刚才说的是消息推送的模式，这种模式它的应用场景不是非常广，但是它也非常优秀，在市场上也是被认可的一种，因为很多优秀的云在做它们。但它的应用场景非常窄，它关注的是消息能不能及时到达，消息的顺序性，它关注的是消息从一端到达另一端，而并不在乎最终的数据状态。而我们想用的是数据同步这个新型的模式，比较新颖，新颖在哪里？我们提供这个模式，你可以用它去实现数据同步，因为消息在数据层面上来说是一种增量的模式，一直在新增一个消息，新增一个消息，但有些应用场景是数据状态的一种改变，比如说数据底下有一些子数据，成一些关系型，而且这些数据有可能被删除，被修改，被添加，就是它不仅仅是个增量的模式，所以它只在乎一个状态，由起始状态，变为最终状态，一个数据同步的过程。消息推送的时候，也可以将数据状态的修改推送过去，这是也可以的，但是有一点，它有个顺序性，而且它在乎一条一条的消息必须都得到达，这种场景非常适合做聊天，或信息消息推送的模式。但有些基于状态的，它为了高效率，并不非常在乎中间状态的变化，只在乎最终状态，比如说做游戏，我们当时做这个实时云的时候也是考虑到面向手机游戏，或者网页游戏的开发。举个简单的例子，游戏角色的状态，比如它的HP值，由一百变成九十被攻击以后，然后再变成八十，用消息推送就会推送三条，按照顺序到达，那你需要做一个很高效的高可用的消息推送机制；然后我们做实时数据同步，我们只关注你是由一百，然后变到了八十，在这种场景下非常适合，中间状态有可能丢失了，但是为了两端展示性能，我可以最终直接把数据状态同步过去，也节省了网络开销等等这些问题。

   

7. 那数据的层面来说，如果只处理增量的话，还是相对简单的，处理修改好像要复杂一些，那你们实现这个同步有什么难点呢？

谢乔：难点有很多，举两个比较好理解的难点，要做数据同步其实很简单，也没什么太大复杂性，很多厂家和公司都能做。但是你要抓住实时这个点，怎么做到实时？还有一致性怎么保证？一个是要解决实时问题，还有一个要多端都可以修改数据，因为大家都可以拿到这个数据，就是修改冲突这个问题。拿数据实时举个例子，比如说我们很多场景下像游戏这种，很多是对数据状态的一个修改，但这时候，其他端有可能要读取这个数据状态，读取数据状态的时候，拿到的就是这个数据状态的一个快照，咱们怎么能保证读和写，在这个时候是一个实时同步的过程，当一个客户端去读取的时候，有可能其他客户端还在写，造成状态的不一致。这块我们也是参考了很多，把这抽象成是主从同步的模式，就是副本和主节点进行同步的模式，当客户端读取数据的时候，先拿到数据的快照，在拿起快照期间，如果有数据进行了修改，那我们再把数据修改的类似操作日志先保存起来，并且缓存到这个客户端的读，当快照拿到以后跟操纵的队列进行合并，最后产生最终的数据，把它同步给这个客户端。然后还有刚才说到的数据的修改冲突，这也是一个很麻烦的问题，举一种冲突场景，就是当甲乙两个客户端要修改同一个数据A，甲将A修改成A1的时候，乙也将数据A修改成了A2，此时数据是不一致的，然后乙先将A2传到了服务端，这时候甲也将A1也传到了服务端，在这个过程中，甲传完了以后收到了乙的同步数据，就是A2，那甲就变成A2了，甲服务修改成了A1，然后也同步到了乙，那乙就变成了A1，这样就造成了数据两端最后大家都执行成功了，但是数据不同步。我们怎么解决这个问题？有很多人说，那你服务端可以做一个串行的推送同步，这样的话高并发下效率就非常低，所以我们做了一些机制，就是客户端我们加了锁。当某一客户端进行数据修改的时候，把他的数据副本提交到服务端，这时候是锁定状态，这时候收到了其他客户端推送过来的数据修改，保持锁定状态，不予以修改，直到我这边操作返回的时候，再看最终状态，服务端进行一个并行处理以后，得到最终的一个状态版本，然后将最终状态版本返回给刚才提交请求的客户端，最后达到了多端操作同步，数据同步。

   

8. 好的，那么最后我想请您再分享一下接下来的计划吧？

谢乔：刚才说了很多技术性的东西，现在说我们公司这边，其实之前一直我们是2D，就是To Developer面向开发者，也是为了传播我们的口碑，下一步我们要2B的话，我们会提供私有云的一些模式，和一些企业进行合作开发，来帮助提供一些解决方案，尤其是像我们也很看好物联网领域，因为在物联网这块，像深圳这边，组织他们自己的服务端，就像传统的这些物联网，他们去做一些硬件项目是非常快的，但是他们的服务端技术能力比较差，我们会跟他们配合来提供这种垂直解决方案。

InfoQ:好的，那今天十分感谢谢老师接受我们采访。