InfoQ是一个很不错的技术网站，内容不是很多，但是都很精。前两天头看到InfoQ的Qclub要在杭州和支付宝联合搞一次活动。主讲人是支付宝的首席架构师程立。抱着讨教经验的想法，我们决定参加这次活动。

活动在7月26日下午在杭州支付宝的一个会议室内举行。来得人不多，只有五十来人，但是气氛非常好。最重头的，也是此行的目的就是要听程立介绍关于支付宝的架构和如何实现SOA。听了之后觉得不虚此行，非常有借鉴意义。

从程立的表述来看，SOA不是空洞的哲学，而是实在的准则。支付宝的面向服务不仅体现在企业信息系统内部，也体现在每一个企业应用。他把一个支付宝的企业系统的发展分为三个阶段。

第一个阶段他们以少数的人，从做应用的角度来做支付宝。早先他们选用spring来做中间的业务层，将业务层再细分为很多层次，这些层次的功能都由 spring bean来提供。后来，spring beans的数量太多，达到数千个，不仅难以管理，也难以使用。尽管开发者可以完全遵循分层的规则把beans分成一组组的，但是由于系统上并没有提供杜 绝开发人员自由调用bean的能力，还是会发生成有些开发人员把层次搞乱的事情。所以在应用级别上，他们提出把beans组成组件，让组件提供服务，把不 能被直接调用的beans隐藏起来。在应用级别上，这也是SOA的一种思想。他们最终采用了OSGI来做为组件基础。

第二个阶段，就是做企业级的平台。一个企业可能有很多的业务模块，一个业务流程可能就要很多的业务模块参与进去。运用SOA的方式，就是把各个相对独立的 业务模块以服务的方式暴露出去，再用ESB来把所有的服务集成起来供上层的企业应用使用，在一个企业之内实现各个业务模块之间的SOA。

第三个阶段，是做开放的面向行业的平台。为了和其他的企业和作，为了给培养整个行业生态圈，最终支付宝走向了开放。这个时候，支付宝以REST或WS方式将支付宝的服务暴露出去。

如果以这三个阶段来评估我现在公司的状况的话，我们正处在第一个阶段，还有很长的路要走。

支付宝的SOA实践并非是死板的照抄SOA标准做法，其中最引人注目的就是他们对事务的处理。如果完全按照WS-Transaction的方式来做，性能 达不到需求，他们就根据业务需要自定义了一套事务管理机制。一个业务流程里的事务原则上来说要满足ACID原则，但是实际中可以根据业务功能的重要度，把 某些功能做成不满足ACID只要满足BaSE就可以。这里的BASE的英文描述我记不得了，意思就是在满足基本业务可用的条件下，在某些业务流程上放宽对 隔离性和一致性的要求，实现最终一致性。如果把满足ACID的叫刚性事务，那么BaSE就是柔性事务。支付宝做到可以通过配置指定一个流程中哪些服务时要 在刚性事务中的，哪些是柔性事务的。估计这个要深入研究事务，才能实现这样的功能。

讨论的时候，还有人提到支付宝如何处理有状态服务在分布式环境下一致性问题，结果程立给出的答案是，支付宝的服务没有状态。看来REST里的服务端无状态原则在SOA中也非常有用，可以简化服务。

这次活动很有收获，看到支付宝在SOA上面的成功，给了我们信心。

• 前一篇: 软件开发真理之关注点分离
• 后一篇: 使用seam时，注意实体的equals方法