我们能在SOA架构里添加哪些特性？

新阳写了一个很棒的Thrift技术演进方案，甚至包含了架构基础代码。这个SOA方案有以下几个闪亮的特性： 1. 可用性：消除单点故障隐患，提供水平扩容的基础； 2. 可维护性：提高服务监控的粒度、规范化程度、自动化程度 3. 可改进性：包括Client端调用方式和Server端实现方式 这个方案最大的亮点就是层次分明：虽然是为Thrift量身定做的技术架构，但这些特性对采取什么具体技术来说并没有强制性的要求。

那么还有没有其它需求可以在SOA框架中满足呢？判断标准又是什么呢？我给出我的思考，希望能看到大家的真知灼见。

首先先给出选择特性的基本原则，然后讨论要为需求提供的特性及实现思路。 基本原则

---

1. 适用性原则 在架构层面被满足的需求应该是对大多数服务来说都必须要满足的需求。 从公司业务情况来看，高可用性、水平可扩展性（Scale out）、可维护性等是所有服务都必须满足的特性。
2. 投入产出比原则 主要考虑两方面因素，架构层面实现特性的代价和具体应用获得特性的代价。 举例来说，如果想要的特性在具体业务中的表现是不一样的，那么在架构上实现这个特性时还得考虑到具体业务的场景，那么直接把这个特性放到具体应用中就更合理； 如果具体应用能够添加一个组件或者依靠继承来获得架构特性，这个代价就是合理的。
3. 轮子原则 大家都知道，在工作中不要重新发明轮子，用现成的就好了。 再往具体了说，如果有现成的工具或系统能支持的特性，一般来说不要带到架构层面实现了。但也有例外，就是如果在架构实现这个特性后，让具体应用添加特性的成本降低了，那在架构引入这个特性也是值得的。

可选的架构特性

1. 可改进性 我觉得这是SOA架构中最重要的一个特性。 实现了这个特性也就满足了SOA架构的基本要求了，即提供封装好的调用服务接口，但具体调用及服务的实现都封装成黑盒。服务的封装度高，对Client端调用方式的修改及对Server端具体实现的修改影响范围都是可控的，能够做得及时改动。 平台组负责的公共服务都具有这个特性。
2. 可监控性 服务的运行状态必须是可监控性，但其实是有现成的监控工具来监控应用的运行状态。表面看是不用重新发明轮子的。

但针对目前运行在TC中的Java应用来说，其中服务的可监控性还是应该在架构层面来实现的--TC正常运行，里面的具体服务歇菜的事情还是出现过的。 从JDK1.5开始，java.lang.management 提供管理接口，可以监视虚拟机中的线程和运行虚拟机的操作系统。TC中的实现一般都是线程形式的，可以设计这样一种约定：重要任务的线程加标记，然后有一个监控线程定期扫描这些有标记的线程，对异常进行告警。 3. 部署的自动化程度及可视性 这个特性的价值是降低维护成本和提升在线时间（uptime），应该也可以在架构层面实现。 4. 基于客户端的水平扩展性 满足水平扩展性的常规做法是在服务端用分发系统做集群。利用架构在客户端实现的代价还需要评估，但这个思路是非常好的，值得探索和尝试。