亚马逊如何变成 SOA（面向服务的架构）？
上一篇文章，我摘录了《程序员的呐喊》。这本书有趣的内容太多，今天再摘录一段。1、
亚马逊公司不仅是世界最大的网络书店，还是世界最大的云服务商。它是怎么实现从电商到云商的转变呢？
https://www.ruanyifeng.com/blogimg/asset/2016/bg2016091101.jpg
一切都是CEO杰夫·贝索斯促成的，他对市场有着超乎常人的理解和预见。
2、
2000年前后，贝索斯有一次在员工大会上提到，各种办公工具、书籍、影音制品都可以数字化，所以也意味着很容易盗版。数字产品可能会利润越来越低，很快就不再产生任何收入了。
所有的民用工业品也都很不妙，服装和电子消费品的消费周期越来越短。连烤炉这种东西，也没人想要去年的型号。总之，卖这些东西，看上去也不太会赚大钱。
亚马逊未来靠什么赚钱，贝索斯不仅忧心忡忡。
3、
2002年，贝索斯突然向全公司发布了一道指令。
（1）从今天起，所有的团队都要以服务接口的方式，提供数据和各种功能。
（2）团队之间必须通过接口来通信。
（3）不允许任何其他形式的互操作：不允许直接链接，不允许直接读其他团队的数据，不允许共享内存，不允许任何形式的后门。唯一许可的通信方式，就是通过网络调用服务。
（4）具体的实现技术不做规定，HTTP、Corba、PubSub、自定义协议皆可。
（5）所有的服务接口，必须从一开始就以可以公开作为设计导向，没有例外。这就是说，在设计接口的时候，就默认这个接口可以对外部人员开放，没有讨价还价的余地。
（6）不遵守上面规定，就开除。
他意识到，亚马逊现有的卖书送书的基础设施，其实可以变成一个非常出色、可定制的计算平台，让用户付费使用。但是前提是，整个基础设施必须改造成面向服务的架构。
4.
接下来的几年里，亚马逊全公司都转向了面向服务的架构（SOA）。这个过程中，工程师们得到了大量的经验教训。
教训一：SOA架构的错误定位，非常麻烦。
一个请求可能要经过20次服务器调用，才能找到问题的真正所在。通常，单单是问题的定位就要花费15分钟到几个小时，除非搭建大量的外围监控和报警措施。
教训二：同事也是潜在的 DOS 攻击者。
公司内部某个小组，会突然对你的服务发起大量请求。除非每个服务都设有严格的用量和限量措施，否则根本无法保证可用性。
教训三：监控和质量保障（QA）是两回事。
监控一个服务的时候，可能会得到"一切正常"的回复。但是很有可能，整个服务唯一还正常工作的部分，就是这个回应"一切正常"的模块。只有完整地调用服务，才能确定服务是正常的。
这意味着，真正监控一个服务，必须做到对所有的服务和数据进行完整的语意检查，否则是看不出问题的。如果做到了这一点，本质上就是在做自动化 QA 了。
教训四：必须有服务发现机制。
面对成百上千的服务时，没有服务发现机制是不可想象的。这又离不开服务注册机制，而它本身也是一个服务。亚马逊有一套统一的服务注册机制，可以通过编程的方式找到所有服务，包括一个服务有哪些API，目前是不是运行正常，在什么位置等。
教训五：必须有沙箱用来调试
如果代码中调用了他人服务，查找问题的难度要高很多，除非有统一的方式在沙箱里运行所有服务，否则几乎不可能进行任何调试。
教训六：不能信任任何人
团队采用服务的方式进行合作以后，基本上就不能信任其他团队了，正如不能信任第三方工程师一样。
（完）
页:
[1]