从MVP到IPO,HotelTonight是如何扩展他们的技术栈的

目录


亮点

最简可行产品(MVP)

不到两个月,这个团队就开发了一款App,他们用了Titanium框架并大量使用CoffeeScript语言。

不到两个月,他们就搞定了从Rails后端到酒店管理库存和员工接口所有这些东西。

不到两个月,他们就能快速上线,推向市场的速度相当快。

我想那时候他们在iOS和安卓 App上用了HTML5jQuery。最终在接下来的几年中,成立了iOS和安卓团队,成员都是非常棒的专家,把这些App转成了原生App。

当前栈

在原先的基础上逐步开发出更多的Rails应用并且开始转向Go语言,来整合一些微服务 ...

你需要把信息从传到另一个地方,为了避免把代码都堆在一起(我们一直在尽量把它们分开),何不试试类似Go的技术呢?

Node.js是另一个我们开始投入的平台… 我们已经有了一个App(给酒店的),它是个面向用户的桌面和移动网络App,但不是原生本地App,它用上了React以及Node与Rail的组合。

可扩展API

回到2014年,我们只提供当天的酒店预定服务。用户只能在当天预订酒店而无法提前预定。Hotel Tonight干的事儿就是在早上九点给所有的客户推送通知,这简直是个自找的DDoS。 9点的时候你会突然看到一个流量高峰,用户们都蜂拥而来看看有啥好东西。

数据库的难题

然后我们开始找技术栈当中的瓶颈到底在哪,扩展性很差一定有原因。其中一个瓶颈是MySQL...然后我们就开始尝试不同的技术。Elasticsearch引起了我们的注意,于是探索了一下,现在已经把Elasticsearch用到了我们的技术栈。然后我们在MySQL上做了一个无模式的附加存储系统,基本上和FriendFeed差不多... 

于是我们可以水平扩展到更多的分区分片上,还让它变成无模式的。由于保存了同一个房间或者条目的不同版本,你不会覆盖哪怕其中一行,因为其实你只是在给它创建不同的版本而已。

展望

我们在Rails模型中远离了很多人陷进去的“回调地狱”...下一步我们要做的是事件流处理。所以接下来,当一个用户改变了某个属性并且系统的其他部分需要知道这个变动,之前我们只是简单地用5个或者10个回调给实现了,现在我们在评估KafkaKinesis


Siraj:你今天过的好吗?近况如何?

Jatinder: 很不错,简直不要太爽。这个季度才刚刚开始,我们要为Hotel Tonight开发很多新功能,所以感觉非常棒。

S:不错哦。你是否有一种每天都坚持的生活习惯,让你醒来后能迅速进入状态?

J:我一般都起得很早,所以常感到能量满满。没错。我通常要做的第一件事是上 New Relic看下性能,昨天情况怎样,我们平均的响应时间是多少,我们95%的响应时间都在核心API上。在公司里,经常有封发送给每个人的邮件——“嗨,公司怎么样啦?我们在这块业务上做的如何?”每天都看一看这样的邮件对我们是一种很好的提醒:在这儿,我们肩负着使命。

S: 谁来发那封邮件?

J: 它是一封自动发送的邮件。我们使用一种名叫Looker的分析工具,用于RedShift等数据库的顶端,你可以发送定时的报告。那封邮件是每天都定时发送的。

S: 就我个人所了解的和你刚才所说的来看,你在这的干相当不错。我们现在有了Equinox,在旧金山有了Hotel Tonight,上下班也方便,各种好事儿。是什么让你涉足计算机的?是什么促使你决定踏入编程领域的?

J: 很早以前,编程世界就让我感到兴奋。90年代的时候,你想上个网还得先连上电话线拨号,想听首歌得等20分钟甚至更久。那会儿还真挺有趣的。港真,编程从一开始就让我着迷,而且从那以后我接触了C和Unix入门,就更喜欢这个领域了。

