引言:从 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 日历的核心技术是什么?具体产品发展过程中遇到过哪些问题?后来是如何解决的?
葛楠:** 以前每天的服务器同步达到一千二百万次,如今已经达到了几亿次了。我们对同步的次数需求,和我们同步的轻重,都跟以前大不一样了。所以,数据同步技术相当于是我们的一个核心技术。
从第一天开始,我们就在开发自己的同步技术,只不过当时自己开发的更轻量级,很容易实现的同步技术。不过,同步技术在不同的阶段,它的演变是不一样的。同步技术开发的复杂度也在逐步增大,包括支持我们现在这种同步机制的客户端的代码量,需要的资源,支持的算法以及支持的数据结构等。另外,同步技术也是受到带宽的影响就比较大。
以日期的重复为例,举例说明一下同步的复杂度正在逐渐增大。当初,我们可能只支持每月的几号,每周的星期几,这种级别的就够了。但是随着我们产品的发展,后来需要支持每个月第几个星期几,每个月的第几天,或者每隔几天,或者是包括农历的日期等。这些数据变得复杂起来之后,数据量自然就变大了。这也是为什么说同步技术开发现在比之前重的原因。
而且,我们支持一个人有多个日历,就是一对多。而且,我们的日历是支持多人使用的,就是多对一。就是一个日历允许多人往里填,它里面的权限关系就更复杂。然后现在的管理者,将有不同的权限创建给管理者、编辑者、普通的收藏用户,这些功能加上你在同步的时候的协议,它们使得这些信息的字段或者是你处理的方法就会越来越复杂。
很显然,用户少的话自然同步数就少,用户多了以后,同步数自然就大了。数据同步的协议一开始我们自己写,但是一开始写得不完善,考虑的不周到。同步协议还是有很高门槛的。后来就去借鉴国外开源社区一些同步协议的经验,参考它们的源代码,去把自己的思想融入进来,重新改写成我们自己的协议。
评论