支付宝大规模SOA系统(转载)

Dear 丶 2022-06-11 00:46 136阅读 0赞

大家好，这里是首届QCon Beijing的现场，现在坐在我的旁边是的支付宝的首席架构师程立。先给大家介绍一下，支付宝架构发展到今天，经历哪些时期，都有哪些里程碑？  
我 回忆一下，支付宝系统架构发展大概有这么几点。我本人大概是2004年下半年参与支付宝系统建设的。当时的目标，支付宝系统是面向整个互联网，而不是淘宝 网内部的一个产品。那应该说是支付宝系统的一个起点，那当时非常的简单，就是一个应用程序，提供了我们所有的功能。功能也不多，有我们基本的支付功能，还 有清算的功能，基本的会员管理功能，包括后台管理功能，这是支付宝的第一个里程碑，从无到有的过程。  
  
第二个阶段是我正式加入支付 宝，2005年2月份，进来之后，我们做了一件事情，当时作为支付宝三期，这期项目实际上是一个真正意义上的支付宝，因为支付宝不仅仅是一个交易系统，支 持各种各样的业务。我们希望它能够支持各种各样的交易流程，包括担保型的支付宝交易、即时到帐的交易等等都会在里面。但是当时支付宝主体的系统还是在一个 应用程序里面——我们面向前端用户的系统，包括我们最后交易、支付的、会员管理的，都在这么一个系统里，这是第二阶段。在这之后呢，我印象很深刻，就是在 2005年上半年，这个系统里面有20个子工程，到2005年的下半年，不到半年时间翻了一倍。当然我们也尽可能把一些业务做成独立的系统，但是发现支付 宝大量的业务它的耦合度还是挺高的，所以我们不能把它做到一个系统里面。那这应该是支付宝的第二个阶段。就是我们开始在一个核心的主体应用里面，不断去堆 积我们的业务功能，发展很快。那在2006年初的时候，我们觉得这个不是长久之计，于是我们开始探索怎么样用SOA的思路去解决这样的问题，找一个切入点 的话，我们找的是用ESB，把一些可以异步处理的，耦合度不高的业务拆开，做成单独的业务服务。那这个阶段，大概持续了有大半年左右。这个时候我们发现， 虽然我们把一些相对来说比较边缘的业务拆开，但是对我们核心业务，我们的交易、支付、处理、会员，他们之间耦合的非常紧，基于 ESB，基于消息，我们很难把他们拆开。去年的时候，我们在讨论这样一个问题，我们不能在持续一个应用中维护这么多业务，当时我们支付宝，开发规模已经上 百人，十几个并行项目，每周一到两次发布，工作在这么一个codebase上面，肯定是不可接受的。那我们当时选择交易作为一个点，前面所说的原因，交易 系统当时响应业务的变化已经很吃力了，一个应用程序里面，这么复杂的商业逻辑。我们既要响应前端的快速处理，又要保证交易逻辑不出任何错误，那么选择交易 服务，针对这个服务我们也从技术上做一些重要的构思，我们建立了自己的服务框架。我们之前也做了很多调研，把一些我们不需要的功能拿掉，再把我们特别关注 的一些功能，放上去，那这个项目大概持续了有四个月左右。这是我们支付宝的第一组服务，它是可以支持我们核心业务的。在这个基础上，我们就去拿支付宝最重 要的功能去改造去提升了——支付宝的帐务会计体系，还有支付宝的客户体系。关于这两个体系的建设，我们的思考，从几年前就开始了。那么支付宝最初上线的时 候，业务的范围非常小，但是随着支付宝整个业务领域的拓展，原有的帐务会计体系不论是灵活性还有专业化的程度都不能满足需要。客户的模型，也不能满足很多 业务的需要。首先是在这两个业务模型的基础上，做一个很大的提升。然后我们SOA整个一套业务的思想，把它分装成真正可以支持业务发展的两套服务——会计 帐务服务以及客户信息服务。这两个服务无论从业务和技术上都有挑战。业务上挑战是什么？就是我们业务服务模型是不是能够支撑支付宝未来数年里持续的发展。 还有一个挑战就是技术上的挑战。帐务处理一旦拿出来后，那我们所有的业务，和我们的帐务处理之间全部都是分布的，很显然这个事务就是很关键的问题，还有它 未来的伸缩性，当时我们的会员数可能接近1个亿。我们的交易笔数也是每年翻3番。那这个我们也做了考虑，解决了一些技术上的问题，同时也对交易服务框架做 了一个提升。那么这样的服务全部做完了的话，大概大半年的时间，这个时间是比较慢的，慢的主要瓶颈是，我觉得前面我们讲的业务服务，怎么去识别服务，怎么 去搭建一个可以支撑业务持续发展的模型，这块我们觉得难度非常大，需要有非常强的业务架构思维的人来做这样的事情，那么在支付宝的话，我们这样的人相对比 较稀缺，所以说这样的事情我们只能一件一件去做。可能这两个基础的服务体系搭建完了之后，支付宝的基础服务便形成了一个三角：帐务会计、会员，还有交易， 在这上面，我们发现，有了他们这个基础，我们又产生了很多服务。这时，支付宝应该是一个全面铺开的阶段。SOA对像支付宝这样的企业，既要响应互联网快速 变化，又要保证核心业务处理绝对安全可靠，可持续稳定服务。这是必须的。我们不能想象，支付宝现在数百位开发人员，在一个单体应用程序上，怎么去做。但现 在，我们不但知道如何去做，而且做的更好，我们现在支付宝上海也有研发中心，都能够一起协作，这是SOA给我们带来的价值。  
您基本上把支付宝发展 的历程完整地说了一下。您刚才也谈到了业务，我觉得在支付中业务需求的变化应当是非常快的，支付宝对于这个业务变化是做出了哪些改变，这个是不是支付宝引 入SOA的一个主要的原因？  
之前提到了，引入SOA，首先要让所有人达成一个共识。不光是技术人员，不光是业务人员，还有我们的高层，要达成一个 共识。实际上当时支付宝所有人都看到了，存在一个挑战，就是前面提到的前端快速响应用户需求、后端持续稳定服务，这个快和稳的矛盾。我们觉得首先SOA会 帮我们把快和稳切开，这样的话，才能够让前端真正快起来，SOA在这方面确实给我们提供了价值。但是SOA的话，让我们实现真正的业务敏捷的话，它有更深 的意义，这是我们当时没有看到的，那就是SOA是真正能够让我们的系统和我们的业务架构对齐。因为它统一了业务和技术，通过服务的概念统一起来了。这样我 就能让业务不但符合当前的需要，而且能够符合长远发展的需要，能够符合整个架构，甚至和公司的整个使命、甚至是愿景对齐。这些方面，其实现在我们也在探 索。  
现在支付宝的这个架构是非常优秀的，您觉得对于一个企业来说，一个优秀的架构意味着什么呢？  
架构的话，我个人觉得，可以从很多层面去 理解。我刚到支付宝的话，我看到的架构很狭隘，我就看到了，比如说我写一个框架或者一个公共基础类的，这就是架构，这是我的理解。后来我发现这个架构仅仅 局限于技术的话，真的是太小了，我们会把业务考虑进去。我们希望整个架构，既包含业务又包含技术。双方的基础是统一的，只不过大家面向的客户是不一样的。 大家可能采用的技术手段是不一样的。但是从概念层上里看是统一的。再后来，我发现，光有业务、技术架构，以用户的需求去驱动，也不够。当我们一次、两次、 三次满足用户需求之后，突然发现用户的某个需求可能跟我们原来的设计模型和基础设施是不匹配的，这样如果要快速响应，我们很难去做到。所以说我们这时候， 认识到架构它不是直接面对业务的需求，还有一个输入是企业的战略，架构要与企业的战略对齐，这样的话，才能支持企业长期的发展。战略会规划企业未来几年的 方向，可能的规模，重点的任务。如果架构能够跟它对齐，那架构将会有更强的生命力。  
那，我的理解就是说一个企业要想看这个架构适不适合它，就是看 它是否与企业的战略对齐呢？  
是的。因为说战略，可能有些虚。如果是实了，就是说架构不但要支持当前的需求，对业务需求要有一个持续稳定的支持能 力。而且这个持续稳定，我们很难去估计未来的需求，那这个时候就只能靠战略，如果是和战略对齐的，我们会发现战略里面考虑的未来重点方向，都在架构中有落 实，无论是业务上，还是技术上，这样我们就更加信心，架构是能够支持企业长期发展的。  
下面问一些技术方面的问题。支付宝的系统在SOA化以后，觉 得面对的一个很大的挑战应该是分布式事务的问题，因为事务对于一个交易平台来说应该是非常重要的，那么在这个方面有什么经验给大家讲一下？  
我其实 第一次遇到事务问题，是在建设交易系统的时候，其实交易一旦拿出来，我们就已经遇到事务的问题了。交易系统作为一个单独的系统，帐务系统在另外一个系统里 面，那怎么保证他们之间的事务一致性。当时，由于交易系统本身业务的特殊性，我们当时采用的就是重置的方式，在交易的过程中，可能请求某些帐务，这时帐务 处理可能会失败，这个时候我们保证通过恰当安排交易系统的处理顺序，如果是由于业务原因造成帐务处理失败，那交易系统是能够正常地把业务回滚的。那如果由 于是系统的原因，那交易系统会处于一个等待系统重置处理的状态，这个系统会安全地通过重置的方式，让最后的交易与帐务处理达成一致。交易处理是幂等的，帐 务处理也是幂等的，这是当时的一个处理方案。这个方案比较简单，但是能满足帐户和交易之间是业务的需要。后来提到支付宝把整个帐户的体系进行SOA 化的时候，那帐户系统面对的不只是交易系统，和所有系统都有这种分布式处理的交易。我们需要提升这个框架，满足多系统，多层次的服务之间做分布式事务的需 要，所以当时我们想了很多的方案，我们也是看了一些标准，那个时候正好是2007年的上半年左右，正好WS Transaction作为标准推出来了，我们看了看WS-AtomicTransaction等，而且我们实际做了相应测试的环境，去做一个概念验证， 最后发现实在是成本太高了。完成一个事务，20多条的消息的交互，其中只有1条是业务消息，其他都是系统之间的协议消息。那对于支付宝互联网应用，必须在 很短时间做出响应的交互，我们无法支付这样的成本，那我们只能去考虑一些山寨的解决方案，当时对我们最有启发的一个是Ebay，关于系统设计，他又一些最 佳实践。其中有一条，就是关于一致性的。我们在满足业务需求的情况下，允许有不一致的情况出现。这对业务是允许的，这是一个很重要的思路，虽然他没告诉你 怎么去做。另外呢，亚马逊关于这些方面也有一些很好的阐述，比如说亚马逊有一位架构师，他关于这方面写了一篇文章，当然他也是面向他的场景，比如他们的分 布式存储如何保持一致性，这些对我们也有一些启发，那关于事务我们需要的ACID到底哪些是必须保证的，哪些是可以放宽的，那atomic原子性这个是必 须要保证的，还有isolation，对事物的处理过程中，对事物所涉及到的资源中，我们一定要控制起来，否则如果你再用这个资源做事务中的某些事情的时 候，就可能被人用掉了。如果要是一笔钱的话，用户可能把钱用到了其他的场景，没法在做业务上的处理，那这样的话，就把一些没有隔离性的补偿方案排除掉了。 那还Consistency有一致性我们是必须需要的，但我们要的是最终一致性，我不一定在某一个瞬间完全一致。那我们就认为一致性可以放宽。那最后决 定，在ACID四个属性中，我们放宽一致性的需求，同时我们也是在考虑到未来系统可伸缩的需要，我们一定不能用分布式的事务，标准的基于XA的分布式事 务。在这两个基础上，我们就设计了一套支付宝分布式事务方案，在数据库操作这个层次我们建立transaction，我们的帐务处理是一种TCC的模式， 任何一个帐务处理，你可以Try它，最后你可以Comfirm它，也可以Cancel它。那在这个过程中，有TCC的基础支持的话，结合中央事务协调器， 我们就可以做分布式服务，而且可以多层次的，任何一个服务，都可以做在事务里面。这个也会有成本，像设计一个支持TCC操作的业务服务。当然这方面，我们 也探索出一些模式，可以做得比较好。  
现在支付宝每天的交易量是非常惊人的，在这么大交易量的情况上，在网站的伸缩性设计上，有哪些考量？  
我 们觉得做SOA很大的好处就是他把很多复杂操作的伸缩性，简化成单个服务的伸缩性。比如对支付宝来说，我们有这么多的业务，对伸缩性最有挑战的，还是帐务 处理和会员业务。比如帐务处理，那帐户处理就是相对来说比较单一的一个应用，那对这样的应用，我们有一些比较好的伸缩性的方案，那比如说应用处理，它对 SOA来说是比较简单的，因为每个服务都是无状态的，是自治的，是可以很方便的通过水平扩展的方式去处理。其次是数据，那数据的话，取决于你的使用场景， 如果你的场景支持数据很好的水平分割，那它的伸缩性也不会有什么问题，那从目前来看，因为我们把服务拆开了，对于每一种服务我们都可以选择最适合它的一种 方案。比如会员数据，我们可以很方便的根据会员把他们分开。我们帐务处理其实也是一样的模式。那交易可能会复杂一些，但它也有它相应的模式，但我们并没有 立刻去做这样的事情，因为目前来看，底层的基础还能够做相应的支持，支持我们现在事务的处理，但是我们相应的方案已经准备好了。如果当业务量达到去做分割 的时候，我们就会去做。毕竟分拆之后，对运维，对成本都会有一些相应的要求。我么可以在适当的时候支付这样的成本。  
还有一个问题，其实也是大家都 想问的问题。如果一个公司，它想在系统里面引入SOA的话，您作为一个在这方面的实施有非常丰富经验的人，能给他们提一些建议吗？  
实施方面，关于 SOA怎么实施，其实有很多指导。那我们支付宝实施SOA的话，前面也说到了，就是大概先去学习，对这个概念的认识，基本知识的掌握，获得所有人对走上这 条路的共识，因为只有这个共识，大家才愿意投入这样的资源。因为SOA既有风险的，又要投入很多的资源，而且它不一定会马上看到效果，所以这肯定是第一 步。完成这一步之后呢，需要选择一个切入点，每家企业都有自己最痛/痒的地方，第一个投入这个项目的时候，要找准切入点，在找的过程中，要选择一个既不要 太难，又不要太简单，然后做之后能产生效果的项目，因为太难的话，可能SOA这个项目就会做失败，那对SOA迁移就会产生非常大的打击。如果太简单的话， 又不能起到锻炼技术、锻炼队伍、积累经验的目的。最后它要看到结果，如果看不到结果的话，那后续的资源投入都会遇到问题。  
  