S: 听程序猿聊他们当初干活的用的那些语言是一件很有趣的事, 而且仍然一定的参考价值,并且它们仍然是最好的。但现在我觉得你一定有不同的感受了,你现在一定不会再觉得C是种必选语言。

J: 当然。我觉得没什么是放之四海而皆准的,特别是当公司的情况不尽相同时。如果这个公司刚刚起步,C就不太合适,技术路子不对。就拿Hotel Tonight和我工作过的一些创业公司来说,Ruby on Rails就很适合你在初创阶段使用。最终你可能遇到一些具体的难题,这时类似C一样的工具就很给力了。现在这方面比较火的可能是Go。选择什么工具还是要看你手头的工作。

S: 有道理。我们从职业方面谈一谈吧,关于Hotel Tonight。你为什么选择Hotel Tonight呢?你有丰富的经验,你可以想去哪儿就去哪儿,但你还是选择了这里。

J: 嗯。关于Hotel Tonight,我最喜欢的一点是开放的环境。在Hotel Tonight,工程师们在全盘业务上都具有举足轻重的影响力。看一看刚才说过的“每日一信”,然后围绕它去做一些具体的事情,而不是仅限于看到而已。这是我从一开始就发现的东西。我在消费领域已经工作了大概10年,曾经为好几家创业公司工作……

S: 作为一名程序员哈。

J: 在来到Hotel Tonight之前,我在一家名叫MUBI的公司工作。我是它的创始工程师之一。我在那儿工作了8年左右,我意识到,“工程”可不只是写写代码那么简单的。那会儿我把Hotel Tonight看成另一个创业公司,其实从人数和规模上来讲并不算是,但从内部运作上看,它的确还处于初创状态。大家都很开放,每个人都能做点什么,对它产生一定影响。港真,这就是我两年前加入Hotel Tonight的原因。

S: 有点意思,开放性对你来说很重要。我们来谈一谈工程师文化吧,假使你团队的一名工程师有个好点子,那么他或她实现这个想法的过程是什么样的呢?

J: 好的。拿我自己来说吧,在这里我想到过很多点子,而最关键的是你得证明这些点子能行得通。我觉得创新有两种类型。第一种是技术创新,你可以改进相关的工具和技术。第二种创新的意义在于,我们还要学会从中赚钱。两个重点:你的点子是否有特点,这个特点是否适合。不同人的想法迥异而庞杂,把它们乱糟糟地拼在一起可不是个好主意。

说回点子,验证的方法很简单,就是看能不能帮助我们的客户。移动App网站上的客户都是想预订酒店客房的人。酒店是供应方。在我们现有的框架内如何工作?我们做的是一个移动应用,我们只着眼于移动设备。我们在iOS、Android平台和移动网络上工作。你可以看一下我们的产品,它非常简洁。我们是如何保持这种简洁性的?当你有一个点子时,你必须把它搞清楚。

S: 明白了,很棒。这个听起来像是一种DIY文化,想到什么点子首先要去做,如果它是行之有效而且有利可图的,那么自然能成。

J: 没错

S: 酷。那么在工程团队方面,你们这里的结构是怎样的?你们采用小团队还是大团队形式?

J: 我们一贯坚持小团队形式。我们坚信一个项目的组员不应超过5人或6人。不论我们开发什么项目,我们的团队都是这个特点。结构方面,我在Hotel Tonight领导是平台团队。平台团队和后端基础建设类似,如API。我们依靠这支团队来处理所有基于网络的产品。其中有包括iOS和Android在内的移动端团队,有质量管理团队,以及产品团队。这涵盖了工程范畴的内外,包括供应、市场、金融等等。

S: 明白了。其中共有多少名工程师?

J: 大概有40名工程师,包括移动端、质量管理和平台在内。

Yonas: 最大的团队是什么?

J: 平台是最大的团队之一,现在有大约十四五人。

Y: 嗯嗯,Android和iOS也是分开的?

J: Android和iOS也是分开的,没错。

Y: 有意思。

S: 你觉得目前什么平台吸引力最大?iOS,Android还是网页?

