枚举我们所采用的第三方服务

孙子兵法中写到『善战者,其势险,其节短』,用来描述当前的互联网环境再好不过了,作为一家创业公司,和其他的公司或者团队在竞争的过程中,谁能更快、更准确的把服务做出来,谁就能抢占先机,这个过程中还需要不断的试错。但是创业公司经常面临的问题是『资源不足』,要么人手不够、要么资金有限,流量来的快走的也快。那么,如何利用有限的资源做最有价值的事情?如何能快速构建产品和服务?

去年和 VisualOps 老大赵鹏聊微信,看下他们所做的事情和对 Docker 等的下一步动作,顺手发了一个当时做的 Docker 管理界面,本来想着应该收到一句:『wow』,但是赵鹏回复说:

Build your App, not Infrastructure.

这句话对我的感触很大,因为当时我们的技术团队本身人就少,每天写代码的状态就像高中时的试卷满天飞那样,即使每天写到夜里两点还是做不完?这个时候就需要考虑如何借势而为,幸好现在有各种为开发者提供服务的技术产品,能够免去了很多烦恼。

但是当你去寻找服务商的时候,会发现同样的服务会有一堆选择,这个时候就需要货比三家,接下来将会列举我们所采用的一些第三方服务,希望对大家有所帮助,其中我们自行部署的服务等将会在以后的《技术选型和进化》中具体展开。

青云

互联网创业,选择哪一家的云计算平台是首先需要考虑的事情,除非人『傻』钱多或者特定的业务需求,否则一个创业公司是不会选择自己托管服务器的,最开始决定使用青云的时候只是听 Sai 念叨过青云的技术实力和愿景很好,是一家靠谱的公司,加上当时公司以前的方案选择的就是青云,所以duang的确定下来。

目前我们大部分的业务都跑在青云上,除了PostgreSQL之外,使用了青云绝大部分的服务,有超过50台服务器分布在北京、广州和香港三个数据中心,数据中心之间通过IPSec隧道互相连接。

别看现在你侬我侬,其实在早期,还是动过念头要搬离到AWS或者其他云主机上,事情的原因是一个月内连续的两次断网事件:

  1. 2014/07/09,青云北京机房的网络出现故障,我们有一个子系统部署在北京机房,而且所有系统的自动部署服务当时也是在北京机房,这就导致部分服务不能正确响应,更麻烦的是当时客户需要部署的一个功能也无法上线;
  2. 2014/08/01,青云广东机房的网络出现故障,当时我们的 BD 正在客户那里做演示,距离会议开始还有5分钟突然电话说打不开系统,由于我们的主系统部署在广东机房,还暂时没有任何备用系统,所以也就导致客户只能望 PPT 兴叹;

由于两次事件都是在客户展示的节点,所以大家就对青云的服务质量打了一个问号,那么当时的想法就是试试AWS或者看下Azure,多几个选择总不会错。但是比较了一圈,基于如下考虑,我们最后还是留了下来:

1. 快,青云的快体现在很多方面:

a. 资源启动快
青云大部分的服务都能达到秒级启动,由于我们提供的是微信解决方案,平时没多少流量,但是客户逢年过节或者周末发一个活动消息就能带来超过平时50X以上的流量,而这个峰值往往只能维持半个小时到一个小时左右,所以就需要我们能够在系统资源出现不足的情况下能够快速部署服务。甚至,有时候有些客户会做一些临时的活动,如果系统不能及时响应,就等着写故障报告吧! b. 产品迭代快
在使用青云之后,基本上每个月都能看到他们发布新的服务,之前问过青云的圆姐:『为什么你们能够迭代这么快?』,得到的回复是:『因为没有产品经理!一两个工程师负责一个具体的产品功能,终身负责……』据说要发布auto scale功能了,很是期待!

c. 问题解决的时间快
由于团队都是90后,大家之前对于系统的网络等方案认知基本上=0,所以在使用青云早期也会遇到各种个样的问题,当然其中包括我们给青云报的一些bug。但是,很多情况下提交工单都很快得到回复,要知道很多时候我们的工单都是半夜2点左右提交……

2. 界面友好

青云的界面操作基本上看看就会用,而且各种设置不像 AWS 那样反人类!可能是因为他们的前端是个漂亮妹子的缘故吧!不过在年前,我还详细看了青云的界面,然后对比了我们的界面,发现了一些端倪,你说都是一样的布局方式,差距怎么就这么大呢?后来我发现问题的关键在于『留白』!

