专访365日历创始人葛楠：创业者技术选型的开放与保守

引言：从2008年开始，365日历开始上线运营，不知不觉到现在已经五年了。目前， 365日历在国内已经拥有超过6000万用户，从App Store上看，市场综合排名最高时是47名。

近日，InfoQ编辑采访365日历创始人葛楠，请他谈谈365日历如何将自己打造一个符合中国人需求的日程管理服务。

嘉宾简介：葛楠，80后，365日历创始人，北京理工大学计算机软件专业，没有海外留学经历，大学期间就在一些公司兼职、编程序。毕业之后并没有马上做365日历，而是创业做软件外包业务，两年后与北京理工大学的校友投身于一个传统行业的项目里。折腾了一圈，还是在2008年有感于互联网的高速发展，又重新回到互联网行业。

InfoQ：首先，能否介绍一下365日历的团队情况？
葛楠：365日历初始团队起初是我和两个学计算机的同学创立的。创业之初，我们的核心的成员都是学生，或者工作一两年，外包时候的合作伙伴，没有什么特多工作经验。后来又进了一些，有几个理工大学的校友，我们就开始编写代码。所以，我们团队也非常草根，感觉完全不是明星团队。

但是，我们的团队成员都是我自己一个一个去精心挑选，有潜力的人才加入我们的团队。他们大多是学校计算机系、软件工程系，而且是那一级的传奇人物，不一定是学习特别好，但是他一定很能折腾事，编点东西。早期的核心程序员都是技术方面的，或者参加一些比赛，获过一些奖。例如，像我们比较核心的Android的开发者，毕业的时候跟我们一起创业，他在校期间得过ACM世界冠军。

现在来看，40多人的团队，有20多人从事开发，当初一起创业的团队成员如进大部分都在。我的理念是希望做一个小而精的技术团队，但是未来会发展成什么样，还是要看一步往前走。

InfoQ：为何选择日历来创业？
葛楠：当时的想法，我们没有太多创业经验，团队经验不足，不适合选择一个竞争特别激烈的正面战场去创业。我们当时的正面战场，如浏览器或播放器，这些在当时已经竞争很激烈了。

选择日历作为创业的方向，我们经过了深思熟虑。日历是一个基础应用，用户基数大；从日历可扩展的方向很多；国内没有好的日历服务平台，我们有机会做到最好。

用户基数大的应用很多，为何定位在日历？这背后还有一个背景就是，记得当时我先看Windows系统上自带哪些软件。我当时的看法是，Windows上自带应用肯定都是大用户量的，否则微软不会把它集成上去。Windows自带的有浏览器、播放器、输入法等，还有记事本，还有计算器，还有日历等。

当时在做日历的时候还是犹豫了一下，日历简单看是一个个标识日期的格子，但从长远来看我觉得是一个日期的索引，那么它未来的空间是非常大的。我们联想到以前，一个挂历挂在墙上，里边其实嵌入了很多内容，有菜谱、生活小常识之类。甚至有人拿台历当日记本。

初步选的是日历，然后我再去做验证。我认为，所有网址站首页上的链接应该是拥有最大用户量的应用，看到HAO123当时是最活的网页，上面都有万年历还有日期，我们就确定，日历这个方向是对的。而且在评估一下当时市场上一个格局，确实没有什么特别强的日历软件。而反观GOOGLE，利用到了云的服务在国外做得也非常好，所以我最终选择做日历。

同时，我们选择日历作为创业方向主要基于以下几点考虑：首先要选择互联网行业。因为互联网是朝阳产业；另外，我也有一定的技术背景；第三就是我个人经历了一些传统行业之后，我觉得我个人性格还是更适合互联网比较阳光的产业，这是未来有大发展方向。

在365日历技术实现的过程中，我的理念就是最终的服务和数据一定是在云上。我们觉得所有的数据首先要在云端来存储，那就要在云端架底层技术架构，然后编写算法。既然所有数据在云端，最终要存储在云端。当时的客户端有几种技术方案选择，一种是做一个本地的，Windows上做一个VC架构的东西，然后去做同步。我们选的是另一种，等于是用VC的壳，然后套一个Web的框架。

一开始我们所有思路一定是跟云端做数据同步的。所以架构就是云端，底层云端的网站，云端的应用服务器，这边是客户端，然后客户端技术的选择。我们是做VC结合的Web的这种架构，这样既能方便灵活地开发，然后又能解决所有数据都在云端这个问题。

InfoQ：365日历主要的用户群是如何定位的？
葛楠：2008年的情况是，只有我们一家在认真地做这个领域。因为日历分着几种，不同的人他对有自己不同的认知。普遍有三种认知：第一种，最多人的群体认为日历就是看日期，然后上面有一个星期几，有个几号就OK了；第二种，一部分中国本土的用户，尤其南方人居多，认为日历就是万年历，上面有农历、有节日、有节气；第三种，一些高端商务人士，从美国引出来的日程管理需求，他们认为日历，尤其是手机上的日历就是日程表加上日程管理。

而我们希望做得是第四种认知，我们想再把日历的概念给他颠覆掉，重新做创新。所以，即便是国内市场有很多人做日历，实际上是面对第一种人、第二种人，他就做一个能够看日期的日历，一个普通的技术人员就可以把它实现，就算是想做一个万年历也不算难事。所以来看，现在市面上充斥了无数的日历和万年历的应用，它们只是画了一个格子写上日期，技术上没有什么特别难实现的。