J: 对我们而言,肯定是iOS。在2010年我们刚开始做Hotel Tonight时,我们就用的iOS。但我们也一直在寻求Android和移动网页方面的机会或合作伙伴。

讲一个小背景,去年9月还是8月,我们推出了一个基于移动网页端预定酒店的产品。那时,你只能在iOS或者我们的Android应用上订房。之后,你就可以在任何移动设备上预订了,但它也还只能在移动端使用。

S: iOS版最初发布时你就在这里了吗,还是你来之后的?

J: 那是我来之前的事了,但我可以根据自己的听闻给你讲一点背景故事。

S: 嗯嗯,MVP那时是什么样的?

J: 行之有效,它是那时候的最佳选择。在两个月内,团队就发布了一款应用。我觉得他们使用的是Titanium开发框架以及大量的CoffeeScript语言。

S: OMG…

J: 这个团队只用了不到两个月的时间就开发了一款App. 我想他们用了Titanium框架并大量使用CoffeeScript语言。

不到两个月,他们就搞定了从Rails后端到酒店管理库存和员工的接口的所有东西。不到两个月他们就能快速上线,推向市场的速度相当快。当时就是这样子的。我想那时候他们在iOS App和安卓上用了HTML5jQuery。最终在接下来的几年中,我们成立了iOS和安卓团队,成员都是非常、非常棒的专家,我们还把这些app转成了原生本地App。

S: 厉害。而且现在都是这种运作方式吧。我对数据存储十分感兴趣。我知道你们的平台各不相同,那么你们都是如何存储数据的?

J: 近年来这方面有了一些进展。我们刚开始做的时候,还只是一个基于EC2实例的MySQL数据库。这几年过来已经改进了很多了。但我们还在用MySQL,这是我们居家旅行必备的存储平台,不过改进了很多以支持更多分区、更多影子系统。我们用到的其他存储方式有ElasticsearchRedisMemcached。种类不尽相同。有些是永久性存储,有些是缓存。我们使用了许多队列系统。IronMQ是我们用于执行服务通信间的必备工具之一。对于ETL来说,我们用RedShift 来完成数据入库存储,我们还使用其他数据库(如Postgres)来做地图支持。

MySQL是大部分东西的起点,就像我说的一样,当你在扩展存储时存储状态很难搞定。你可以水平地扩展你的App服务或者网页服务,但存储永远都是最终的难题。在这个方面,我们一直致力于把单个数据库升级为能够处理栈中单点错误的,其中的一个手段是MySQL。

S: 现在你们有了很多点可以出错。。。

J: (笑)

S: 这真的很棒,虽然你们对于不同的东西有不同的专门数据。通常要么是这个要么是那个。你们在处理存储和检索方面用什么后端语言?

J: 我们很大程度上依靠Ruby on Rails平台。这也是我们在2010年编写第一个应用时用到的东西。

Y: Appcelerator上的第一个程序?

是的,API的后端和酒店界面。但渐渐地,我们在原先的基础上开发出更多的Rails应用并且最近我们开始转向Go语言,用来整合一些微小的服务 ... 你需要把信息从一个传到另一个地方,所以为了避免把代码都堆在一起(我们一直在尽量把它们分开),我们何不试试类似Go的技术呢?关于Node.js和其他我刚刚提到的移动平台,Node.js是另一个我们开始投入的平台… 

Y: 你觉得Ruby的代码库占比是多少?

J: 我认为至少是80%。

Y: 全部API都是Ruby?

J: 对的。

Y: Objective CJava呢?

J: Objective C和React,也是移动网页端应用。我们为酒店开发的那个App用了React。

Y: 你们开发了一个不同的旅店应用。

J: 没错,我们开发了一个旅店应用。它确实是一个面向消费者的桌面和移动网页应用,而不是一个原生本机应用。它使用了React和Node与Rails的组合。

Y: React, Node and Rails, 这样子。

S: 你觉得Go怎么样?我非常喜欢Go,你也一样吗?

J: 还是那句话,用什么工具要看你做的具体是什么。Go可以胜任许多工作,但如果我们要写一个CRUD应用,那我肯定是不会用的。

S: 看来你是JavaScript的忠实拥趸了。

J: 我喜欢用Rails之类的工具来做简单的CRUD App。如果你有专门的需要或者你想从不同的地方快速调用数据时,Go是个很好的选择。你不想让垃圾回收或者多层框架碍事吧,所以这时你会好好考虑用Go。

S: 我喜欢你在划分不同问题以及利用技术解决具体问题上的细致。最近你有没有解决掉某个很难的工程问题?

J: 这方面我有很多可讲。从第一个开始吧,2014年,我们只提供当天的酒店预定服务。作为用户你只能在当天预订酒店而无法提前预定。Hotel Tonight干的事儿就是我们要在早上九点给所有的客户推送通知。 这简直是个自找的DDoS。 9点的时候你会突然看到一个流量高峰,用户们蜂拥而来看看有啥好东西。这个事件很有趣,因为数据库会因此承担很大的压力,而那时候我们的缓存非常有限。

S: 这是那个推送消息的导致的,还是因为用户们开始用App?

J: 看到了那个推送消息,他们所有人都同时进入了应用,而结果表明我们没有一种能为所有人同时服务的算法。我们要考虑多个因素,最后呈现给用户某些酒店,而不是一下子给他们几百个选择。我们只向他们显示15个酒店。对用户而言,地理位置是最重要的因素之一。在洛杉矶和在旧金山的用户在这个应用里看到的搜索结果是不同的。这意味着,驱动不同位置用户的API的缓存能力是有限的。

那是个很有意思的挑战。像7月4号,纪念日周末这样的大日子,人们会打开App。特别是越来越多的人会在同一时刻打开它,所以这是个不小的挑战,也很有趣。我们引进了一种叫Fastly的服务。有些API没法长时间缓存,但我们开始在很短的时间内开启某个API缓存。比如缓存驱动宾馆列表的API很短一段时间而且这个缓存还取决于用户的位置。

Y: 你可以做地理定位。

J: 是的

Y: 基于地理位置用Fastly做缓存。

J: 是的。我们非常喜欢Fastly。我过去用过Varnish。它提供给你的那种计算能力,边界缓存等等……如果你可以通过类似Varnish的东西来解决某个问题,那么你当然可以使用。那时还有其他一些缓存效率高得多的API,我还记得当我们使用了Fastly后,我们成功削减了3倍或4倍的服务器,仅仅是因为使用了Fastly。

Y: 是响应时间吧。

J: 不是的,是服务器数量。至于响应时间……Fastly的相应取决于进程的有效载荷大小,我们见过响应时间是40ms的,也见过30ms的,这也取决于用户所在地。网络节点与我们的用户所在地之间具有很大的一致性。

另一方面,API请求需要通过整个软件栈。它要通过所有的负载均衡器,Rails和所有数据库。

Y: 核心应用托管在哪里?

J: 我们最近开始迁移到AWS上。我们曾经使用一种带有Engine Yard服务器的平台。我们使用AWS已经有段时间了,主要放页面容器和后台容器。我们迁移到AWS以后开始使用ECS,Amazon EC2的容器服务。

我们用docker打包App之后用ECS运行,有点像某种容器调度服务。这种转变也非常棒。

S: 哈,我们又绕了回去,这听起来也蛮有趣。回到Fastly,你们当时减少了Engine Yard的服务器数量,对吗?

J: 对的。

S: 当你们引入了Fastly时?

J: 是的。

S: 你们认为Fastly工作的怎么样,那个决定是如何做出的呢?整个过程是怎样的?

J: 那是一个相对简单的过程。我想我们的工程团队里有一大批Varnish的粉丝。我们见识过Varnish的力量。另一方面,我们也一直在努力去掉自托管工具。比如,我们曾在EC2实例上托管MySQL。我们后来不再这样做,转而开始使用RDS。类似地,我们当时在为Varnish寻找服务。有没有什么东西把Varnish作为一种服务提供?Fastly就是一个答案。我们当时四处找寻过。

