这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第二部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会，欢迎做些技术或者业务方面的交流，
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。

书接前文

支付宝每时每刻都要应对海量的数据和交易，是否使用了类似于”云计算”的方式进行后台处理？对于业界现在热炒的”云计算”概念，你们团队有什么想法？

的确，支付宝的数据堪称海量，但相比之下，主要的压力还是来自对交易事务的处理上。我们也有一些密集型的后台计算，但相对规模不算特别大，当前的计算能力足以支撑，当然，我们也尽量会想办法用更小的成本提供更强的计算能力。

对于云计算，我们目前还没找到很合适的应用场景，但整个架构组目前对云计算保持密切的关注，并会投入适当的力量进行一些前瞻性研究。我们实际上更为关注一些解决方案，比如 Hadoop ，并准备在 DW/BI 方面进行一些尝试。

冯大辉曾经在一个访谈中提到：技术架构与产品设计这两者的优劣，会对 Web 应用的发展起到至关重要的作用，那么这二者应该如何平衡？在支付宝进行架构设计和产品设计时，是怎么样进行权衡的？

通常情况下我们的技术架构是可支撑产品设计的多样性需求的,但仍有部分产品设计因市场的差异化需求非常特殊,造成我们的技术架构要支撑这部分产品产生了一定的挑战,这也是因为我们的所处的行业是一个迅速发展的行业有关,一方面我们加强技术架构的灵活性和前瞻性研究，另一方面我们也同时加强对产品设计的规范指导,使其两者达到平衡。

我们在技术架构的发展上做了很多课题性研究,如遇到新产品的设计技术架构无法支撑的情况下我们对产品所带来的收益与需扩展技术架构的投入成本上做出分析权衡.

高性能设计中缓存技术是最常用到的，您们在架构设计中通常怎样考虑缓存问题？

现代大型系统中，Cache 是个非产关键的组件，在具体实践中，我们会依据支付宝自身的数据特点对数据部署缓存策略，支付宝对数据实时性的要求造成Cache的准确性要求极高，而数据的私有性造成提高Cache命中率难度较大。客观地说，目前对于 Cache 的利用应该说还不是很充分，这有待于我们进行更深入的研究。

简单的说几点经验，一个是要合理的选择 Cache 所在的位置. 简单的说，Cache 的位置有几个地方:

Web服务器层 -> 应用服务器层 -> 数据库层

具体使用哪个 Cache 以及在哪个位置来做 Cache，要依据缓存什么、性能要求、数据量、可伸缩性、事务要求、过期特性、一致性要求、可复制性、硬件投资、开发投资多个维度来考虑。如果 Cache 的位置选择不合适，那么系统伸缩性会受到严重影响，每次 Cache 系统实施之前，需要架构师进行充分的论证和评估。

第二点，在Cache 存储的资源粒度，需依据 Cache 资源的特点，比如登录者基本信息，就完全可以一次性缓存起来，对于聚合关系结构的业务对象，在缓存的时候需要考虑业务特点，如果业务上对聚合对象内部的对象访问就很频繁，那么就考虑选择小对象力度缓存，否则考虑大粒度对象。第二点是Cache自身的特点，本地JVM Cache，可以考虑存储大对象，因为此时没有网络访问、数据流量的考虑，那么即使业务上小对象访问比较多，也可以考虑完全缓存整个对象关系；如果是远程 cache，那么就要依据大粒度和小粒度对象访问的频率，然后决定。

Cache 是个非常庞大的话题，如有必要，可以选择另外的时间进行探讨。

分布式是架构设计中最有挑战的任务，您们在分布式设计中主要从什么角度出发？怎样选择按用户拆分和功能拆分？

考虑到支付宝的业务特点， 无论我们做什么应用，安全性、可靠性肯定是排在第一位的。然后我们会重点考虑性能和可扩展性。支付宝现在已经是最大的第三方支付工具，日益增长的交易量给架构师们带来了很大的挑战。我们在具体实践中也从BASE 策略中得到很大参考：

