SOA构架注意事项

接下来的几年里，亚马逊全公司都转向了面向服务的架构（SOA）。这个过程中，工程师们得到了大量的经验教训。

　　教训一：SOA 架构的错误定位，非常麻烦。

　　一个请求可能要经过 20 次服务器调用，才能找到问题的真正所在。通常，单单是问题的定位就要花费 15 分钟到几个小时，除非搭建大量的外围监控和报警措施。

　　教训二：同事也是潜在的 DOS 攻击者。

　　公司内部某个小组，会突然对你的服务发起大量请求。除非每个服务都设有严格的用量和限量措施，否则根本无法保证可用性。

　　教训三：监控和质量保障（QA）是两回事。

　　监控一个服务的时候，可能会得到"一切正常"的回复。但是很有可能，整个服务唯一还正常工作的部分，就是这个回应"一切正常"的模块。只有完整地调用服务，才能确定服务是正常的。

　　这意味着，真正监控一个服务，必须做到对所有的服务和数据进行完整的语意检查，否则是看不出问题的。如果做到了这一点，本质上就是在做自动化 QA 了。

　　教训四：必须有服务发现机制。

　　面对成百上千的服务时，没有服务发现机制是不可想象的。这又离不开服务注册机制，而它本身也是一个服务。亚马逊有一套统一的服务注册机制，可以通过编程的方式找到所有服务，包括一个服务有哪些 API，目前是不是运行正常，在什么位置等。

　　教训五：必须有沙箱用来调试

　　如果代码中调用了他人服务，查找问题的难度要高很多，除非有统一的方式在沙箱里运行所有服务，否则几乎不可能进行任何调试。

　　教训六：不能信任任何人

　　团队采用服务的方式进行合作以后，基本上就不能信任其他团队了，正如不能信任第三方工程师一样。