Y: Google查一下。上StackShare看看。嗯我喜欢它。是你们内部原本就有人听说过Fastly并且说“我们应该用Fastly”,或者有考虑过别的选项吗?

J: 我想我们最后还是留在Fastly上,一开始讨论过CloudFlare不过支持Fastly的人也不少。但是我觉得一般来说,当我们评估工具时,就又回到了那个老问题:如果你有一个想法,你应该怎么做呢?让我们动手证明它可行吧。我们注册了一个免费试用,看看用Fastly能做出什么来。其实它如此简单,我们只需要改动我们的Route 53的DNS来指向Fastly以及改变TTL,在响应里指定TTL或Cache Header。这就可以了,没用几天就上线了。

Y: 你们开始分流这些请求,你们没有做一个自动化的(工具)……或者通宵干活。

J: 没错。我们开始转出一些不太重要的用户流量,一开始是想确保一切正常运行,后来就变成了我们的必备工具。

你能够缓存的东西只有那么多,所以我们在早上9点左右使用激进的缓存策略解决了那个9点难题。不过你无法长时间缓存这些页面,特别是对于酒店列表一类的东西,因为这个业务的时效性非常强。人们通过我们找宾馆,而宾馆在不停地改变着它们的价格和房间分配。他们每分钟都在变,所以我们只能缓存这么多。

然后我们开始审我们的软件栈,瓶颈在哪呢?无法扩展肯定是有原因的。其中一个瓶颈是MySQL。当一个用户进入时,我们会简单地……我们的数据库里有上百万条表项记录。我们将在此之上设置一个位置查询,试着从上百万记录里挑选出15个最佳酒店。

S: 为什么是15?

J: 因为我们相信,用户的选择范围应该是有限的,只给他们显示最好的15家酒店能让他们更容易做出选择。我们还做到了确保酒店和街区的多样性,许多这样的特性都写进了算法里。这样的操作,我们过去在MySQL里完成其中一些,更多在Ruby里做,这是个瓶颈。MySQL逐渐成为了一个瓶颈。

我们开始转而探求不同的技术。Elasticsearch 引起了我们的注意。很多人成为了其他最新技术的粉丝,例如Solr等,而Lucene宾馆评级似乎是个很有趣的想法。我们探索了一下,现在我们的软件栈里用上了Elasticsearch 。

Y: 你们的网站服务器放哪?自己搭建吗?

J: 我们使用了一个Found来托管Elasticsearch。值得一提的是:在Ruby和MySQL的组合下,基于用户位置和供应水平来选择15个最佳酒店大概需要500ms到1s。

Y: 这个过程要通过活跃记录对吗?

J: 的确经过了ORM,然后是MySQL和后处理,在Ruby中进行的大量后处理,以进行酒店的融合和匹配。之前用Ruby和MySQL做同样的事我们现在用Elasticsearch只需要15ms。那是一个很有意思的挑战。

关于Elasticsearch 我可以一直讲下去,因为我们又发现了Elasticsearch的另一个问题。这差不多就像 “好的,这样很好,我们搞定了吧?” 然而,并没有。在用户方面,很多人进入应用后想看宾馆列表;然而宾馆方面,很多合作方都在频繁更新库存条目、更新可用房间和评级。接下来,数据要从MySQL同步到Elasticsearch。

Y: 顺便问下,他们在输入数据吗?你们不舍弃一些东西吗?

J: 是的,他们不停地输入数据。我们也跟他们保持着直接联系,就像API一样。这意味着数据经过了多次变化,还要传输给所有的存储系统,包括Elasticsearch。哇塞嘞,这对于Elasticsearch可真是相当繁重的写入负载。一般来说,Elasticsearch的存储围绕着记录和分析展开。而刚才讲到的这个事就不一样了。文件的数量未必有多大,但数据一直在变化导致许多行为在我们刚开始用Elasticsearch时并不知道。

