亚马逊(Amazon)面向服务架构(SOA)经验

Amazon前员工，现google员工在Google+上说google不懂得做平台，里头也提到以前Amazon实现面向服务架构的一些经验(不过是好几年前的经验了)：

- pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If eachbounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build alot of scaffolding and metrics and reporting.

- every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress untilvery serious quotas and throttling are put in place in every single service.

- monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'mfine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, rogerroger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls.The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of servicesand data, at which point it's indistinguishable from automated QA. So they're a continuum.

- if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't beable to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism,which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) aboutevery service, what its APIs are, and also whether it is currently up, and where.

- debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.

来自 https://plus.google.com/112678702228711889851/posts/eVeouesvaVX