BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 涂兰敬 关注 0 他的粉丝 发布于 2013年8月17日. 估计阅读时间: 12 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

引言:从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日历的核心技术是什么?具体产品发展过程中遇到过哪些问题?后来是如何解决的?
葛楠:
以前每天的服务器同步达到一千二百万次,如今已经达到了几亿次了。我们对同步的次数需求,和我们同步的轻重,都跟以前大不一样了。所以,数据同步技术相当于是我们的一个核心技术。

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT