HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

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

  • 2013-08-16
  • 本文字数:4067 字

    阅读完需:约 13 分钟

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

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

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

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

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

2013-08-16 06:253180

评论

发布
暂无评论
发现更多内容

架构师训练营 - 第12周

袭望

单词匹配算法,算法常见的模数1000000007 模数10 ^ 9 + 7,swift mock URLSession,John 易筋 ARTS 打卡 Week 30

John(易筋)

ARTS 打卡计划 单词匹配算法 swift mock数据 算法中的模数

ARTS打卡 第27周

引花眠

微服务 ARTS 打卡计划 springboot

第十二周 作业2

Yangjing

极客大学架构师训练营

ARTS打卡 第26周

引花眠

微服务 ARTS 打卡计划 springboot

第8周作业

hunk

极客大学架构师训练营

数据应用(一)

wing

极客大学架构师训练营

架构第12周总结

Geek_Gu

极客大学架构师训练营

SpringBoot系列(6)- 测试

引花眠

spring springboot

week8-作业二-根据当周学习情况,完成一篇学习总结

未来已来

架构师训练营 1 期 - 第 十二周总结(vaik)

行之

极客大学架构师训练营

week8-作业一

未来已来

架构师训练营 2 期 Week08 总结

架构师训练营 2 期 Week08 作业

架构师训练营第十二周命题作业

一马行千里

第十二周 作业1

Yangjing

极客大学架构师训练营

架构师训练营第 1 期 - week12 - 作业

lucian

极客大学架构师训练营

架构第12周作业

Geek_Gu

极客大学架构师训练营

第三周总结

胡益

第12周作业

paul

Architecture Phase1 Week12:HomeWork

phylony-lu

第八周作业总结

hunk

极客大学架构师训练营

架构师训练营 1 期 - 第 十二周作业(vaik)

行之

极客大学架构师训练营

ARTS打卡 第25周

引花眠

微服务 ARTS 打卡计划 springboot

第十二周 数据应用(一)总结

蓝黑

极客大学架构师训练营

架构师训练营第 1 期 -- 第十二周学习总结

发酵的死神

极客大学架构师训练营

第3周学习总结

Binary

极客大学架构师训练营

架构师训练营第十二周学习笔记

一马行千里

Week_12 总结

golangboy

极客大学架构师训练营

第3周作业提交

Binary

极客大学架构师训练营

大数据概述

garlic

极客大学架构师训练营

专访365日历创始人葛楠:创业者技术选型的开放与保守_语言 & 开发_涂兰敬_InfoQ精选文章