3. VPC

VPC这么好的东西,但是 BAT 三大厂的服务都没有这个功能,然后 AWS 太难用……

4. 标准服务

除了主机之外,青云还提供一些PaaS服务,例如 Redis、MySQL、Memcache等,这些服务最大的特点是你不需要对代码做任何的改动,因为他们本身就是标准的服务,这样有一个好处就是当突然有一天你要部署自己的服务了,就可以随时把数据迁走,而不会出现因为使用了这些服务而动弹不得的情况……

当然,在使用青云的过程中也有一些问题无法解决,例如,我们所采用的 Web 框架所生成的 log 所包含的信息太少,那么为了能够喂给日志中心更精准的数据,我们需要在每个服务器前面挡一个nginx或者统一使用HAProxy来分流,但是前者麻烦在我们的主机量比较多,每个都操作不仅繁琐还引入了新的依赖需要维护,后者自己部署管理缺乏一个高效的管理界面,由于青云开放了内网的负载均衡(据了解采用的HAProxy),所以我们打算直接使用这个方案,但是问题来了,无法获取青云负载均衡的日志,因为日志的数据根本不会落地到磁盘,相比较与 AWS 日志落到到 S3 的方案,还是让人比较不爽的,而且目前由于没有人提这个需求,所以日志落地暂时还不能实现,这就意味着我们需要自己动手造轮子!结果就是我们参照青云的负载界面写了一个HAProxy的管理界面:

Tower

我们采用 Tower 作为开发团队和运营、BD等团队的协作工具,在使用 Tower 之前,早期我们使用 37signals 的 Basecamp,之所以迁移到 Tower 的原因有:

  1. 速度,Basecamp 的速度对我们来说就相当于龟速……我只是上去√一个任务而已,还让不让我完成了!
  2. 体验差,作为一个小公司的杰作,貌似 Basecamp 很多年没有更新的节奏,整个风格没有与时俱进,相比于 Tower ,体验不在一个次元上了,怪不得 37signals 自己都意识到这个问题决定抛弃一篮子副产品专心改进 Basecamp 了;

当然对于 Tower 的使用,我觉得更多的是一种意识,创业团队每一个人都是处于非常忙的状态,而且大家又在一个小的环境中,基本上遇到任何问题,说话比发任务更简单,所以很多时候大家都会不自觉的去说句话而不是想好以后发一个任务!通过对于团队的观察我发现不是所有人都理解任务的含义:

  1. 任务应该是有结果导向而且无歧义的:在创建任务之前,你需要告知接受人任务相关的背景,预期的结果,而且这个任务不能是要多个结果的状态;
  2. 任务有且只有一个接受人:大家无意识的在一个任务中分派给一堆人任务,这就失去了任务的本意,如果你有一堆任务,那就需要单独罗列一个任务清单,任何一个任务,给谁就明确这个人来负责!
  3. 不要在同一个任务下回复新的任务:在完成了一个任务之后,会出现分任务的人在下面的回复中追加需求!这本身就是错的,因为你的任务所预设的目标在完成之后,新的需求就是一个新的任务,而不应该是在之前的任务中通过添加回复的形式再追加!

另外,对于开发团队而言,Tower 不是我们最好的选择,目前我们的方案是通过 Phab (Facebook的开源方案)来进行管理,而代码中的 bug 等则尽量通过 issue 的形式分配。

Github

Github 是我们目前在使用的代码托管服务之一,说是之一,是因为我们在1月份部署了自己的 Gitlab 方案,对于 Github 应该没有什么好说的。不过我们可能会根据架构的考虑放弃 Github ,全部转向 Gitlab 的方案,具体将会在以后展开。

七牛

七牛也是真心良心,虽然充值了,但是现在每个月免费的额度还是够用!好赞!

Mailgun

由于我们有事都是发微信/HipChat,所以Mailgun只是用来做 Gitlab 的邮件通知的给技术团队发信,所以不考虑送达的情况,但是如果发信是你的产品业务重要环节,建议可以试试 SendCloud!

HipChat

HipChat 大法好!

首先,它是一个聊天工具,纯粹,由于微信/QQ 十分方便,所以团队协作中大家倾向在这些 IM 工具中聊天,对于这一点技术团队是很不赞成的!不要在这些不能保留上下文环境的工具中聊工作,微信/QQ 明显是用来吹水的好不好!

其次,HipChat 开放 API 同时采用 XMP P协议,就很容易和其他的应用或者自己的服务对接起来,目前我们是对接了自己的 Hubot 机器人。