从2008年开始，我们当时以谷歌为目标做日历。我们最早的一批用户，包括智能手机的用户，都是高端商务人士，他们对日历的需求更倾向于欧美的程管理的需求。在云端，你要只做一个简单的日历就是一个客户端软件，安装上去就可以运行。我们现在云端的技术能达到Google Calendar的95%，它95%的功能我们都是支持的。

相较市场上越来越多的日历类应用，365日历的拥有很多互联网的特色服务：例如，用户的数据都安全存储在云端，数据永远都不会丢失；建立共享日历，与亲朋好友一起分享等。未来，我们还会开放公众日历，让每个人每个组织都可以建立自己的日历让大家来收藏。

其他的团队都是在做，就像万年历，或者是说普通的一个简单日历。只有我们一家是从云端、底层的技术在做各个终端的的数据同步，各种底层的算法。而且我们已经做得是非常专业了。

InfoQ：365日历开发时候的技术难点是什么？解决方案是什么？同时，您是如何选择技术合作伙伴？
葛楠：2002年的时候，互联网刚刚起步，当时我还在上大学，我就认为以后所有东西都是在云上。我是学软件的，当时比较擅长的技术是Java、J2EE。J2EE这一套就是在服务器上很完整，很早就受这个思想的影响，认为以后所有的东西都是可以在云端完成的，然后客户端来用。但是在2008年之前，云这个概念，还没有变成现在一个大众所这么了解的一个概念，基本上是在技术人员的思维之中。

其实365日历的这个技术难点，相对来说，虽然比不上某些应用，但它的底层技术还是非常复杂的。我们已经做了两年多时间，这种积累在国内当时是没有的。例如，365日历在开发中使用业界主流的技术框架，比如Java作为主要的开发语言并使用Spring框架，使用nginx/lua处理通知更新等调用频繁的接口，在后端用MySQL/redis做存储并辅以FusionIO来提升系统性能。我们全部的解决方案都是基于例如Spring/nginx_lua/haproxy/redis等成熟的开源项目，同时结合产品特点，从提高产品迭代速度和减小运维成本的目的出发，比较多的使用了第三方提供的商业化服务，如百度的BAE以及又拍云作为图片存储。

特别是在面对一些突发大流量的场景，比如临近节假日时用户对于节假日的查询会N倍于平时，使用了百度的BAE的弹性云计算特点就比较好的解决了这方面问题。

从365日历一开始创业，我就预感到云服务这东西未来一定会大势发展。所以，当百度云推出云服务的时候，我们就开始接触百度云服务了。我们百度云服务有很多了，目前365日历应用到的百度云服务包括地图、存储、推送等都在用。

在我们选择技术合作伙伴的时候，我们有一些考量。类似的云服务其实其他公司也能提供的，但是始终有一点担心，小公司可能从婴儿长不到成年就夭折了。与百度云合作，至少没有这种担忧。另外，百度云有一个好处，与百度云的功能结合的比较好。例如百度云存储。而且，百度也能为365日历带来一些福利，比如说在百度搜各种日历,被搜索出的都是我们，这也是一种合作关系。还有我们因为早期用了它的一些服务，比如国家，他之前有一个，从国家的扶持资金，就是通过百度去支持一些小企业，我们也获得那种支持。

InfoQ：您觉得365日历的核心技术是什么？具体产品发展过程中遇到过哪些问题？后来是如何解决的？
葛楠：以前每天的服务器同步达到一千二百万次，如今已经达到了几亿次了。我们对同步的次数需求，和我们同步的轻重，都跟以前大不一样了。所以，数据同步技术相当于是我们的一个核心技术。

从第一天开始，我们就在开发自己的同步技术，只不过当时自己开发的更轻量级，很容易实现的同步技术。不过，同步技术在不同的阶段，它的演变是不一样的。同步技术开发的复杂度也在逐步增大，包括支持我们现在这种同步机制的客户端的代码量，需要的资源，支持的算法以及支持的数据结构等。另外，同步技术也是受到带宽的影响就比较大。

以日期的重复为例，举例说明一下同步的复杂度正在逐渐增大。当初，我们可能只支持每月的几号，每周的星期几，这种级别的就够了。但是随着我们产品的发展，后来需要支持每个月第几个星期几，每个月的第几天，或者每隔几天，或者是包括农历的日期等。这些数据变得复杂起来之后，数据量自然就变大了。这也是为什么说同步技术开发现在比之前重的原因。

而且，我们支持一个人有多个日历，就是一对多。而且，我们的日历是支持多人使用的，就是多对一。就是一个日历允许多人往里填，它里面的权限关系就更复杂。然后现在的管理者，将有不同的权限创建给管理者、编辑者、普通的收藏用户，这些功能加上你在同步的时候的协议，它们使得这些信息的字段或者是你处理的方法就会越来越复杂。

很显然，用户少的话自然同步数就少，用户多了以后，同步数自然就大了。数据同步的协议一开始我们自己写，但是一开始写得不完善，考虑的不周到。同步协议还是有很高门槛的。后来就去借鉴国外开源社区一些同步协议的经验，参考它们的源代码，去把自己的思想融入进来，重新改写成我们自己的协议。