写点什么

专访 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:253165

评论

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

云图说|AppCube零代码,开启无码新生活

华为云开发者联盟

低代码 零代码 华为云 企业号十月 PK 榜

需求吞吐量半年提升 65%,500强企业这样做|ONES 研发管理大师课

万事ONES

@全体开发者, 华为云1024程序员节精彩开启!

华为云开发者联盟

华为云 企业号十月 PK 榜

质量切入点都在哪儿呢?

QE_LAB

质量保障 敏捷精益

前端编程培训学习就业有前途吗?

小谷哥

时间复杂度与空间复杂度

lovevivi

c 数据结构 10月月更

C# Timer控件学习,使用Timer解决按钮幂等性问题

IC00

C# 学习 程序员 上位机 10月月更

ThreadLocal 源码分析-扩容和get方法

zarmnosaj

10月月更

社招前端经典手写面试题合集

helloworld1024fd

JavaScript

K8S 故障排错新手段:kubectl debug实战

BoCloud博云

容器 云原生 k8s

web前端开发培训学习合适吗?

小谷哥

大数据开发培训机构有哪些?

小谷哥

从零手写react-router

helloworld1024fd

JavaScript

vcluster -- 基于虚拟集群的多租户方案

Se7en

Kubernetes 云原生

一句口诀教你辨别索引失效七大场景

华为云开发者联盟

数据库 后端 索引 华为云 企业号十月 PK 榜

将 NGINX 部署为 API 网关,第 2 部分:保护后端服务

NGINX开源社区

nginx 安全 Backend Developer api 网关 模块

js 和 css 是如何影响DOM树构建的?

CoderBin

CSS JavaScript 前端 DOM 10月月更

数据结构学习,数组和数组矩阵的三种压缩

IC00

学习 数据结构 算法 学习笔记 10月月更

链表专项之环形链表

lovevivi

c 数据结构 10月月更

数字化的一切都会在安全沙箱里面

FN0

云计算 安全性 沙箱

长安链源码分析之网络模块 net-liquid(4)

前端培训学习好就业吗?

小谷哥

音视频开发进阶——YUV与RGB的采样与存储格式

ZEGO即构

音视频开发

上干货 | 园区智慧物联管理解决方案

AIRIOT

物联网 智慧园区 低代码开发 园区解决方案

Vue组件入门(九)v-model 自定义修饰符

Augus

Vue 3 10月月更

从零开始实现一个Promise

helloworld1024fd

JavaScript

开源依赖管理的最佳实践

SEAL安全

开源许可证 开源安全 软件供应链安全 开源安全与治理 10月月更

AntDB数据并行加载工具的实现

亚信AntDB数据库

大数据 AntDB AntDB数据库 企业号十月PK榜 企业号十月 PK 榜

重磅来袭 | 尚硅谷数据湖Hudi视频教程发布

小谷哥

MobLink Android 快速集成

MobTech袤博科技

Gradle sdk moblink

EasyNLP发布融合语言学和事实知识的中文预训练模型CKBERT

阿里云大数据AI技术

深度学习 开源 语言模型 企业号十月PK榜

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