面向服务的架构(SOA)

// 多个 SOA 返回不同规范的 resultCode ?
// 和微服务的区别?

SOA 架构的错误定位,非常麻烦

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

同事也是潜在的 DOS 攻击者

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

监控和质量保障(QA)是两回事

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

必须有服务发现机制

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

必须有沙箱用来调试

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

不能信任任何人

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