BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

程立谈架构、敏捷和SOA实践

| 作者 霍泰稳 关注 1 他的粉丝 发布于 2008年7月18日. 估计阅读时间: 22 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

支付宝公司官方数据,截止到2008年5月6日,使用支付宝的全球用户已经超过8000万,支付宝每日交易总额超过3.5亿人民币,日交易笔数超过150万笔。看到这儿,我想很多软件开发者朋友可能会问的问题是:这么庞大的支付平台是谁设计的,如何设计的,有什么经验和教训?在2008年5月份阿里巴巴举办的第二届网络工程师侠客行大会上,InfoQ中文站有幸认识了支付宝首席架构师程立先生,并邀请其分享了软件架构设计心得,对当前热门技术的看法,以及在自己团队中对这些热门技术的实践经验等。

InfoQ中文站:请给InfoQ中文站的读者介绍一下您自己。

程立:InfoQ中文站的读者,大家好,我叫程立,来自支付宝架构团队。和大家一样,我也是InfoQ的忠实读者。从2004年起,我开始参与淘宝网与支付宝系统的建设,并于2005年正式加入支付宝,此后一直从事支付宝系统的研发工作。现阶段,我的兴趣在于适合电子支付行业的敏捷、高可用、可伸缩的面向服务架构与开放架构。非常高兴InfoQ中文站提供了这样的机会,让我能够代表支付宝的工程技术人员和大家进行交流,希望这样的交流能增进我们的相互了解。

InfoQ中文站:支付宝技术架构的发展过程是什么样的?

程立:三年多前的支付宝系统只有一个应用程序,而今天,仅仅在你点击支付宝支付按钮的一瞬间,取决于你选择支付方式,很可能调动了数十个独立的系统同时为你提供服务:有的帮你联系银行,有的帮你支付货款,有的推进你的交易,有的帮你联系商家发货,有的警惕地盯着这一切,为这个过程保驾护航……支付宝系统从一个朴素的轻量级Java应用程序,发展到现在由很多自主的服务系统构成的全分布式系统,是一个朝着明确的方向、迈着小而快的步伐、与业务齐肩并进的发展过程。这个过程大致分为两个大的阶段。

第一阶段是基于良好的业务边界,将一根粗烟囱似的应用程序拆成若干个细一些的烟囱。这种切分方式,可以使应用程序间的通信尽量小,只有少量的页面跳转与组合,以及基于JMS的异步消息交换。这种简单的分布就带来一些相当直接的好处,如单个系统的复杂性降低了,研发的并行度提高了,每个系统可以单独进行伸缩。公共的业务,比如账务与交易的处理等,被实现成可共享的类库,打包在每一个应用程序中,这样,可以仍然使用单数据源上简单、低成本的本地事务来保证业务处理所要求的原子性、一致性、隔离性与持久性。在这个阶段,新业务只要是自成体系的,都尽量作为单独的应用程序实现。

在第二阶段,为了使业务核心更加专业化,前端应用能够轻装上阵,我们将原来类库形式的业务核心一个接一个地拿出来,做成了自主的服务系统。这是一个充满业务与技术挑战的过程。仅从技术架构上说,为了使服务能够快速构建、灵活扩展,我们研发了组件式平台,使服务自身能够通过插件式体系进行灵活扩展;为了提供电子支付业务所要求的严格事务一致性、快速响应与高并发处理能力,发展了分布式服务系统中事务协调技术;我们也发展了企业服务总线技术,以提供统一、易于功能扩展、满足各种服务质量要求与集成模式的服务通信机制。每个服务系统连同它操作的数据都是一个自主的业务单元、系统单元与研发单元,很好地支持了业务模型创新、系统伸缩、研发组织小型化与专业化。

总体说来,虽然发展速度较快,但支付宝的技术架构仍然处于一个布局与打基础的阶段,对技术高度重视的态度,和紧紧抓住“服务”不放、持续小步快跑的执行策略,使我们在这个阶段打下了一个良好的发展基础。面对前方业务发展的巨大空间,架构与技术大有用武之地,在这里欢迎有志之士加入我们,共同开拓未来。

InfoQ中文站:请谈一谈您对架构的认识。

