1) 所有团队的程序模块都要以透过Service Interface 方式将其数据与功能开放出来。(陈皓注:Service Interface也就是Web Service)
2) 团队间的程序模块的信息通信,都要透过这些接口。
3) 除此之外没有其它的通信方式。其他形式一概不允许:不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等,等等,唯一允许的通信方式只能是能过call 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说,“是的,我还好!”,情况可能是,服务器里唯一能正常运作的功能就就是一个快乐的机器声音在呼叫你:“我很好,收到,收到”。为了要确认整个服务能正常运作,你需要对每一个部分都去 Call一下。这个问题会以递归的形式地出现,直到你的监控系统能够全面性地系统地检查所有的Services和数据,此时,监控系统就跟自动化测试QA 没什么两样了,所以两者完美的统一了。
如果你有上百个Services,而且你的程序只能通过由这些Services来跟其他团队的程序做沟通,那么,没有一套Service发现机制的话,你就不能找到这些Service。所以,你得先有一套Service的注册机制,这也是一个Service。所以,Amazon有一套全体适用的 Service注册机制,以例可以通过反射机制来找到Service,并知道Service的API,以及是否可用,在哪儿。
调试其他人的代码以调查问题变得非常的难,几乎都不可能,除非有一套全面性的标准的方式,他可以在可被调试的沙盒里运行所有的Services。
上面这些只是极少数几个例子,在Amazon在进化的过程中,Amazon遇到这样的问题可能一打甚至数百个,Amazon都一一学习和总结了。对于把Service外部化甚至还有很多几乎没有人会想的非常生僻的知识,当然,也不会有你想像的那么多。把业务组织成Service让团队学会了不能相信对方,就如同他们不能信任公司以外的程序员一样。
当我在2005年中期离开Amazon加入Google时,这个努力进化的过程还在进行时中,但那时已经相当的先进了。从Bezos颁布法令的时间到我离开的时候,Amazon已经把文化转变成了“一切Service第一”为系统架构的公司,今天,这已经成为他们进行所有设计时的基础,包括那些绝不会被外界所知的仅在内部使用的功能。
那时,如果没有被解雇的的恐惧他们一定不会去做。我是说,他们仍然怕被解雇,这基本上是那儿每天的生活,为那恐怖的海盗头子Bezos工作。不过,他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问,某些缺点还很大。但总的来说,这是正确的,因为,SOA驱动出来的设计会产生出平台(Platform)。
是的,这就是Bezos的法令要达成的目标。他以前(现在也是)一点不关心各团队是否好,也不关心他们使用什么样的技术,实际也不去管他们如果动作他们的业务,除非团队开始把事搞砸。但是,Bezos比绝大多数的亚马逊人都很早很早就领悟到,Amazon必须成为一个平台。
如果是你,你会想到要把一个在线卖书的网站设计成为一个有扩展性,可程序化的平台?你真的会这样想吗?
嗯,第一件Bezos领悟到的大事是,为了销售书籍和各种商品需要的基础架构,这个基础架构可以被转变成为绝佳计算平台
原文转自:http://blogread.cn/it/article/4532?f=wb