参加了QClub：当SOA遭遇现实归来。地主已经把活动图片放出来了：QClub 杭州站成功在支付宝举行
支付宝首席架构师程立的分享很精彩。讲述了支付宝几年走过的架构历程。《程立谈架构、敏捷和SOA实践》
截止到2008年5月6日，使用支付宝的全球用户已经超过8000万，支付宝每日交易总额超过3.5亿人民币，日交易笔数超过150万笔。 对于这样一个系统，支付宝也是从简单三层的应用开始的。面对不断变化的业务，海量的数据，系统内产生了上千个类的情况，给开发维护都造成极大的困难。之后开始应用SOA,对系统进行封装，将功能做成服务，每个服务都可以应用集群进行支撑。
分布的业务，分布的数据，海量的访问。
对事务的处理，提到了两个概念：ACID(原子，一致，隔离，持久)和BASE(基本业务可用，柔性状态，最终一致)。
支付宝对BASE的实现有一个TCC模型（try-试执行,cancel-取消,confirm确认）。
在之后的讨论中，有幸程立和我们在一个小组。对分布式系统中的事务处理，及在SOA中的应用引起了大家的关注。ACID被称为刚性事务，BASE被称为柔性事务，这个叫法很快被认同，也很好理解。讨论很快集中到最终一致上。因为大系统应对大并发时，必然会采用柔性事务，以保证基本业务可用。之前自己做的一个系统里也遇到过这种问题，刚开始的时候采用刚性事务，在小数据量的时候好象没什么问题，当数据量大了之后，一次刚性事务就会占用系统极大的资源，对用户的响应和并发都造成影响。之后改用柔性事务的处理，把请求放到一个队列里执行，这样就避开了并发，只是用户操作的结果不是即时有效，有系统处理的延时，也就是最终一致。不过当时开发的时候不知道ACID,BASE的概念。
支付宝是7*24小时运行的系统，其中各种服务上百个。这样的系统开发，维护都是一个大问题。先说开发，编码之后的测试，光环境就需要上百台机器，这可不是每个开发人员都能得到了。然后是维护，系统需要更新，但服务不能停，怎么办。例如有50台机器需要更新组件，就先停25台进行更新，然后开启，再更新另25台。这就要求组件的向下兼容性要好，更新的过程要严谨。
随便提一下支付宝的开发模式，以产品线为组织形式，各产品线每周提交一个更新包进行系统改进。新加的项目周期控制在3个月以内。没有严格的模式定义，比较倾向于敏捷。目前开发人员在200左右。
整体来说，现在的支付宝架构良好，开发有序，前程一片光明啊。
反观自己，架构还在初级阶段，开发混沌，路漫漫兮其修远 吾将上下而求索。
