SOA架构设计概要

主要内容也是来自《SteveY对Amazon和Google平台的长篇大论》

1. 通过服务接口提供全部数据和操作

我们理解的SOA必然是通过接口的方式将数据与功能开放出来的，但要想要往平台方向发展，必须保证用且仅用服务接口的形式提供数据和服务： 团队间的程序模块的信息通信，都要通过这些接口； 除此之外没有其它的通信方式。其他形式一概不允许：不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门； 所有的程序都必须从骨子里到表面都要设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便把接口开放给全世界的程序员，没有例外。

2. 容错与服务保护

作为SOA服务中的开发者，既不能相信为自己提供服务的应用（Server），也不能相信访问服务的应用（Client）。 基本算老调重弹，因为没有无故障的软件，也没有无故障的硬件，再加上千奇百怪的网络条件和完全料想不到的客户，所以要处理异常（容错）才是正常逻辑；而每一个和你相关的团队突然间都可能成为一个潜在性的DOS攻击者。必须要为每一个Service设置配额（quota）与节流阀（throttling）的保护机制。

3. 监控与QA

仅有一个确定主进程不死的响应不是监控。如果测试覆盖到能验证所有业务逻辑的程度，当然是最好的。但我迄今为止，没见过太多的团队（仅有一个团队）完成了如此缜密细致的测试用例。 我觉得比较理想的监控系统要让业务人员“看到”业务在系统中的流转。实现这样的监控系统需要从以下几方面着手：

1. 梳理核心业务过程

把一个服务拆解成1~3个关键的业务流程，每个流程有2~4个重要环节。 然后描画出业务的时序图，在图上标出业务数据采样点。

2. 匹配监控函数

由两种匹配模式，最佳模式是寻找一个流程从上游到下游的数据关联性，打个比方来说，一个订购流程，在一段时间内用户发起的订购请求是x，下游订购成功的梳理是y，在一定范围的业务周期内，应该能观察得出y=F（x）的关系函数； 另外一种模式是无法获得可以直接关联的x和y。这种情况下只能通过对比环比数据来判断是否异常了，对于依赖用户行为的业务，准确性较低。

3. 过程要点

可以看出来，这个监控系统也是个分布式的。SOA服务要拆解自己的业务，寻找采样点，按照统一业务日志格式进行记录； 监控程序要能把数据进行汇总，按照预置匹配函数进行判断，对超出阈值的情况进行告警。