SOA 面向服务架构 服务化
公司项目最近的主要工作是准备服务化，作为服务化的鼻祖亚马逊的架构服务化过程经历了哪些困难，踩了哪些坑？通过这篇文章你可以略知一二。
- 作者：阮一峰
亚马逊公司不仅是世界最大的网络书店，还是世界最大的云服务商。它是如何实现从电商到云商转变的呢？
一切都源于CEO 杰夫.贝索斯超于常人的理解和预见
- 2000年前后，贝索斯在一次员工会议上提到，各种办公用具，书籍，影音制品都可以数字化，意味着容易盗版，数字化产品可能会利润最低或不产生收入了。
- 2002年，贝索斯向公司发出一道指令：
- 所有团队都以服务接口的方式提供数据和功能。
- 团队之间必须通过接口来通信。
- 不允许任何其他形式的互操作：不允许直接连接，不允许直接读其他团队的数据，不允许共享内存，不允许任何形式的后门，唯一的通信许可是通过网络服务调用。
- 具体实现技术不做规范，HTTP，Corba，PubSub，自定义协议皆可。
- 所有的服务接口必须一开始就可以公开作为设计导向，没有例外。就是说在设计接口接口的时候就默认这个接口可以对外开放没有讨价还价的余地。
- 不遵守上面的规定就开除。
他意识到，亚马逊现有的卖书送书的基础设施，其实可以变成一个非常出色，可定制计算的平台，让用户付费试用，但是前提是必须将基础设施服务化。
- 接下来几年里，亚马逊公司都转向了面向服务的架构（SOA）。这个过程，工程师得到了大量的教训经验：
- SOA架构的错误定位，非常麻烦： 一个请求经过20此服务调用，才能找到问题的真正所在。通常，单单是问题的定位就话15分钟到1个小时，除非搭建大量额外的监控和报警措施。
- 同事是潜在的DOS攻击者： 公司内部某个小组，会突然对你的服务发起大量请求，除非每个服务都严格控制用量和限量措施，否则无法保证。
- 监控和质量保障（QA）是两回事： 监控一个服务的时候，可能会得到“一切正常”的回复，但是很有可能，整个服务唯一还正常工作的部分就是这个回应“一切正常”的模块，只有完整的调用服务，才能确定服务是正常的。 意味着，真正监控一个服务，必须做到对所有的服务和数据进行完整的语义检查，否则是看不出问题的。如果做大这一点，本质上是在做自动化QA了。
- 必须有服务发现机制： 面对成千上万的服务，没有服务发现是不可想象的，这有离不开服务注册机制，它本身是一个服务，亚马逊有一套统一的服务注册机制，可以通过编程的方式找到所有的服务，包括一个服务有哪些API，目前的运行状态，在什么位置。
- 必须有沙箱用来调试： 如果代码中调用了他人的服务，查找问题的难度要高很多，除非有统一的方式在沙箱中运行所有的服务，否则几乎不可能进行任何调试。
- 不能相信任何人： 团队采用服务化的方式进行合作，基本上就不能相信其他团队了，正如不能相信第三方工程师一样。
