剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
文章：程立谈架构、敏捷和SOA实践
作者 霍泰稳 发布于 2008年7月17日 上午2时55分
在2008年5月份阿里巴巴举办的第二届网络工程师侠客行大会上，InfoQ中文站有幸认识了支付宝首席架构师程立先生，并邀请其分享了支付宝技术架构的发展，对架构的认识，成功架构的特点，如何避免架构设计的失败，以及在敏捷和SOA方面的实践等。
据支付宝公司官方数据，截止到2008年5月6日，使用支付宝的全球用户已经超过8000万，支付宝每日交易总额超过3.5亿人民币，日交易笔数超过150万笔。我们可以想象这么庞大的一个支付平台的背后，其架构师所承受的压力，以及其在架构设计方面的经验和教训是多么难得。这也是InfoQ中文站就软件架构方面的问题采访程立先生的主要原因。
在文章中，程立结合支付宝团队的经验谈到对架构的认识：
老子说“道生一、一生二、二生三、三生万物”。在业务愿景的技术实现过程中，假设“道”为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。战略是整体的、长期的，让架构直接承接战略，带来的最大好处是可以得到一个整体的可持续发展的系统平台。而如果只是让架构从属于项目或者产品，很可能产生的系统也是烟囱型的，短视的。
这是支付宝公司内部对架构的定位。作为技术人员，常常遇到的问题是“提供一个X产品，它的流程为Y，高峰期处理量达到Z。”；也有一些问题的提法有所不同，比如“我们希望进入X市场，Y是我们的主要价值点，这个市场未来三年可能有Z倍的增长，系统能帮我们做什么？”。在我所在的团队中，第二类问题总是由架构师出马，而第一类问题，只要X、Y、Z不太离谱，基本不需要架构师操心。当然，如果现有架构难以支撑这个需求的话，那架构师也是责无旁贷的。
阅读全文：程立谈架构、敏捷和SOA实践
相关活动：7月26日QClub杭州站──程立与您分享“当SOA遭遇现实”的心得
赞一下 Infoq 编辑们的敬业精神
发表人
Fenng David
发表于
2008年7月18日 上午3时5分
Re: 赞一下 Infoq 编辑们的敬业精神
发表人
Leon Hsu
发表于
2008年7月18日 上午4时37分
Re: 赞一下 Infoq 编辑们的敬业精神
发表人
霍 泰稳
发表于
2008年7月18日 上午9时37分
Re: 赞一下 Infoq 编辑们的敬业精神
发表人
mingyuan liu
发表于
2008年7月18日 下午8时34分
期待26日和大家的相聚与畅谈
发表人
li cheng
发表于
2008年7月20日 上午4时18分
恭喜啊
发表人
huang yifu
发表于
2008年7月20日 上午6时21分
Re: 恭喜啊
发表人
henter chi
发表于
2008年7月21日 上午3时52分
Re: 恭喜啊
发表人
li cheng
发表于
2008年7月21日 上午5时33分
关于SOA在企业中的应用
发表人
雨 谷
发表于
2008年7月23日 上午3时8分
Re: 关于SOA在企业中的应用
发表人
li cheng
发表于
2008年7月23日 下午10时14分
Re: 关于SOA在企业中的应用
发表人
雨 谷
发表于
2008年7月24日 下午9时10分
Re: 关于SOA在企业中的应用
发表人
li cheng
发表于
2008年7月25日 下午9时45分
Re: 关于SOA在企业中的应用
发表人
凉粉 小刀
发表于
2008年7月25日 下午10时48分
Re: 关于SOA在企业中的应用
发表人
Tony Cao
发表于
2008年7月29日 下午11时45分
Re: 关于SOA在企业中的应用
发表人
ken H
发表于
2008年7月27日 上午2时22分
可贵的真实：关于架构设计的失败
发表人
Charlie Zhang（张恂）
发表于
2008年7月24日 上午9时15分
赞一下
发表人
liujun zhang
发表于
2008年8月25日 下午10时45分
-
也希望在本月 26 号的 QClub 上能邀请更多的业界朋友来支付宝畅谈技术 :)
-
侠客行大会的时候正在赶毕业论文，没去可惜了。
-
感谢大辉的肯定，没有最好只有更好，InfoQ中文站一直在努力:)
这次杭州QClub活动，华章公司会为每个参会的朋友提供一本《硝烟中的Scrum和XP》，并为活跃用户提供一些SOA方面的书。期待程立在QClub上的精彩演讲。 -
相信程立一定会结合支付宝的实践给我们带来一份技术共享大餐，值得期待哦。
-
很有幸认识了InfoQ中文站并接受了访谈，一直觉得InfoQ很专业，在本次合作的过程中对这一点体会更深了。
期待本次在杭州举办的QClub上能结识更多的同道好友。 -
恭喜Cheng Li同学啊
没想到在这里看到你的采访,不错不错,呵呵 -
yifu 和程立还是老同事啊 呵呵
-
yifu, henter, 本是同根生，相见何太急啊，呵呵
-
很欣赏程先生的见解，并从您的文章中了解一些支付宝的技术方向。有个问题想向您请教：您文中提到支付宝的设计基于SOA原则，那么支付宝系统中有没有采用目前较为先进的一些开源的SOA产品呢？比如Apache Tuscany,Apache CXF等；还是说贵公司采用自己私有的SOA架构。是不是说支付宝系统以自己的实践证明了SOA思想切实会成为新一代的软件设计理念，并成熟应用于能承受大规模访问的企业级应用中？谢谢
-
谢谢谷先生的关注，说请教实不敢当，针对你关注的两点谈谈我们目前的情况与看法吧。
关于第一个问题，在多位同事的努力下，支付宝搭建了一套自主研发与开源产品相结合的SOA框架，并且还在持续地改进中。自主研发与开源之间分工方式是：面向开发者，基于POJO、自定义XML标签与Java注解，围绕"组件"、"扩展"、"服务"、"事件"、"策略"等概念提供一套SOA编程模型，这套编程模型是现有主流服务与组件标准的一个剪裁过的超集；在中间层，采用了通用性与扩展性强的开源产品作为工具；在底层，垫上自己的设施，根据硬件资源、研发、运维方式的特点，解决高可用、可靠、监控、性能等需求。这有点像是三明治，开源产品是当中的夹心。举一个例子，当要发布一个服务时，开发人员在Spring bean配置中，通过自定义标签来描述需要发布成服务的组件、操作、集成模式与发布策略；标签处理器将这个组件与描述信息组装成服务对象，注册到开源ESB Mule中；服务的访问则是通过定制的Connector提供的。采用这种做法，我们期望开发人员面向的是清晰、一致、可扩展、易剪裁的编程模型；开源产品作为工具，降低了中间层的研发成本、对开发人员可以做到透明，替换成本较低；在底层，针对业务与环境的特征，可以进行针对性的优化。
关于第二个问题，支付宝系统既有互联网系统实时海量访问、7*24可用、快速变化等特点，也有传统企业系统严格事务处理、流程庞杂、集成繁复等特点，因此总的说来，支付宝的实践，是SOA思想在大规模企业系统中切实可用的又一个例证，实践表明它的确能简化分布式系统构建中的很多难题。但就SOA的技术与标准体系而言，还并非全都适用于大规模系统。比如WS-Transactions，虽然去年被OASIS接受为标准，但我不知道是否在大规模互联网应用中有成功案例 -- 拿其中的WS-AT为例，仅仅完成一个最简单的两参与者分布事务，就需要近20个协议消息、需要资源层XA支持，需要对事务状态进行复制或持久存储、需要复杂的故障自动检测与恢复等等，带来一系列性能、伸缩性、可靠性、部署复杂性等问题，离可成熟应用的阶段还有不小的差距吧。此外，诸如高度并行开发中的环境与测试问题、7*24小时系统中服务的无缝升级问题等等，SOA现在也还没有满意的答案。现阶段这些问题往往需要架构师结合本企业的业务特点与研发模式，创造出独特的解决方案。希望看到社区中关于SOA深度实践的更多讨论，推动更先进的模式、标准与工具的出现。 -
支付宝的每个重要子系统都历经了若干个大的版本升级 ... 但也有一些系统的升级则是接近于返工，架构重新设计、代码重写、数据模型重新设计、已有数据大迁移。路遥知马力，虽然这些系统在上线的当时都达到了功能与质量要求，但时间可以判定架构成功与否。
...
架构设计不可能不犯错，因此很重要一点是当发现架构设计有错误时，一定不要尝试掩盖或者固执地坚持自己的错误，调整得越早，付出的代价就越低。好的企业一定有一个非常宽容的氛围、允许犯错并且鼓励及时改正。我曾经有过几次在开发已经进行到三分之一甚至更久时，发现架构设计有严重缺陷的经历，由于及时调整，加上团队的理解与配合，最终项目仍然取得成功，因此对这一点感受很深。
能够正视失败和错误，而不回避和掩盖，正是真正的职业架构师的宝贵素养。
敏捷 OO 教练 张恂
www.zhangxun.com -
非常感谢您详细的回复。在IT技术飞速发展的今天，各种概念和开源产品曾出不穷，国内的IT公司还处于跟随和学习的阶段，因此这些舶来品是否确实能够提高生产力，还需要实践的检验。支付宝在这方面显然走在了国内的前沿，应该也积累了许多这方面的经验。我想作为国内技术领先的IT公司应该把贵公司的这些最佳实践共享给大家。很希望程先生能够围绕支付宝平台撰写一本关于开源产品和SOA在支付宝平台应用的最佳实践的架构设计的书籍，带动整个中国的企业级应用水平的提升。
-
非常赞同您说的用实践去检验SOA概念与技术，并且通过案例分享来推动SOA应用与创新的观点。
回想几年来，我们也经历了从观望与学习、到小心翼翼地尝试与跟随、到敢于将最核心、最关键的业务建设在SOA的思想与技术基础之上、到对未来之路的思考与寻求突破的各个阶段，这个过程中积累的实践体会的确值得和大家交流。现在，支付宝技术团队也正在探索一些与社区进行互动的形式、通过与社区的交流增进相互间的了解、互通有无、共同进步，这会是一个长期的方向。
您说的通过写书的形式分享支付宝的实践体会，很不错的建议，我们会认真地考虑，非常感谢。 -
谷雨……请问你是吉大毕业的么？
-
谢谢提供这么好的资料 仰慕中......
-
淘宝网和支付宝的系统和架构设计,即使和国外类似系统相比也丝毫不逊色.而且功能和user experience方面个人觉得比ebay还要超出不少.
-
有几个问题比较好奇，不知道能否分享一下经验？
稍微估算了一下日交易笔数超过150万笔，按每日10小时最忙，也就是平常15万笔每个正常访问小时，每秒50笔交易。
第一： 不知道每笔交易核心处理最耗时是多少？从用户请求到银行的connector系统,整个交易时间不知道大概要花时间？
第二： 整个业务应该需要事务的处理，用jms发送消息，怎么控制整个事务。
第三： 怎么做到high availability, 说不定银行的系统也会有问题。
系统框架的设计肯定是分解功能，满足scale ability.
能分享请多谢
.gif)
17 条回复
回复