程立谈架构、敏捷和SOA实践
原文的地址：
http://www.infoq.com/cn/articles/chengli-arch-agile-soa
[size=small]据支付宝公司官方数据，截止到2008年5月6 日，使用支付宝的全球用户已经超过8000万，支付宝每日交易总额超过3.5亿人民币，日交易笔数超过150万笔。看到这儿，我想很多软件开发者朋友可能会问的问题是：这么庞大的支付平台是谁设计的，如何设计的，有什么经验和教训？在2008年5月份阿里巴巴举办的第二届网络工程师侠客行大会上，InfoQ中文站有幸认识了支付宝首席架构师程立先生，并邀请其分享了软件架构设计心得，对当前热门技术的看法，以及在自己团队中对这些热门技术的实践经验等。
nfoQ中文站：请给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，这样做都是必须的。站在架构师的立场看，架构必须有一个好的技术梯队一层层传递下去，才能够有效、持续地贯彻执行，如果只是架构师们冲在前面，背后空了一大片，架构永远只能停留在蓝图上。站在企业的立场看，企业真正的技术实力，不在于已经有怎样的系统或者平台，而在于是否有一个强大而有生命力的技术团队，通过快速复制架构师的技术与经验，可以帮助发展并壮大这样的团队，而企业整体技术实力的提升也促进了架构师提升。[/size]
http://www.infoq.com/cn/articles/chengli-arch-agile-soa
[size=small]据支付宝公司官方数据，截止到2008年5月6 日，使用支付宝的全球用户已经超过8000万，支付宝每日交易总额超过3.5亿人民币，日交易笔数超过150万笔。看到这儿，我想很多软件开发者朋友可能会问的问题是：这么庞大的支付平台是谁设计的，如何设计的，有什么经验和教训？在2008年5月份阿里巴巴举办的第二届网络工程师侠客行大会上，InfoQ中文站有幸认识了支付宝首席架构师程立先生，并邀请其分享了软件架构设计心得，对当前热门技术的看法，以及在自己团队中对这些热门技术的实践经验等。
nfoQ中文站：请给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，这样做都是必须的。站在架构师的立场看，架构必须有一个好的技术梯队一层层传递下去，才能够有效、持续地贯彻执行，如果只是架构师们冲在前面，背后空了一大片，架构永远只能停留在蓝图上。站在企业的立场看，企业真正的技术实力，不在于已经有怎样的系统或者平台，而在于是否有一个强大而有生命力的技术团队，通过快速复制架构师的技术与经验，可以帮助发展并壮大这样的团队，而企业整体技术实力的提升也促进了架构师提升。[/size]