Basically Availble --基本可用
Soft-state --软状态(柔性状态)
Eventual Consistency --最终一致性

目前的拆分原则主要是遵循 SOA 的思路，面向服务进行拆分，这也是基本原则之一。 至于是否按照用户拆分，只要不违背 SOA 即可。

对于开放平台、开放 API、以及SaaS这些互联网的新风潮，支付宝架构团队有什么看法？

开放平台这个词最近确实非常火，好像一夜之间大家都开放了。开放确实是一种趋势，任何一个互联网公司都只是整个互联网生态圈中的一环，只有开放才能让自己更好的融入到整个生态圈中。这是大方向，大方向确定了，剩下的事情就是如何开放，开放什么的问题了，这也是每个互联网公司需要仔细考虑的问题。

我觉得随着公司业务的不断发展，开放是一个必然的结果，我们在支付宝创建初期就意识到整个支付市场是非常大的，在服务好淘宝的基础上应该大胆的走出去，去为更多的电子商务平台提供支付服务。所以，我们很早就推出了支付宝商户平台，在这个平台上我们提供了大量的交易、支付服务。通过这几年的运营，我们确实尝到了开放的好处（外部商户为我们的交易量做出了很大贡献），同时我们也积累了很多开放的经验。目前我们正在开发一套新的开放平台，我们希望通过这个平台，可以为我们的合作伙伴提供更多、更好的服务，同时也希望有更多的第三方公司能在我们提供的基础服务之上，创造出新的商业模式。

如果说”面向服务架构”使企业IT系统支持业务敏捷化的话，开放平台则是使互联网大系统支持整个行业生态圈的业务敏捷化。开放平台、是企业追求开放式成长的必然道路，也是SOA原则走出企业系统的狭小圈子、在广袤互联网上的自然延伸。以支付宝的实践来看，在2005年中，支付宝就针对互联网交易提供了API，为互联网上的电子商务提供安全交易与资金流解决方案。随着业务领域不断拓展，原来的从需求->解决方案->产品->API的方式，周期太长，已经难以快速满足大量合作伙伴的需求。因此，支付宝现在正在由产品式的开放转向平台式的开放，通过加强开放基础设施的建设，向合作伙伴提供更基础、更可重用、更体系化的服务，达到与合作伙伴充分协同，建设繁荣、共赢的电子商务生态圈的目标。

同时，开放的业务服务与开放的技术平台也正在推动支付宝的业务与技术架构向前发展，对构建更大规模的分布式系统、更大规模的并行研发模式都带来了积极而深远的影响。

对于有志于成为架构师的开发者，支付宝架构团队有何建议？

技术不是一蹴而就的事情，而是长时间积累的成果。此外，扎实的基本功是做好所有事情的开始！抽象的能力也是作为一名好的程序员必须具备的，我们在考虑问题的时候可能会遇到错综复杂的场景，从这些迷雾中找到一条明路是我们做好程序员的关键。实际抽象能力衍生出来的一点就是需要我们对已学过的知识定期的进行梳理，这样能让你稳固已有的知识，为以后学习的更多的知识做好准备。

实践也是非常重要的一个环节，不要有畏难心里，觉得这个东西非常的难，我无法完成！有时候你去完成一件事情，事情的结果可能会是糟糕的，但是解决这件事情的过程是非常宝贵的，你可以在这个过程中学习到很多东西！最后我还要说一点的是，业务知识非常重要，这个是你实践的关键！(by 胡喜)

架构师在设计系统架构，或者对重大问题进行决策时，必须在全面考虑各种因素、充分前瞻的基础上做出全局最优的选择。这种整体性与发展性的思考模式是一种能力，也是一种习惯，一种态度。作为有志于成为架构师的开发者，应该在日常开发中就养成站在整体、发展的角度去理解、分析、与解决问题的习惯。(by 程立)

