一直以来，看了很多东西自己知道就完了，而我觉得作为互联网的一份子，应该懂得分享。
最近看了很多关于程立的一些演讲，学习到了soa实践中非常宝贵的经验。
最开始支付宝架构是单应用系统，采用分层架构模式（展现层+业务层+持久层），用过分层架构模式的人都很清楚业务层是最关键的一层，也是最容易造成臃肿和庞大的一层，所以需要合理的分离。而最佳实践应该是把业务层分为：facade层和业务逻辑层，也符合现在比较热的领域模型驱动，业务逻辑层主要负责业务本身的实现，facade层区分产品功能和决策。对于中小型而且项目业务需求也不怎么变的应用来说，是比较合理的架构。无论从学习成本和人力成本来说，都相对较低。但是业务不断扩张的应用来说，到最后开发成本和维护将会逐步提高。支付宝也是这个时候就开始着手对“对象”进行“组件”化，也就是接下来的第二个过程了。
从对象到组件化，我们首先要来看看组件这个概念。组件是功能职责相近类的集合。组件本身需要以下几点功能：1、属性 2、运行级别 3、引用 4、扩展 等。而那时比较符合支付宝这一思想的规范有osgi。具体关于osgi的相关内容可以自行google。如果用osgi会出现如下三个问题：
1、osgi平台如何在tomcat，jboss下运行。（现在tomcat，jboss等应用服务器都已经支持了，以前需要自己来扩展tomcat）
2、osgi使用起来比较麻烦和复杂，如何跟spring整合起来使用也是需要解决的问题，不过spring就是spring，05左右好像就对这方面开始研究了，现在作为一个子项目（Spring Dynamic Modules）。
3、osgi规范没有扩展这种功能，所以需要自己来对osgi的一些框架进行扩展，可以参照eclipse的一个osgi框架，或者也可以直接用此框架（Equinox）。
这些问题都解决了，那么“对象”进行“组件”过程就完成了。但是这个时候需要对企业内部的系统能够配合起来，那么可以对业务层进行服务化。也就是第三个过程了。
把组件都以服务方式部署出来，同时也需要管理好这些服务，那么此时可以引入esb（企业服务总线）中间件了。商业的和开源的都有，支付宝用的是开源的mule，不过对于某些方面，支付宝进行改造过，为了确保消息能够百分百不丢失，毕竟跟钱打交道嘛需要严谨。
其实这些基础平台搭建好后，还需要解决一个特别难的难题。功能服务化后，数据库也不再是集中式了，本地事务也不能保证了。这个时候需要引入分布式事务，数据库软件本身也提供分布式事务，但是对于需要高访问量和高性能的网站来说，可能需要换一种方式了。cap和base理论告诉我们可以适当放弃强一致性来达到其他两项性能。ws-transaction是分布式中间件，但是完成一个事务需要很多消息来沟通，至少大大增大了事务的中间过程会被中断掉。支付宝公司研究出了一些分布式事务模式，比如幂等性模式，补偿性模式，tcc模式等等。每个模式都有不同的应用场景，大家可以根据自己的业务特点来进行选取。
以上即是我最近学习的一些总结。让更多的人能学习好的技术和经验。让我们一起来分享吧。