程立:老子说“道生一、一生二、二生三、三生万物”。在业务愿景的技术实现过程中,假设“道”为愿景、一为方向、二为战略的话,三就应该是架构了,架构既出,万物化生可矣。战略是整体的、长期的,让架构直接承接战略,带来的最大好处是可以得到一个整体的可持续发展的系统平台。而如果只是让架构从属于项目或者产品,很可能产生的系统也是烟囱型的,短视的。

这是支付宝公司内部对架构的定位。作为技术人员,常常遇到的问题是“提供一个X产品,它的流程为Y,高峰期处理量达到Z。”;也有一些问题的提法有所不同,比如“我们希望进入X市场,Y是我们的主要价值点,这个市场未来三年可能有Z倍的增长,系统能帮我们做什么?”。在我所在的团队中,第二类问题总是由架构师出马,而第一类问题,只要X、Y、Z不太离谱,基本不需要架构师操心。当然,如果现有架构难以支撑这个需求的话,那架构师也是责无旁贷的。

InfoQ中文站:一个成功的架构应该具备什么特点?

程立:架构必须能够达到功能与质量要求,以合理的研发、运行与管理成本产生使客户满意的系统,这是一个基本要素,否则是不及格的。但仅仅满足功能与质量要求的架构,还谈不上成功。

在长距离赛跑中,能够让系统以轻松的步伐始终跑在业务前面,是成功架构的一个显著特点。为了支持这几年业务的快速发展,支付宝的每个重要子系统都历经了若干个大的版本升级。这些升级有些是沿着事先规划好的迭代式发展路线进行的,在保持整体架构稳定的情况下,通过增加功能、扩展数据模型、引入新的处理模式、不断地扩展着功能与性能,持续给予业务强劲的支撑;但也有一些系统的升级则是接近于返工,架构重新设计、代码重写、数据模型重新设计、已有数据大迁移。路遥知马力,虽然这些系统在上线的当时都达到了功能与质量要求,但时间可以判定架构成功与否。

成功架构的另一个显著特点是能够对公司的核心竞争力形成有力的支撑。最近,马云先生在一次公开演讲中,举了一个例子,沃尔玛要增加一万个买家,需要买面积巨大的地,需要买很多的设备,需要很多的仓储;而淘宝只需要增加一台电脑就可以了。这个优势是商业模式带来的,但其背后,是需要有一个高度可伸缩的技术架构来支撑的。

InfoQ中文站:如何最大限度避免一个架构设计的失败?

程立:首先说点外因,架构设计的失败不全是架构师的责任。假如一个企业战略不清,或者虽然定义了清晰的战略,但没有很好的沟通机制让架构师了解战略,很难设计出全局上下一盘棋、富有生命力的架构。当发现看不清全局、看不清未来时,架构师应该设法多沟通、推动改进。如果始终推而不进、沟而不通,就该考虑换个舞台去发展了。不过,对于处于创业期的企业,这一条不大适用,这类企业中,架构发展与业务发展在开始阶段往往是一个快速犯错、快速调整的试错过程,这样的企业走向成功的同时,也常常能够培养出好的架构师。

在做架构设计时必须以业务为本。不是说让架构师去抠业务的枝节,比如流程中的某个环节究竟应该有几个分支、或者某个业务参数应该是多少,而是将精力放在理解业务本质,看清不同业务之间的关系上。在一个业务思想混乱的头脑中产生的系统也一定是结构模糊、行为混乱的。

业务清晰之后,架构师就像导演读透了剧本,可以在脑海中构思与创作了。拟定时空结构、选择风格样式、物色演员、规划每一幕的内容以及幕与幕之间的衔接等等。待一切可以在头脑中栩栩如生、流畅地上演之后,架构其实就出来了。这一步工作做得是好是坏,主要取决于架构师长期以来积累的能力、知识与素养,没有太多的捷径。

有几个算不上新鲜的经验还是值得提一下。首先,架构师要建立自己的QA工具,比如一个质量检查表,能够全方位地从研发、运行、管理等维度,对架构的质量属性进行客观地评估,这个检查表中各项指标的值范围与权重需要针对实际情况进行个性化定制。到了一个新环境中的架构师往往需要一个适应期,在这个适应期中除了熟悉新公司的现有业务与系统之外,很重要的一个工作就是调整原来的质量评估体系,使之新公司的业务相匹配。其次,在架构师头脑中的虚拟舞台上,演员是一个个系统,对每种系统的能力与特性的理解会决定他构思出来的剧情在真实上演时能在多大程度上符合期望,这需要在实践中关注并积累,如果引入了全新的演员,一定得让他试镜。还有一个是习惯问题:不要把脑海中出现的第一个设计当作最终版本,只要时间允许,要多创作几个版本,其间多与同事讨论、做些换换脑筋的事,避免陷于某种定式跳不出来。这需要架构师养成习惯,也需要公司研发流程的支持,比如让架构师尽量早地介入项目,有充分的时间酝酿与斟酌。