Elasticsearch会在悄悄地丢掉一些写入。如果你用了批量更新API,你就要小心这些错误了。从前我们会说:“噢,Elasticsearch 扩展性不错啊?”然后我们发现了这些错误,现在我们在加速写入的时候需要确保正确性。于是我们在Elasticsearch和系统之间设置了队列。

Y: 队列用了哪个?

J: IronMQ.

S: 它会自动工作吗,还是有人操控?比如一名工程师在时刻观察并等待着。

J: 我们也在这些队列系统里设置了很多监控,覆盖了所有系统。我们在很多服务中使用了Datadog。如果这些队列中的消息超出了预设阈值,相关人员就会收到警告。

Y: Datadog就像你的仪表盘,对吗?

J: 不只是仪表盘,我觉得仪表盘看起来很漂亮,但很多时候你从它们那里得不到深层信息或者可行的见解。Datadog的报警系统是我们很喜欢的东西。我们为系统设置了警报,从负载均衡到所有数据库再到所有缓存。我们有检查和平衡系统以确保值守人能收到警报。比如如果RDS数据库的CPU使用超过了一定限制。

Y: 看来有很多工具帮助你们完成了这一系列工作。你可以说我们不需要谁来做DevOps谁来倒腾Docker。很多事情都可以通过工具来完成,对吗?

J: 一点不错。ECS大大简化了工作,我们还用Terraform把我们的基础设施模板化形成代码。我们所有人都可以用代码的形式来看基础设施是什么样的,而在以前很少有文件描述系统,文档也特别少,现在都可以用代码来描述了,比如Terraform。

很多创新出现在这个空间里。很多很酷的事情发生在这个空间里。

Y: 你们还用CloudFormation 吗?

J: 我们不用CloudFormation了。Terraform有我们所依赖的一切环境,包括所有的弹性缓存和RDS等等,非常棒。我们还有好几个暂存环境(Staging Environments)。我们可以很方便的上线下线更换环境,把新环境放上去拿下来。

Y: 你们的编译、测试、部署流程是什么样的,每个人都在本地使用Docker吗?

J: 现在还不是。有些人用,但这是我们接下来要评估一下。

Y: 你自己也在用Docker吗?

J: 是的。没错。我们需要特定的一些东西。我们现在想弄清楚当我们增加服务的时候,我们应该怎样抽取出接口给外部服务,这是我们在琢磨的事情。

我们通常的工作流是这样子的。我们用Solano。一旦你登记上什么东西,一旦你清除了私有库或者清除了一个分支,它通过Solano CI执行来确保一切正常。

所有测试跑通,并且确保在几分钟之内跑完,而不是耗上三四十分钟。这就是Solono CI的强大之处。

你可以创造一个私有代码库,在Solano上测试运行。团队中的其他人审查你的代码库,然后你可以把私有库合并进Master里。然后用Jenkins 和 Solano 的组合部署到暂存服务器里之后我们做一些质量管理方面的人工测试,然后上线到生产环境。

Y: Docker是怎样用在这个流程中的? 把代码push到GitHub上然后把它装进容器然后放进Solano里?

J: 是啊,它会被放进容器。我们使用Jenkins并创建那些Docker构建以及创建我们需要的那些镜像。有了ECS以后,我们可以定义这个流程,以上就是我们的构建流水线。

Y: 测试要跑多久?我只是好奇。

J: 如果你在本地运行,那得跑上好一会。我们刚开始做的时候就是这么干的,好几年前了。那会儿还是Circle CI和Solano。在Solano上面的话,我记得花了5分半钟。

Y: 哇,那真不错。

J: 嗯,不过我们仍然在努力避免把代码堆在一起。平台方面,一切顺利。去看看我们提取出来然后封装都不同服务里的那些东西。

Y: 从构建和部署上来讲,移动端的处理过程有什么不同吗?