再补充三点:

• 1、从程序员到架构师：是思维提升的一个过程、责任心升华的一个过程、是一楼向楼顶攀爬的一个过程，每一层楼，都要向下、向上、向远处看(注：这个楼顶有多高？没人知道 ：） ；
• 2、读别人的代码、框架，看身边同事做事情，与同事一起讨论问题等，要始终尝试：交换思想的苹果，达到 1 + 1 > 2 ；
• 3、找一个架构师老师，榨取他身上的每一点优点(别把坏的也给学去了) ；

(by 姚建东)

架构师在成长过程是个顿悟的过程，需要自己注意及时总结，尤其是不可能不犯错误，但是需要自己通过每次所犯的错误进行深刻的总结提升自己。提升的过程是个螺旋式上升的过程，自己以前也做失败过一个案例，至今记忆深刻，通过这次深刻的教训，对自己的成长是很有帮助的。遇到错误不要怕，要坦然面对，能做到:犯错误–>提升–>避免错误就可以了。(by 王学安)

1，架构师往往是领域专家，持续关注领域发展和创新、领域知识，了解领域需求，并将领域需求不断的融入到架构模型里，侧重领域功能布局。
2，架构师往往是技术专家，持续的关注技术知识，架构模式，设计模式以及技术规范等，技术架构关注点可以是，开发高效、复用、安全、可维护可管理、灵活等。
3，实践出真知，持续关注领域、技术，勇于实践。( by 刘明源)

附录：可能有的朋友已经知道支付宝的花名文化，这次接受采访的同事花名可以列一下：鲁肃、苗人凤、西毒、阿玺、邓芝、庞统、夫差、李磊、俊义。(猎头们就别盯着这里看了，做点有技术含量的事儿吧)

–EOF–

这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第一部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会，欢迎做些技术或者业务方面的交流，
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。

Note：提问者：《程序员》杂志郑柯。回答者：支付宝架构师团队。

能否介绍下支付宝架构团队的构成以及各位的知识结构?

支付宝架构团队里的架构师角色可以划分为首席架构师、技术架构师、业务架构师、产品架构师等、数据库架构师等。

• 首席架构师：制定公司的长期技术路线图。是公司技术方向和技术组合的重要决策者。
• 技术架构师：关注整体网站系统架构。通过技术架构对业务架构提供支撑；（系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责）
• 业务架构师：关注业务架构。对公司战略、客户需求、内部需求进行抽象、组织、规划。关注业务的敏捷性，能够随着战略的变化而变化。
• 数据架构师：负责数据库相关的架构，数据相关的技术研究、规划、评估等。

此外，我们支付宝架构团队里面还有搜索引擎专家专门负责搜索相关的技术，有业务流程专家制定业务流程制定，流程架构开发指引等，可谓藏龙卧虎。

支付宝的架构师中，一部分是从支付宝与淘宝网的内部一线研发人员中成长起来的，在多年的实战中积累了丰富的大规模分布式互联网系统的设计与开发经验，有扎实的 Java 开发功底，熟悉各种开源系统、框架与工具，熟悉主流的企业中间件。支付宝架构团队也有一部分是来自著名 IT 企业的架构师，他们分别在数据库、高性能计算、企业服务总线、工作流、开发工具等专业领域有多年的积累。

支付宝架构师对电子支付行业知识有相当深入的了解，尤其我们的业务架构师，他同时也是会计与支付行业应用的专家。另外，值得强调的是，每个架构师也都会定期带一到两名徒弟，把经验直接传递下去，满师之后徒弟也会承担比较关键的角色，这也让开发团队的同事有更好的上升空间。

支付宝架构团队对自己的具体定位是什么？

支付宝架构团队的日常工作定位在支付宝系统高层架构的设计与优化，其职责是保障系统与公司的愿景与业务体系一致，达到关键的业务敏捷、可伸缩、高可用、性能与安全指标，具备内在的统一性、协调性与可持续发展性，支持支付宝技术团队高效率地研发高质量的产品。

为了达成这一目标，我们会创建并持续优化支付宝的业务架构与系统架构蓝图与发展路线图、参与各类外部与内部标准与规范的制定、评估与指导重大项目与重大的系统变更、主持设计并实现支付宝系统开发框架与工具、以及辅导与培训支付宝技术团队成员等。

支付宝架构团队同时是支付宝未来发展所需的关键技术的孵化器。我们会根据公司的业务方向与趋势，结合行业与技术的发展状况，产出并维护支付宝的技术愿景、技术研究整体规划与发展路线图，并主持开展前瞻性技术的研究。

支付宝架构团队也是公司决策层的智囊团之一。我们会参与公司的发展决策，站在整体业务与技术架构、技术可行性与最佳技术途径的角度，对公司重要项目的决策提供专业性的参考意见。

补充一下，支付宝架构团队一直在招贤纳士，欢迎更多技术牛人加入(Fenng 补充：另外近期在上海会有招聘会)。

架构团队与开发团队之间的沟通多么？主要集中在哪些方面?

沟通是比较多的，一方面是在项目期间会有比较频繁的沟通，主要集中在产品的系统设计是否合理、技术难点支持等方面，有的时候，架构师也会临时”下放”到项目组，与开发工程师并肩战斗；另一方面在非项目时间经常会针对开发模式、新技术走向、如何做好设计和编码等技术角度做分享与交流。

架构团队内部的小范围沟通也不少，大家经常会就一些难点进行思维碰撞、分享、交流。
我们架构组后面的白板好像很少有干净的时候 – 经常是在讨论中拓扑图画满了整个白板。

支付宝架构团队是否经常与阿里巴巴旗下其他公司的架构团队进行沟通和交流？从其他团队哪里学到的最有价值的东西是什么？

为了促进阿里巴巴旗下的各个子公司之间的技术交流，我们成立了一个集团架构委员会。集团架构委员会每个月会有一次线上交流，每个季度会有一次线下的会议交流，而且每个月末各个子公司都会在邮件列表中报告各个子公司技术研究方向和成果。

如果大家都在研究同一种技术，会成立专门的研究小组，进行针对具体技术场景的研究。通过集团架构委员会，我们可以了解各个子公司的技术方向和研究成果，做到互相促进，互相学习，技术共享。

你们认为支付宝架构最令你们自豪的是什么？为什么?

在过去的三、四年里，随着支付宝业务领域的拓展与业务规模的增长，支付宝系统也一直处于快速的增长与变化中，从最初的单一应用迅速发展成由数十个自主系统构成的高度分布又充分协同的大系统。与此同时，支付宝研发团队的规模也从最初的数人发展到现在超过百人的研发团队。在快速奔跑中保持稳定与平衡，对架构提出了很高的挑战。

因此，我们很早就将支付宝系统建立在了面向服务架构(SOA)之上，确立了面向服务的整体业务架构，围绕着公司的基础业务建设了几大核心服务系统，并且搭建了以 ESB 为骨干、以服务框架为基础的面向服务基础设施。这些核心服务以及基础设施是支付宝系统健壮的后腰，它们的高可靠与高可用性是支付宝系统的整体稳定性的基础，它们的灵活性与可重用性支持前端业务有条不紊地创新、整合与优化，它们的可伸缩性保证了系统能够支撑持续的快速业务增长。

面向服务架构不仅是支付宝的运行系统的基础，而且已经渗透到了支付宝的研发与治理体系中，当前，这个领域仍然是支付宝架构团队的一个研究与应用的重点。

能够介绍一下支付宝的架构中用到了哪些 SOA 的思想?

支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。

从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。

在采用SOA思想的过程中，我们从下面2个方面入手：

首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 — 这也是SOA思想的核心。

业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。

接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：

A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。

B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。

C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。

D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。

E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。

–待续–