最后,架构设计不可能不犯错,因此很重要一点是当发现架构设计有错误时,一定不要尝试掩盖或者固执地坚持自己的错误,调整得越早,付出的代价就越低。好的企业一定有一个非常宽容的氛围、允许犯错并且鼓励及时改正。我曾经有过几次在开发已经进行到三分之一甚至更久时,发现架构设计有严重缺陷的经历,由于及时调整,加上团队的理解与配合,最终项目仍然取得成功,因此对这一点感受很深。

InfoQ中文站:在支付宝的技术团队中,也采用了敏捷的方法,请谈谈这方面的经验。

程立:支付宝的研发体系是从自身实际出发制定的,既要保障产品的高品质,又要保持对业务变化的快速响应,加上协调多个团队高度并行开发的需要,整套研发体系是一个精心设计的严谨结构,也是比较重量型的。但我们还是可以从中找到敏捷方法中的一些重要元素。

首先谈谈迭代。这里,以我所熟悉的支付宝架构团队的研发模式举一些例子。之前提到,支付宝技术架构是采用与业务发展齐肩并进的策略,这个过程就像给F1比赛中的赛车换轮胎,所有架构改进的实施必须安全、快速,尽量不打断正常的产品研发的节奏。因此,在确定技术架构的基本发展方向或者基础设施产品的蓝图之后,我们会将研发工作切分成很短的迭代,每一个迭代的目标明确,一般只解决少数几个技术问题。

以引入企业服务总线为例,第一个迭代的任务是调研,目标是概念验证与产品选型;第二个迭代是试水,我们选择了一个新的业务产品作为服务总线应用的小白鼠,当时的目标是解决高可用部署模式问题、以及集成逻辑的统一管理问题,架构师进入到该项目中,通过服务总线提供该产品与其它系统的集成方案,这个迭代与新产品发布的同时完成;以后的迭代是一系列推广使用的迭代,几次之后,我们完全替换了原来不够灵活的商用JMS服务器集群,并且整个技术团队可以不依赖架构组使用服务总线了;再以后的迭代是服务总线的自身的改进,如QoS的改进、服务治理功能的增加等等。采用这种方式,每一次迭代都有实际可运行的产出,并且其结果可以作为选择下一轮迭代目标的依据。以这种模式,架构发展以一种稳健的方式小步快跑着。但与有些敏捷方法学建议的固定迭代时长有些不同,当“搭顺风车”时,是宿主项目的规模决定迭代的时长。

保证高效的沟通是另一个重要的问题,这通常是采用我们俗称为“闭关”的形式来解决的。项目上到一定规模,就会包下一个会议室,项目经理、架构、系分、开发、测试等人员都会坐在一起,保持沟通的高效率,也减少不必要的干扰。对于长周期的项目、或者需求难以在初期完全确定时,在一个项目内部也设计一些迭代,开发人员增量地交付功能,测试并行进行功能验证,畅通无阻的沟通以及项目经理在场的协调管理是这种工作模式能够顺畅运转的关键。

InfoQ中文站:阿里巴巴和淘宝网的很多架构也是基于SOA的,请谈一下选择和实施SOA的前因后果。

程立:支付宝早期的单一应用程序架构只存在了很短一段时间就受到了挑战。

首先对这种架构发起挑战的是团队组织结构与分工的变化。随着业务领域的拓展,并行的项目越来越多,研发团队也迅速扩大,为了使团队更好地配合业务,走向专业化,我们内部开始按照业务线分组。跨组之间的沟通成本的提高要求必须将各自负责的系统严格切开,降低相互间的耦合度。