你认为HipChat只是一个聊天工具?错!!!我们把它和我们的ops机器人对接起来,随时能够查看具体的主机、服务状态:

你认为HipChat机器人只能聊Ops?错!!!我们还可以用它来看苍老师!!!

是不是觉得自己 Too yong, too simple, sometimes naive 了?

当然,HipChat 有一个问题就是服务器不稳定,我们目前的方案是自己做了一个代理,说到代理简直是一个大坑,这个将会在以后的《那些年的代理》中去展开。另外,关于『机器人和自动化』的细节,将会在《机器人,写代码!!!》一文中详细聊聊。

Codeship

CI 需要从小团队抓起!

Heroku

在我们目前的业务需求中,有一些客户的服务独立于我们的主系统开发并由我们进行托管,对于这一部分的业务,客户的 IT 部门需要能够随时了解所托管的服务状态。毕竟这是一个附属的需求,相当于买珠送椟,显然我们希望能够找到一个最实惠的方案来满足这一部分需求。由于我们大部分的业务都跑在青云之上,而青云又有完善的API,所以就选择基于API进行简单的二次开发,把服务状态系统部署在Heroku上,还有一个好处就是如果我们青云的系统挂了,也不会影响状态查询系统,哈哈,独立的中间人,这一点是从 Github 学到的,如下是我们一个客户的系统界面:

当然,除了以上『不给钱就不干白活』+『程序员就是懒』的理由,Heroku的简单易用也是吸引我们使用的原因!当你使用如下几个简单的命令就能起完成部署以后,想必你也会动心:

$ heroku login $ heroku git:clone -a status $ cd status ... $ git add . $ git commit -am "make it better" $ git push heroku master

可惜,Heroku 对于代码的侵入性太强,不然我们会把更多的东西托管上去,不过得益于 Heroku 的 The Twelve-Factor App所带来的启发,我们对一个系统应该怎样去更快速构建、解耦和部署有了更好的认识,目前我们在架构方面尽可能的往这些指导靠近,3月也准备根据自己的业务场景来部署一套简单的系统实现快速部署和扩展,具体将会在以后的《我们的服务发现与自动部署》一文中展开。

LeanCloud / Twillo

选用LeanCloud的原因是因为认识滚滚同学……好吧,开玩笑!因为1月份有一个客户的子系统需要对接短信验证,而他们的用户又不限于中国大陆地区,早开始的考虑是使用 Twillo 来做统一的服务接口,但是理想很丰满,现实很骨感,首先中国的短信管制很严格,每一条短信都需要按照规定带有发送方的名称,而 Twillo 上面发送到中国的短信竟然有时候带的是 Uber、UCG(好像是这个)……说好的客户名称呢?你让我们的客户怎么看我们的专业性!!!其次,Twillo 对大陆的短信时滞太长,这个就无法容忍了……

在寻求了一圈朋友的意见之后,我们放弃了一堆方案(主要是这些服务商的网页做的太丑……一点没有逼格好不好!!!)选择了 LeanCloud 作为国内短信接口。

首先我要声明,LeanCloud 不是发短信的,只是他们正好有这个服务,而且我们客户的国内短信量比较小,所以基本上不会有太大的问题!但是问题来了,LeanCloud 没有 Golang 的SDK……奥,我忘记说了,我们团队是写 Golang的,于是就花几个小时写了一个 LeanCloud 的Go-SDK,目前除了 sms 接口之外就随便写了几个接口,但是整体架构是确定的,你有时间就请 fork 发 PR 吧!

DNSPod

DNSPod 真心良心,不过我们没有付费,而且用的比较简单,接下来在我们的服务发现系统中可能会结成这个方面的功能,具体的细节需要深入使用再说!

Google Apps

对于技术团队来说,最头疼的不是遇到各种架构代码的问题,而是这帮人大不爱写文档,所以早期我们把所有的文档都放在 Google Docs 上,但是由于一些文档除了技术团队之外别的团队成员也需要查看,所以我们后期已经进行了迁移,使用的 Phab。

可能看了这些,你会说:『裤子都脱了,你就给我看这些?你们的日志、监控、Phab、运维、自动部署、CoreOS/Docker使用、开发环境和测试都是怎么做的?……还有那个苍老师机器人咋整?好歹给看一个代码吧!』

不着急,本文明显就是一个吹水的文章,重点在后头好不好?下一篇文章将会说《如何让新人加入就能尽快写线上代码?》。