J: 一些平台,像iOS,在你提交App的时候就会启动审查周期。每两周我们会尝试做一些新东西出来,一个新Release版本或者补丁,当然我们发现了什么以后会立马打上。我们想保持一定的节奏来在这些平台上发布新版本,而不是新特性驱动的版本发布,这个更接近于我们有个发布周期,每到一定时间我们就要发布些东西出来。

有件事我还没提到,跟刚才说的数据库难题有关。我们通过引进缓存和迁移到Elasticsearch 上来解决用户方面的问题,但是依然需要往Elasticsearch里不停写入,所有酒店都在不断地更新他们的费用和空房,所有这些数据仍然需要在进入同一个数据库。那里是个热点。很多公司和我们一样也在寻找这个问题的解决方法。我们在MySQL之上建立了一个无模式只附加的存储区。 和FriendFeed差不多 ... 大约在2009年,FriendFeed的人发布了一篇相当不错的博客。最近Uber也用了这个无模式只附加的模型。

它让我们能够在水平地扩展到更多的分区和分片上,同时我们让它变成无模式的。无模式和只附加存储是关键。通过保存同一个房间或者条目的不同版本,就不需要覆写了。你甚至不需要覆写哪怕一行因为实际上只是在创建不同的版本。关于无模式,因为有些东西一直在变化所以你不需要跟进然后改变这些模式。你不需要在线更新这些模式变化。

Y: 哇,好棒。

我们还有几分钟。还有其他一些有用的工具吗?我们不需要谈太多移动端的东西,因为你做的是平台,但关于Ruby可谈的还有很多。我知道你提到了Go,但你们还探索过其他的新技术吗,或者你们在Ruby上取得成功了吗?能够让它高效运行吗?

J: Ruby表现的很不错。在一些应用实例中,Go是人们刚开始使用的东西。这个房间里有包括我在内的许多Ruby迷,我们从2006年开始就在Ruby社区里了,很多Ruby社区是从Elixir开始的。我们团队里很多人也在研究Elixir。

Y: 你是它的粉丝吗?用它做过东西吗?

J: 还没呢。

Y: OK,你对Ruby很满意。

J: 我对Ruby很满意,但同时我不会把编程看的太重,花在编程和管理上的时间甚至都不会对半分。目前我更侧重管理方向,我需要确保团队文化和项目都在正轨。基础建设很吸引我,在扩展这件事儿上我甚至感到更加兴奋,特别是在存储系统方面。你可以扩展Ruby,你可以添加很多很多网页服务器,但扩展状态则十分具有挑战性。  

Y: 是的,看来很多问题都是因为供应方的大量写入数据造成的。我觉得在用户一方没有这么多问题,对吗?

J: 其实是有的。但并不多。我们在Rails模型中避免了很多人陷进去的“回调地狱”。

Y: after_save

J: 嗯,after_save,我们以前的一些Rails模型中列了一个很长的回调表。我们远离它们并且尽可能把他们放到后台去。

Y: 大量使用Rake tasks。

J: 不是Rake tasks但用了Sidekiq之类的东西,只是离线队列而已。我们着眼的下一步是事件流处理。考虑某个用户改变了某些属性的情况,然后系统的其他部分就需要知道发生了什么变化,而从前我们只是简单地用5或者10个不同的回调给实现了。另一个在考虑的解决方法是用生产者/消费者模型。生产者产生数据然后推到队列里,比如用Kinesis或者Kafka,然后消费者消费队列。这是我们即将迁移到的模型。这样从概念上理解系统里发生了什么就简单多了。

Y: 是的,这意味着你们有一个可以纵观全局的中央位置。

J: 对。

Y: 你们现在要引进Kafka,还是已经用上了?

J: 我们现在正在测试Kafka和Kinesis。Kafka是基于AWS的一项服务,所以你不用担心会主机上会出什么问题。但同时我们尝试分别用Kafka和Kinesis运行边界情况看看会得到什么结果。完成这个以后,我们再决定应该使用Kinesis还是自主式的Kafka。