另一个挑战与支付宝业务特点密切相关。作为互联网上的新型服务,必须快速变化才能满足需要,曾经有很长一段时间,我们保持每周两次的新版本发布速度;而作为电子支付服务,它又必须绝对可靠、高度可用。为了解决这个稳定与快速的矛盾,我们必须将系统中的业务核心独立出来,由专业的团队、通过更严格的研发体系来支持它的发展;前端应用程序则继续以互联网速度高速发展。

业务、技术、管理上同时提出了解耦的需要,而“服务”很好地统一了这三者,所以,选择SOA作为技术架构的发展方向是很自然的。

现在,我们已经围绕着公司的基础业务建设了几大核心服务系统,并且搭建了以 ESB 为骨干、以服务框架为基础的面向服务基础设施。太极拳中讲究腰功,拳论中说“腰为主宰,腰为轴,刻刻留意在腰间”。这些核心服务以及配套的基础设施很像支付宝系统的“活腰”,它们的高可靠与高可用性是支付宝系统整体稳定性的基础,它们的灵活性与可重用性支持前端业务有条不紊地创新、整合与优化,它们的可伸缩性保证了系统能够支撑持续的快速业务增长。

InfoQ中文站:现在你们也对外开放了很多服务,在架构设计上有做特殊的考虑,或者经验吗?

程立:支付宝很早就提供了外部API,为互联网上的电子商务提供安全交易与资金流解决方案。现在支付宝已有上百个开放的API服务,连接了数十万大大小小的商户系统。

我们觉得设计开放API平台的思路与基于SOA原则进行架构设计很相似:业务上,需要理顺业务关系、划分清晰的企业业务边界、并制定业务处理规范;从技术上说,需要制定统一的技术标准、建设统一的通信基础设施。由于新产品会不断推出,因此,支付宝在内部建立了一个API容器,方便扩展新产品。将SOA搬到互联网上,SOA体系中固有的一些问题,如安全性、可靠性、接口契约的稳定性等问题就会被放大,在架构设计与标准制定时,必须很好地考虑这些问题。

出于安全与合规的需要,支付宝在制定API的业务规范与技术标准时,特别关注身份与安全体系;安全与方便是一对矛盾,为了更好地处理这两者的关系,支付宝在架构上支持灵活的安全体系,可以根据业务特性与商户个性需要,在安全性与方便性之间进行折衷。

互联网上系统交互的非可靠性与交易与支付类业务的可靠性要求之间也是一对矛盾,因此,接口标准与统一的通信基础设施中我们针对可靠性进行了专门的设计。

从接口契约稳定性上说,我们当时的做法是将技术标准设计成允许API接口增加新参数,提供版本参数,提供API接口的个性化配置能力,允许商户定义一部分API上交换的数据与处理行为等。

随着支付宝业务领域不断拓展,原来的从需求->解决方案->产品->API的方式,周期太长,已经难以快速满足大量合作伙伴的需求。因此,支付宝现在正在由产品式的开放转向平台式服务的开放,通过加强开放基础设施的建设,向合作伙伴提供更基础、更可重用、更体系化的服务,达到与合作伙伴充分协同,建设繁荣、共赢的电子商务生态圈的目标。同时,开放的业务服务与开放的技术平台也正在推动支付宝的业务与技术架构向前发展,对构建更大规模的分布式系统、更大规模的并行研发模式都带来了积极而深远的影响。

InfoQ中文站:我们知道,支付宝的架构平台中采用了不少开源系统,为何作此选择?

程立:除了支付宝与阿里巴巴集团自主研发的很多基础系统与开发框架、以及一些商业系统之外,支付宝也使用了很多优秀的开源软件。具有蓬勃的生命力的开源软件对支付宝的技术体系是一个很重要的补充。

在某些领域,一些开源软件几乎已经是事实的标准了,它们的高质量也是经过社区的严格考验的,比如Spring和它的POJO编程模型。通过使用这些开源软件,不但让系统可以在开始阶段就站在一个比较高的起点上,而且对于加入团队的新同事,一开始就可以在一个相对熟悉的环境下工作。

