亚马逊是如何转型云计算的

标签:SOA服务器安全沟通OA

访客:55501  发表于:2012-05-14 16:24:53

看到一篇文章,转过来其中的一部分,很不错的。

Jeff Bezos是个臭名昭彰的微管理经理人,他的微管理都管理到了Amazon零售网站上的每一个显示像素。他雇佣了Larry Tesler——Apple的首席科学家,他可能是全世界最有名也最受尊敬的人机交互接口专家,然而,Bezos忽略了Larry三年来提出的每一个建议,直到Larry最后——明智地——终于离开了公司。Larry本应做一些大型可用性(Usability)研究,并可以系统地了解那个根本就没有人能够搞懂、使用那该死的网站,可是,Bezos对于那些像素不放手,这些页面上的那几百万个显示像素就像是他的孩子一样。所以,他的这些孩子还留着,而Larry没有。

当然,微管理不是第3项Amazon做的比我们好的事。我的意思是,没错,他们微控管理做地非常地好,但我不会把这项列在他们的强项清单上。我这样说只不过是为了我下文做铺垫,帮助你了解我后面要说的事儿。我们现在要说的这个人,是在多个严肃的公开场合说要来Amazon工作就应该付他钱才对的人。当有人跟他意见不同时,他会递出写有他名字的黄色即时贴以提醒那个人“谁是公司的老大”。这家伙是……,Steve Jobs,我想,除了没有品味和设计能力,他们很相似。千万别误解我,Bezos是个绝顶聪明的人,只不过他把那些正常的管控搞得像嗑了药的嬉皮士一样罢了。

所以,有一天,Jeff Bezos下了一份命令。当然,他总是这么干,这些命令对人们的影响来说就像用橡皮槌敲击蚂蚁一样。这个命令大概是2002年,我想误差应该是在正负1年内 —— 这个命令发布的范围非常地广,设想很大,让人眼珠子鼓出来的那种,这种惊讶程度和其他的命令相比,就好像你突然收到公司给你的奖金一样让人惊讶。

这份大命令大概有如下几个要点:(陈皓注:这里是本篇文章的要点!如果这真是Bezos发出来的,那么太赞了,Bezos完全就是一个系统架构大师啊,那可是2002年左右啊。作者调侃Bezos完全是正话反说啊)

1) 所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。(陈皓注:Service Interface也就是Web Service)
2) 团队间的程序模块的信息通信,都要通过这些接口。
3) 除此之外没有其它的通信方式。其他形式一概不允许:不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等,等等,唯一允许的通信方式只能是能过调用 Service Interface。
4) 任何技术都可以使用。比如:HTTP、Corba、Pubsub、自定义的网络协议、等等,都可以,Bezos不管这些。(陈皓注:Bezos不是微控经理吗?呵呵。)
5) 所有的Service Interface,毫无例外,都必须从骨子里到表面上设计成能对外界开放的。也就是说,团队必须做好规划与设计,以便未来把接口开放给全世界的程序员,没有任何例外。
6) 不这样的做的人会被炒鱿鱼。
7) 谢谢,祝你有个愉快的一天!
哈哈!你们这150个前Amazon的员工,当然能马上看出第7点是我开玩笑加上的,因为Bezos绝不会关心你的每一天。

不过第6点是很真实的,于是,所以人们都去工作。Bezos并派出了几位首席牛头犬来监督并确保进度,领头的是和熊一样大的牛头犬:Rick Dalzell,Rick是以前是陆军突击队队员,西点军校毕业生,拳击手,和沃尔玛的首席虐刑官 / CIO,而且他也是个高大、和蔼、令人敬畏的人,还是经常使用”hardened interface”词的人,Rick 本来的走路和说话都比较hardened interface,所以不用多说,每个人都得干 出有重大的进展,这样Rick才能看得见。

在接下来的几年,Amazon内部转变成面向服务架构SOA(Service-Oriented Architecture),在这华丽转身的过程中,他们学到了相当巨多巨多的东西。我在的那个时候,世界上就有很多很多的关于SOA的学术文档,但在Amazon的那种超大规模的面前,世间的这些文档就好像告诉印第安纳琼斯(陈皓注:电影夺宝奇兵男主角)过马路前要先看看两边有没有来车一样没用,Amazon的研发工程师们在这个过程中发现了很多很多的问题,并从中学到了很多。下面只是他们这些问题中的沧海一粟:

pager escalation(陈皓注:生产线上问题的寻呼系统)变得比较困难,因为ticket可能会转过来转过去(陈皓注:ticket就是处理问题的工单),只到转了20次,都找到真正能解决问题的团队和人。如果每一个呼叫都花去团队的15分钟的响应时间,那在找到真正的团队之前,几小时就已经过去了,除非,你能建造出很多很多的脚手架,测量标准和报告。

每一个和你的相关团队突然间都可能成为一个潜在性的DOS攻击者。没人可以让事情有进展,直到在每一个Service里放上配额(quota)与节流阀(throttling)的机制。

监控与QA是被统一了。如果你不进行一个大规模的SOA,你就不会这么去想。但是,等到你的Service说,“是的,我还好!”,但实际情况可能是,服务器里唯一能正常运作的功能就是一个快乐的机器声音在呼叫你:“我很好,收到,收到”。为了要确认整个服务能正常运作,你需要对Service的每一个部分都去Call一下。这个问题会以递归的形式地出现,直到你的监控系统能够全面性地系统地检查所有的Services和数据,此时,监控系统就跟自动化测试QA没什么两样了,所以两者完美的统一了。