Heroku最近发布了他们的Kafka as a Service,我们也在考虑这个。

Y: 不错,有意思。嗯,我们的访谈进行的很顺利。话说Looker对你们很有用吗?

J: 当然,Looker一直都很有用。我们有如此多的数据,该如何取用呢。我没有问题,因为我可以自己去运行SQL查询。团队的其他人需要简单的方法。这时,Looker就是一种很有帮助的工具,它设计出来就是干这个的。

Y: 我想到一个问题,关于你说的上午九点钟的推送通知,你能简要描述一下如果一个服务器在午夜停运了会怎样吗?处理流程是怎样的?你们会用PagerDuty来接受文字消息吗?

J: 我们有平台团队。每个队员每周会值班。我们设有首层和次层机制,无论在什么时间,都由首层优先处理。如果无应答,那么就启用次层机制,而我处在第三层。我也会在每14或15周值一次班,但我一直处在第三层,如果前面都没有人应答,那么我就顶上去。

根据通知设置和问题本质,我们当然想让大家接电话,而不是一则文字消息。如果数据库报警了,当然最好赶紧去看看。我们通过使用一种警报机制来努力减少噪音。

所有噪音。要确保高级别警报和重要呼叫能得到应答。我觉得下一步应该是如何把警报带到下一层里。不止是报警,还要找到能够立刻能解决问题的方法。举个例子,考虑我们的队列系统堵了,我们能不能立马派更多的Worker顶上,而不是跟值班人员报警。

在没有人员干预的情况下,你需要很小心,因为你可不想用了一大堆Worker顶上去然而最后把数据库拖垮了。

S: 听起来像机器学习。

J: 是的。异常检测是机器学习的一种……很多公司都在用它。我想Sumo Logic就是其中之一,他们几周前上线了,看起来很有意思。

S: 我想问你的问题太多了,但我知道你的时间很有限所以我们很快就结束了。对我来说,你所说的Hotel Tonight里似乎有一种非常酷的文化氛围,是一个我如果我跳槽会很像去的地方。你知道Airbnb上有一种分享经济和分享服务。你觉得住宿业务以后的发展趋势是什么?你觉得人们还会继续选择酒店,还是其他什么方式?你会怎么选?

J: 我觉得要看不同情况,也得看客户的现实生活。如果你在度假,如果你提前一年和你家人计划了度假内容,那我觉得类似Airbnb住宿服务会胜出。在其他很多情况下,如果你喜欢说走就走的旅行,或者像我一样从南湾出发,晚六点到达旧金山,那你肯定要考虑“我是晚上就回去呢,还是在定个房间过一夜明早再走?”在Hotel Tonight的帮助下,很多人都有了这般随性的旅行体验。在手机时代,这就是“千禧一代”的生活方式。我们才刚刚开始。

S: 还有个小问题。到底是什么让你感到兴奋,让你十分期盼?可以使技术上的,或者生活上的,比如说我养了条狗,我要买点东西,可能明天,可能下周,也可能下个月。

J: 好的。就我个人来说,我喜欢搞扩展。当我围绕系统扩展工作时,我会很嗨。可以是折腾存储系统,也可以是扩展用户数。在成长过程中,我也常常问自己我的兴奋点在哪里。从本质上来说,扩展一个公司会让我充满干劲。建立客户基础、想办法留住用户,你可以高速运转。但如果你的客户不愿留下呢……所以说,保留客源是另外一回事。总的来说,我觉得生意和技术的结合就是最美妙的事。

S: 很赞!多谢啦。

J: 也谢谢你们大伙啦,谢谢!

本文来自GET社区翻译计划,每翻译一篇高质量文章,可获100元奖金。翻译计划赞助商:
转载必须保留来源和以上赞助商信息。

本文由 turbo0628 第一时间收藏到GET,由 Easy 创建本知识库永久备份,原文来自 → stackshare.io

「GetParty」

关注微信号,推送好文章

微信中长按图片即可关注

更多精选文章

评论
微博一键登入