在另一些尚未形成标准的领域,在产品选型阶段,我们一般会在开源系统与商业产品间进行细致地选型,必须能够满足业务所要求的主要功能特性与关键质量要求。在同样能够满足主要功能特性与关键质量要求的前提下,谁具有良好的可扩展性,谁更简单,谁具有长期发展的生命力,谁有好的服务支持,都是最后做出选择的重要因素。其中,可扩展性往往是一个选择的关键因素。基于社区集体贡献模式的开源软件在可扩展性方面往往做得很好。当业务发展到一定阶段,在技术上一定会有大量个性化的需求,所选择的系统必须能够支持快速满足这些需求。开放的源代码也使我们在问题响应时,具有更大的主动性。随着开源系统走向商业化运作,在服务支持方面也开始做得更好,这些都进一步增加了开源系统的竞争力。

InfoQ中文站:请谈一下当前架构师所面临的挑战。

程立:“瞻前”、“顾后” ――这是我现在体会到的最大挑战。

先谈谈“瞻前”。当业务个性不明显、业务规模也不大时,架构师还是有很多容易模仿的定式与先例的。但当业务的个性与规模到达一定阶段时,一定会有一些别人从未遇到过的非常困难的问题需要你去解决。作为站在企业技术金字塔塔尖上的一群人,当过去的经验用不上,搜索引擎也不能向你提供任何有用的答案,只有独立去思考,去做出重大决定时,如果没有充分的准备,对企业对个人都是巨大的风险。这需要架构师建立未雨绸缪的意识,不断推演未来可能的变化并思索应对之策,持续而有方向地积累知识、发展能力,建立广泛的技术交流圈子,并且“顾后”。

再谈谈“顾后”。架构师的另一个重要的职责是发掘团队中的好苗子,帮助他们,使他们赶上并超越自己。无论这一点是否写入你的KPI,这样做都是必须的。站在架构师的立场看,架构必须有一个好的技术梯队一层层传递下去,才能够有效、持续地贯彻执行,如果只是架构师们冲在前面,背后空了一大片,架构永远只能停留在蓝图上。站在企业的立场看,企业真正的技术实力,不在于已经有怎样的系统或者平台,而在于是否有一个强大而有生命力的技术团队,通过快速复制架构师的技术与经验,可以帮助发展并壮大这样的团队,而企业整体技术实力的提升也促进了架构师提升。


程立,支付宝(中国)网络技术有限公司。2004年开始参与淘宝网与支付宝系统的建设,2005年起进入支付宝,一直从事于互联网电子支付系统的研发工作。现任支付宝首席架构师,专注于电子支付系统的分布式服务架构与开放架构。

注:支付宝数据架构师冯大辉,InfoQ中文站编辑郭晓刚、赖翥翔和刘申对本文亦有贡献

相关活动7月26日QClub杭州站──程立与您分享“当SOA遭遇现实”的心得

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

赞一下 Infoq 编辑们的敬业精神 by David Fenng

也希望在本月 26 号的 QClub 上能邀请更多的业界朋友来支付宝畅谈技术 :)

Re: 赞一下 Infoq 编辑们的敬业精神 by Hsu Leon

侠客行大会的时候正在赶毕业论文,没去可惜了。

Re: 赞一下 Infoq 编辑们的敬业精神 by 霍 泰稳

感谢大辉的肯定,没有最好只有更好,InfoQ中文站一直在努力:)


这次杭州QClub活动,华章公司会为每个参会的朋友提供一本《硝烟中的Scrum和XP》,并为活跃用户提供一些SOA方面的书。期待程立在QClub上的精彩演讲。

Re: 赞一下 Infoq 编辑们的敬业精神 by liu mingyuan

相信程立一定会结合支付宝的实践给我们带来一份技术共享大餐,值得期待哦。

期待26日和大家的相聚与畅谈 by cheng li

很有幸认识了InfoQ中文站并接受了访谈,一直觉得InfoQ很专业,在本次合作的过程中对这一点体会更深了。

期待本次在杭州举办的QClub上能结识更多的同道好友。

恭喜啊 by yifu huang

恭喜Cheng Li同学啊
没想到在这里看到你的采访,不错不错,呵呵

Re: 恭喜啊 by chi henter

yifu 和程立还是老同事啊 呵呵

Re: 恭喜啊 by cheng li

yifu, henter, 本是同根生,相见何太急啊,呵呵

关于SOA在企业中的应用 by 谷 雨

很欣赏程先生的见解,并从您的文章中了解一些支付宝的技术方向。有个问题想向您请教:您文中提到支付宝的设计基于SOA原则,那么支付宝系统中有没有采用目前较为先进的一些开源的SOA产品呢?比如Apache Tuscany,Apache CXF等;还是说贵公司采用自己私有的SOA架构。是不是说支付宝系统以自己的实践证明了SOA思想切实会成为新一代的软件设计理念,并成熟应用于能承受大规模访问的企业级应用中?谢谢