如果你有上百个Services,而且你的程序只能通过由这些Services来跟其他团队的程序做沟通,那么,没有一套Service发现机制的话,你就不能找到这些Service。所以,你得先有一套Service的注册机制,这也是一个Service。所以,Amazon有一套全体适用的Service注册机制,以例可以通过反射机制来找到Service,并知道Service的API,以及是否可用,在哪儿。

调试其他人的代码以调查问题变得非常的难,几乎都不可能,除非有一套全面性的标准的方式,他可以在可被调试的沙盒里运行所有的Services。

上面这些只是极少数几个例子,在Amazon在进化的过程中,Amazon遇到这样的问题可能一打甚至数百个,Amazon都一一学习和总结了。对于把Service外部化甚至还有很多几乎没有人会想到的非常生僻的东西,当然,也不会有你想像的那么多,Amazon都学到了。把业务组织成Service让团队学会了不能相信对方,就如同他们不能信任公司以外的程序员一样。

当我在2005年中期离开Amazon加入Google时,这个努力进化的过程还在进行时中,但那时已经相当的先进了。从Bezos颁布法令的时间到我离开的时候,Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司,今天,这已经成为他们进行所有设计时的基础,包括那些绝不会被外界所知的仅在内部使用的功能。

那时,如果没有被解雇的的恐惧他们一定不会去做。我是说,他们今天仍然怕被解雇,因为这基本上是那儿每天的生活,为那恐怖的海盗头子Bezos工作。不过,他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问,某些缺点还很大,也不疑问。但总的来说,这是正确的,因为,SOA驱动出来的设计会产生出平台(Platform)。

是的,这就是Bezos的法令要达成的目标。他以前(现在也是)一点不关心各团队是否好,也不关心他们使用什么样的技术,实际也不去管他们如何运作他们的业务,除非团队开始把事搞砸。但是,Bezos比绝大多数的亚马逊人都很早很早就领悟到,Amazon必须成为一个平台。

如果是你,你会想到要把一个在线卖书的网站设计成为一个有扩展性,可程序化的平台?你真的会这样想吗?

嗯,第一件Bezos领悟到的大事是,为了销售书籍和各种商品需要的基础架构,这个基础架构可以被转变成为绝佳计算平台(Computing Platform)。所以,现在他们有了Amazon Elastic Compute Cloud(亚马逊弹性运算云平台EC2),Amazon Elastic MapReduce,Amazon Relational Database Service(亚马逊关系数据库服务),以及其他可到AWS aws.amazon.com查得到的一堆Service。这些服务是某些相当成功的公司的后台架构,比如我个人喜欢的 reddit 是这一堆成功公司的其中一个。

另一大领悟是,他知道他们不可能永远都创造出对的东西。我认为,当Larry Tesler说他妈妈完全搞不懂怎么使用那个该死的网站时,Bezos的某根筋被触动了,当然,我也不清楚到底是谁家母亲,这无关紧要,因为没有人的母亲能够会用那个该死的网站。事实上,连我这个在那工作超过5年的人都觉得Amazon网站的接口令人胆战惊心。

我并不是很确定Bezos是如何领悟到的——领悟到他不能创造 出一个产品能适用于所有的人。不过,怎么来的这不重要,重要的是他的确领悟了。这种事有一个正式的术语,叫Accessibility,这是计算机世界中最最重要的事情了。

最!重!要!的!事!

如果你在心里面在想“哼?你是说,像盲人和聋人那种Accessibility吗?”,那么,你不是唯一这样想的人,因为我已经知道有很多很多像你这样的人:这种东西对你们这种人来说是不可能有正确的Accessibility,所以这事你还不能理解。当然,不能理解也不是你的错,就像眼盲,耳聋,或是其他行动不便的残疾人,这些也不是他们的错。当Software——或ideal-ware——如果因为某些原因不能被存取或使用,那么,这就是软件或是那想法的错了。这就是Accessibility failure。

就如同生命中那些重大的事一样,每个事都有一个邪恶的双胞胎姊妹,它在幼年都受到父母的溺爱,现在它已经成长为同等强大的复仇女神(是的,Accessibility有不只一个复仇女神),这个复仇女神叫安全性(Security),他们在一起总是争执不休,冤家一对。

不过,我会和你争论Accessibility要比安全性来的重要多了,因为零Accessibility就意为着你根本没有做出产品来,而如果安全性为零,你仍然还是可以有一个某个程度上成功的产品,譬如说Playstation Network。

对了,也许你还没注意到,我其实可以为这篇文章写出一整本书,很厚的一本,其中填满了那家我曾工作过的公司里关于蚂蚁与橡皮槌的事。但是,我可能也就永远无法在这发表这短篇的夸夸其谈了,而你也就无法读到除非我现在开始结尾。

评论(1)

您可以在评论框内@您的好友一起参与讨论!

    1. 姜稳 好长的文章,不过通篇读完后很爽,谢谢大刚老师的分享。

      回复[1] 2012/05/14 23:13

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");