然后下一步，我 感觉支付宝是比较大胆的，我们立刻拿我们最核心的业务去动刀了。这一块我觉得要动，早动会比晚动好。我们在2007年去动这块业务，当时我们敢动。现在如 果动的话，我相信会有更多的挑战、更大的难度。那整个基础打好之后，这个时候我想，包括你的基础设施，包括你的主要的SOA团队的建设，包括前面讲到基 础，不光是技术基础，也是业务基础，包括整个一套的方法论，无论是已经正式成形的，还是大家口头认识上的，都应当有一定基础了。这个时候，可以让SOA交 付它的价值了。但是我们支付宝，有一方面我们觉得做得还不够，还需要改进。就是治理引入太晚了，对于治理的问题，我们并没有非常早的意识到，一路的高歌猛 进，但是后来发现，SOA会引入一些问题。使系统在某些方面变得更加复杂，更加难以控制等等这样一些问题，包括怎么让SOA真正交付价值，这些都需要治理 来支持。  
  
今天我才看到，有一篇应用SOA治理的报道，非常有意思，它里面就提到，如果你的系统服务个数达到50个以上，治理的话，不但要 有，而且是正式的，得到了充分资源的保证的流程，实际上治理的话，不能说没有，一开始我们是一种人治的方式，通过这么多SOA系统建设的话，我们有一个很 好团队，通过他们的口头的方式治理，但是随着整个服务体系全面铺开，靠人是很不靠谱的。我们希望如果有其他的企业想要走在SOA这条路的话，希望能够把治 理尽量提前。  
非常感谢程立接受我们的采访，谢谢大家。  
谢谢。  
我这边有两个问题想问一下程立，其实对于企业来说，它从业务角度上来 考虑SOA松耦合、多重复用等特性，您认为从架构的策略上面会有哪些原则可以遵循来实现这样的一个业务上的问题？  
在架构方面的话，我想，首先 SOA有一个很高层次的架构方面的指导，就是对一个企业来说，它的服务并不是所有服务都是遵循平等的，每个服务都有各自的安排。比如说对支付宝来说，我们 有的服务是我们核心业务服务，有的是合作伙伴的服务，有的服务是我们产品的服务，有些服务是我们后端管理的服务。有了这么一个安排之后，要有规划的、有计 划去做好每一个服务组，然后在这大的规划之后，才能有系统的去识别，在我这个业务里面我需要怎么样的服务。而不是，看到一个需求，就做一个服务。这样的 话，整个系统就不成架构了。这块儿的话，支付宝是一直努力去做，加深大家的理解，让这个服务的识别能够更加匹配这样的架构。  
整个SOA改进的过程 中，有没有遇到一些平台转型的问题？  
平台转型的话，应该是感谢Java企业开发技术，越来越轻量化，侵入性越来越小了。无论是开源产品还是商业产 品，它都能做到这样。所以平台转型方面，虽然我们有考虑，但是我们也没有在这方面做太多的工作，实际上我们大量SOA基础设施都是我们自己开发的，因为考 虑到我们只需要这样一些功能，我们不需要其他的功能。而且我们这些功能又有很多个性化的需求，所以我们倾向自己开发。