分布式系统中的一致性和可用性

——QClub杭州活动（7.26）总结

本文是根据7月26日InfoQ中文站在杭州举行的QClub活动（第三期）后半程小组讨论总结而成。主要内容包括如何在SOA系统中实现服务编排，如何保证分布式系统中的一致性和可用性，以及如何在实施SOA的过程中控制接口的粒度等。活动前半程的嘉宾分享部分，InfoQ中文站已经通过视频和PPT演示的形式发布了。

如何在SOA里面实现服务编排？

SOA系统或产品一般会提供ESB这样一个核心服务。在开发过程中，我们自己曾经用过BEA的WebLogic产品，在它的企业服务总线里面有一个UDDI，里面注册了很多服务。假设目前有A，B，C三种服务，而我们需要用到的一种顺序是ACB，这就需要在一个调用中把这三个服务串起来。在ESB里有一些脚本语言可以把这些服务找出来，然后经过串联形成一个虚拟服务D。从而通过这样的方式把分离的服务编排成一个相互之间有顺序的，能够完成你实际需要的那么一种服务。另外在ESB里面每个服务会有一个事务框架，也就是说每个服务自己是有事务处理。假如要把它们封装到一起形成一个链的话，那么在这个链中任何一个服务的事务失败之后，都会使得整个链中的事务失败，最后回滚到最开始执行的场景，保证整个D服务的事务也是完整的。

图1：演讲嘉宾程立参与分组讨论

如何保证分布式系统中的最终一致性和可用性？

对于本地事务处理，或者是集中式的事务处理系统，很显然我们应该采用已经被时间证明也是很成熟的ACID（注：Atomic/原子性、Consistency/一致性、Isolation/隔离性和Durability/持久性）模型。它会利用到数据库管理系统和成熟的JMS服务器等，用其本身所具有的事务管理功能，来保证程序具有数据库事务处理的这四个特性，对于编程模型来讲，这也是最简单的。但是当我们开发的系统不再是一个简单的集中式系统，比如简单的MIS（管理信息系统），OA（办公自动化系统）或者是博客系统等，而是类似支付宝或者说eBay的Paypal支付系统的时候，其访问量特别巨大和系统结构非常复杂的特点，导致它必须具有一个分布式的架构。又因为系统处理的事情特别多，这也需要它具有很长的事务过程；另外最重要的一点是因为涉及到资金的流转，它对安全性的要求非常高，不允许发生资金的错误。

对于这样的分布式系统，组件的分布会导致它调用的成本和时间代价非常高。如果我们采用传统的ACID本地事务的话，所出现的情况就是系统可用性和严格一致性之间的冲突。因为当我们要求分布式系统具有严格一致性的时候，可用性就会受到损失，而可用性又是一个不允许我们讨价还价的，比如说像支付宝这样的业务，它就要求服务器一年365天7*24小时不间断运转。结果就是我们只能在严格一致性上做出让步，这就需要放弃掉传统的，也是最简单的ACID模型，而选择BASE，即基本可用，柔性状态，柔性一致和最终一致等。对一个“基本可用”系统来说，我们需要把系统中的所有功能点进行优先级的划分，像资金划拨这样的功能在一致性上不能做出任何让步，我们可以选择继续使用这样的严格一致性。而例如邮件发送、通知这样的功能，我们可以对系统做一个选择，降低其一致性的特性，使其具有高度可用性。所谓柔性一致就是系统内的状态对用户来说是一个完整的系统，它的一致性是不允许有任何损失的，就是说用户支付了10块钱，那么他的帐户上必然是只扣掉了10块钱；但是对于系统内部的状态，我们可以采用一种柔性的策略，比如说系统内分布了ABC三个功能模块，我们允许它们在某一时刻三个模块的状态可以不一致。我们会通过业务和技术的手段，比如说异步机制或者批处理方式来保证系统通过柔性状态一致来获得可用性。

图2：QClub杭州负责人冯大辉现场组织

最终一致性其实也是同样的意思，柔性的状态一致只是说某一些阶段不一致，但最终要求系统必须保持一致，也就是说在用户看来你的系统必须是一致的。所以归根到底，BASE的实现是放弃掉纯粹的业务手段，而采取技术和业务相结合的机制来保证系统对于外部看来是一个一致的系统。由于采用了这样一个灵活的策略，使得我们同时具有最终的一致性和系统的可用性。

如何在实施SOA的过程中控制接口的粒度？

针对在SOA中如何控制服务的粒度，以及如何让SOA与现有的业务相结合这两个问题，在我们现在行业里没有一个放之四海而皆准的标准。这个东西一定是你在制订SOA策略的时候就提前做考虑，通过对现有业务进行抽象，然后定义出来SOA系统的接口。在设计这个接口时，我们的原则就是它一定是粗粒度的，不是细粒度的，因为只有粗粒度接口才能够灵活应对我们业务的变化。现在不论是哪一个行业，比如互联网行业和企业管理，它们的业务需求变化都是非常快的。

图3：活动结束后合影留念

在系统日常的工作中，常会冒出一些新的业务类型，但这些类型在我们做业务抽象的时候并没有出现。如果我们当初定义的这个SOA接口粒度非常细的话，那么现在很有可能没有办法处理这样一个新的业务。如果要处理，可能的方法是再投入开发资源去开发一个新的接口，或者在原有接口上再增加新的方法。试想一下，如果现在有一个粗粒度接口，我们就可以把这个新的业务类型包容进来。具体的解决方案是我们可以对外界提供一个粒度很粗的接口，而在我们的系统内部通过很多细粒度接口对它进行支撑。比如说我们现在对外公布一个传递数值的接口，传递过来后，系统返回一个业务操作的具体结果。在这些接口里，假设每一个细粒度接口对应一个业务分支，那么当出现新的业务类型时，因为我们当初定义接口的时候赋予它一定的扩展性，所以能够很容易地更新变化的数据。可以预见的结果是，当有了新的业务类型，我们也不用再担心，只需要再加上几个细粒度接口即可。新的业务分支对应到这几个细粒度接口上去，使得SOA的一个粗粒度对外接口应对所有新的业务变化，而且这个接口的定义整体是没有变的，对外界而言完全是一个稳定服务的接口。

后记

相比于北京、上海、广州等地，在我从前的印象中，杭州的IT氛围还不能算入流。这次和支付宝一起组织的QClub活动改变了我的观点。包括支付宝本公司的几个帮忙的朋友，这次活动共有56人参加，除了大部分杭州本地的朋友外，还包括宁波、台州以及沈阳的朋友。也许是因为长时间没有参加过线下讨论活动的原因，现在气氛非常热烈。活动进行过程中，需要主持人数次“厉声”制止方能结束讨论，一点也找不到江南才子细语轻声的感觉。各讨论小组的负责人也能很好地将本组讨论的观点进行总结和分享，嘉宾程立更是被数次请上台结合支付宝的经验和与会者朋友分享。也许像北京、上海这样的城市活动比较多，大家见多不怪，也不以为奇，可是像杭州这样的城市类似的活动却还很少，活动结束后，很多朋友询问什么时候再举行下一次。希望InfoQ中文站的QClub能够架起中高端技术人员之间的桥梁，以微薄之力在更多的城市开展更多的活动。

注：本次QClub的视频和PPT文件已经发布，欢迎大家浏览。本次活动特别感谢QClub杭州负责人冯大辉，支付宝首席架构师程立以及支付宝公司和华章图书的大力协助！

志愿参与InfoQ中文站内容建设，请邮件至editors@cn.infoq.com。也欢迎大家到InfoQ中文站用户讨论组参与我们的线上讨论。