Re: 关于SOA在企业中的应用 by cheng li

谢谢谷先生的关注,说请教实不敢当,针对你关注的两点谈谈我们目前的情况与看法吧。





关于第一个问题,在多位同事的努力下,支付宝搭建了一套自主研发与开源产品相结合的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深度实践的更多讨论,推动更先进的模式、标准与工具的出现。

可贵的真实:关于架构设计的失败 by Zhang Charlie


支付宝的每个重要子系统都历经了若干个大的版本升级 ... 但也有一些系统的升级则是接近于返工,架构重新设计、代码重写、数据模型重新设计、已有数据大迁移。路遥知马力,虽然这些系统在上线的当时都达到了功能与质量要求,但时间可以判定架构成功与否。



...



架构设计不可能不犯错,因此很重要一点是当发现架构设计有错误时,一定不要尝试掩盖或者固执地坚持自己的错误,调整得越早,付出的代价就越低。好的企业一定有一个非常宽容的氛围、允许犯错并且鼓励及时改正。我曾经有过几次在开发已经进行到三分之一甚至更久时,发现架构设计有严重缺陷的经历,由于及时调整,加上团队的理解与配合,最终项目仍然取得成功,因此对这一点感受很深。


能够正视失败和错误,而不回避和掩盖,正是真正的职业架构师的宝贵素养。



敏捷 OO 教练 张恂


www.zhangxun.com

Re: 关于SOA在企业中的应用 by 谷 雨

非常感谢您详细的回复。在IT技术飞速发展的今天,各种概念和开源产品曾出不穷,国内的IT公司还处于跟随和学习的阶段,因此这些舶来品是否确实能够提高生产力,还需要实践的检验。支付宝在这方面显然走在了国内的前沿,应该也积累了许多这方面的经验。我想作为国内技术领先的IT公司应该把贵公司的这些最佳实践共享给大家。很希望程先生能够围绕支付宝平台撰写一本关于开源产品和SOA在支付宝平台应用的最佳实践的架构设计的书籍,带动整个中国的企业级应用水平的提升。

Re: 关于SOA在企业中的应用 by cheng li

非常赞同您说的用实践去检验SOA概念与技术,并且通过案例分享来推动SOA应用与创新的观点。




回想几年来,我们也经历了从观望与学习、到小心翼翼地尝试与跟随、到敢于将最核心、最关键的业务建设在SOA的思想与技术基础之上、到对未来之路的思考与寻求突破的各个阶段,这个过程中积累的实践体会的确值得和大家交流。现在,支付宝技术团队也正在探索一些与社区进行互动的形式、通过与社区的交流增进相互间的了解、互通有无、共同进步,这会是一个长期的方向。




您说的通过写书的形式分享支付宝的实践体会,很不错的建议,我们会认真地考虑,非常感谢。

Re: 关于SOA在企业中的应用 by Jacky Li

谷雨……请问你是吉大毕业的么?

Re: 关于SOA在企业中的应用 by H ken

谢谢提供这么好的资料 仰慕中......

Re: 关于SOA在企业中的应用 by Tony Cao

淘宝网和支付宝的系统和架构设计,即使和国外类似系统相比也丝毫不逊色.而且功能和user experience方面个人觉得比ebay还要超出不少.

赞一下 by zhang liujun

有几个问题比较好奇,不知道能否分享一下经验?
稍微估算了一下日交易笔数超过150万笔,按每日10小时最忙,也就是平常15万笔每个正常访问小时,每秒50笔交易。
第一: 不知道每笔交易核心处理最耗时是多少?从用户请求到银行的connector系统,整个交易时间不知道大概要花时间?
第二: 整个业务应该需要事务的处理,用jms发送消息,怎么控制整个事务。
第三: 怎么做到high availability, 说不定银行的系统也会有问题。

系统框架的设计肯定是分解功能,满足scale ability.
能分享请多谢

Re: 赞一下 by Lui Mingle

知道程立的博客地址是多少?很想关注程立并向他学习!

学习了 by 猛 杨

获益良多,谢谢。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

19 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT