概要
本次采访在伦敦QCon大会上录制，谷歌的架构师Gregor Hohpe与Stefan Tilkov就他在会话模式方面的新工作进行了交谈。基于他以前在企业整合模式方面的工作，Gregor认为会话模式在现实世界的互动中发挥了与其在自然世界类似的关键作用。
个人简介
Gregor Hohpe是谷歌公司的软件架构师。Gregor是异步消息和SOA领域公认的思想领导者。他是开创性著作《企业集成模式（Enterprise Integration Patterns）》的合著者。2005年，Joel Spolsky将Gregor的文章“星巴克不使用两阶段提交”入选其“最佳软件文章”。
我是Stefan Tilkov，正在参加2008年伦敦QCon会议。坐在我身旁的是Gregor Hohpe。欢迎你，Gregor！请介绍一下你的工作？
我是软件工程师。我写代码谋生，我还想指出，现在我依然在这样做。我从EAI开始做起，也经历过TIBCO和Vitria，从事过大量企业集成工作。有趣的是，刚刚会议的闭幕演讲者是Martin Fowler和Jim Webber，他们在EAI时代做了很多有趣的事情。基于这些，我做了许多意大利面条式的集成工作，将所有可以连接在一起的东西都相互连接起来，这可能是我最终得以通过《企业集成模式》而出名的原因。我得说，工作中我积累了很多有用的经验，我也尝试着记录下来，并以书籍的形式进行分享。
你当前的工作是什么，目前正在做什么？
我有点偏离了企业集成方向。我目前在谷歌工作，实际在内部培训组。我对分享知识、教书很感兴趣，所以我为我们的工程师创建内部技术的培训材料。遗憾的是，这些都是内部秘密，所以就不必询问了。
你写这本书已经有段时间了。它仍然有效么，一切改变了吗？
这问题不错，我跟几个正着手写书的人在会议上也交换了意见，我想最令人沮丧的事就是倾注所有努力写了一本书，而6个月后，书却过时了。很多书都有这种情况，对我来说，这是件令人沮丧的事。我们非常幸运：这本书在2003年出版，实际上经过了2年的努力。我们从2001年初开始一直写到2003年夏天，并在2003年底正式出版。
重要的是，我们把重点放在架构、设计原则和模式。我们希望它在相当长的一段时间内都是有用的。它基于异步消息这种相当基本的架构，这是其为什么成功的原因。
书店仍在出售该书，人们仍然在谈论异步消息，书中的例子代码在很大程度上仍然有效――我们有一个有趣的章节，关于“Web服务的未来”，因此，在年代上可能有点超前于其他书籍，但这对设计和架构原则是有益的。大家都知道，称这本书为“经典”可能太苛求了，我想它只是有一点点靠近吧。在本领域5年算是一个相当长的时间，而我相信这本书仍然会很有趣。
是否会有更新？
这是一个有趣的事情。我觉得书中的模式仍然是有效的;我们发现它们也可以运用于许多新的领域。当然，Web服务标准是重中之重――当我们写这本书才刚刚出现，此后很多人认为，在面向服务的架构中，面向消息的通信确实是一个核心属性，这正是我们在书中确信的事。虽然我们甚少谈及SOA（当时这个缩写还没有完全形成），但它们仍有相当的关联。即使缩略词生态系统有些演变。但我们仍乐见该模式跨越了一项相当新的技术。
当然，这并不是这一领域唯一有趣的模式。我们整理了大概700页东西，实在是太多了，但我们设法做成了。但实际上，当你考虑到这个领域和模式有些老旧，即将所有东西连接到一起，远远超过我们现在所做的事。我们正在缓慢但稳步地撰写第二卷，将有更多的会话模式，这些模式更单纯的关注于系统间来回往复的消息。就像是一个全新的模式种类，我希望能形成一本新书。
能否讲讲这些会话模式的思想？
我认为会话模式的一个好处――可能我有点偏见――是它们有很多较好的和现实生活的类比。现实生活很大程度基于异步通信。我们现在坐在这里面对面交谈，其实是一种非常典型的同步会话。我通常不这样做，因为这样我必须有百分之百的注意力。大多数情况下我会向你发送电子邮件、打电话给你、给你留个语音邮件。
我们之间的交流和普通的一样是十分异步的方式，也没有什么保证。我的电子邮件可能被你的垃圾邮件过滤器扔掉，或着你可能会删除它或是遗忘了，所以我们必须处理所有这类通信问题的挑战，很快地就有了会话进化的概念。轮询就是一种非常简单的会话：我要求你做某件事，然后我不断侦测，直到我得到答案，对吧，随着时间的推移将会出现消息交换。我可以要求你做某件事，我可能收到一个回应，或者得不到任何答案，我不会等待你告诉我何时能准备好结果，而是继续发送请求。
这可能有些低效，但是也有可能必须这么做。也许你没有我的电话号码，或者你不能给我打电话，或者你不想给我打电话，所以我继续呼叫。因此，描述这种会话的设计模式就是轮询、应答、达成协议，回调。想想这个出去吃午饭的例子，比方说：“嗨，你想出去吃午餐”，需要找个好地方，找个好时间。你可能有个助手来做这些事，例如向每个人询问最喜欢的食物，最想去的地方，是否有空等问题。当他们都回复后，就像魔术洗牌一样，确定是在星期四12:30在拐角处的中国餐馆进行午餐。
这是很明显的有状态（stateful）消息交换，这正是模式涉及到的，因为所有这些现实生活中的例子都可以在计算机系统的世界中找到一致的类比。我的意思是，这正是B2B的工作方式。比较真实生活与系统模式有很大的乐趣。我计划以现实生活的情况为这些模式进行命名。
书中你写了一个现实生活中的例子，即星巴克的例子。这种互动和协调，令我想起了你当时所描述的两阶段事务协议。事务是会话模式么？
很好的问题。我一直认为我理应可以终身免费在星巴克消费，因为我在“星巴克不使用两阶段提交”的文章中为它做了广告。这本书现在已被翻译成日文，在日本发行，我对此很高兴。这完全突显了以下事实：现实世界中很少有两个面对面(two faced)的提交，这并不像我们计算机科学家所设想的那样，这也并不意味着两阶段提交完全没用。当然，我们希望保持某种一致性，即确保当一个人付钱之后可以喝到咖啡，或者如果没喝到咖啡，他们可以拿回自己所付的钱。
无论如何，我们都试图做出公正的结果。但是如果在所有终端都开启事务，然后提交或者回滚的话，这将难以正常工作。非常有趣的是，我认为这完全归因于在大多数的系统中缺少分布式事务，这也是会话发展如此迅速的原因之一。如果所有事情都以类似于100％可预见的事务为基础，则采用大量会话将会简单得多。基本上我会说要做这件事，这里有钱，完成这件事，做完之后回来找我。这就是整个会话，谈起来不会有很多乐趣。
但在现实生活中它不会这样。它更像是你有存货，我想买的东西，你对我说“ooh”（很遗憾），其他人刚刚买了东西离开，我没有得到这个信息，或者该消息被推迟了，然后就出现了重试――我真的想要这东西，而且现在下了两个订单，这究竟意味着你真正想要的是两杯咖啡还是一杯咖啡呢？由于在现实生活中，系统中正在发生的事情具有很多不确定因素，很快可以看到会话的产生，它同样也出现在较高的层次和系统图中，你干脆说，“Gregor从Stefan处买了杯咖啡 ”――就像一行语句。
但是在现实中，这一行并不只是表示交易发生了，用钱换了咖啡。这里有很多来回的交互、错误的情况，等等。这也使得事情变得有趣起来。我认为非常重要的一点是，因为越是分布式的系统反而造成对你的保证更少了，对吧，你并未获得分布式的ACID事务。你必须自己做更多的处理，这通常意味着你具有某种形式的会话，例如重试、确认告知、取消、调整，补偿等。这些对我来说都是非常有趣的会话。
有趣的你使用了星巴克的例子：Jim Webber昨晚的报告整个采用了同样的例子。用来描述REST式的星巴克服务，这是一个很好的方法。在报告的开始，他提到了为描述会话还缺乏相关的支持手段。他认为WSDL在这点上并不真正提供帮助，它认为一个请求加上一个响应就是会话。在你涉及会话模式的工作中，你碰到服务支持中需要采用框架来描述会话的情况么，或者你认为以后我们只需要请求/响应模式么？
很好的问题。据我所知，还没有一个真正的好方法可以精确描述会话。存在几个候选的方法，而且对人们更偏向哪个还有激烈的辩论。我曾看到过有人，其实是在微软在某个设计评审中，大家都坐在一起，然后有人站起来，相互大声喊叫，然后带着他们描述会话的观点而离开。这是有关WS- CDL（choreography description language，编排描述语言）和BPEL （Business Process Execution Language，业务流程执行语言）两者的竞争。
虽然这两者都具有规范，但是BPEL可能是最流行的一个，在产业界吸引了越来越多的注意。CDL在思维上更加正确，是真正的编排语言，其目的是真正地描述会话。这两个有很大的思维鸿沟。Jim可能还提起了SSDL，SOAP服务描述语言。
现在有很多方法。对我来说最大的挑战就是，还没有一个明显的超级赢家。我要说的是，如果我说BPEL是明显的赢家――也许有些人要站起来离开，因为我说这是明显的赢家。但它对于会话来讲可能是最差的匹配，因为它实质上是一个业务流程的语言，而不是一个会话语言。但它在被采纳方面是明显的赢家，所以对我来说的挑战是：你可以从思维上正确的和最流行的两者之间进行选择，但是最终，哪果你要以此谋生的话，你可能需要选择最流行的。
对我来说，另一个巨大的挑战是――模式从哪里来――即使假定我们拥有的语法可以较好地描述会话规则。在设计会话时仍然具有很多问题，例如什么是好的、什么是不好的、如何确定你的会话具有鲁棒性。例如，如果可以重试的话，你是否允许无限次的重试？是否限制重试？取消操作如何做？――这是好事还是坏事？在设计会话时还有许多这样的问题，我认为很多都还没有合适的答案。而我希望能够提供更多的指导和建议。最终归结为两个问题：如何真正地描述解决方案，然后第二个问题是你如何拿出解决方案。两个问题也许应该颠倒以下，首先是设计问题，然后是描述问题。
是什么使得BPEL在描述业务或者会话上比任何其他编程语言更合适？这个语言带来了什么好的特性？
我们需要小心一点，以免太拘泥于细节，搞不好待会儿我就直接在白板上画出XML、BPEL等东西。当我想到会话的时候，我试图描述两个或者三个核心的属性。例如你想知道会话的参与者，更确切的说，参与者的角色、权限，可能有一个买方一个卖方，可能有会议发起者、会议协调者和会议的参与者，然后不同的个人或系统分别属于这些角色。有些人可能同时既是发起者也是协调者，这也是我说要有角色的目的。
通常情况，有一大把已定义的角色，有一大串的消息类型。消息具有一定的意义和一定的结构，这时WSDL和XSD能帮上一点忙。例如，买咖啡，也许消息里传达了我想要的什么的信息，星巴克的咖啡有17个可选字段，每个字段有2个额外的可选项。现在你应该对消息内容有些概念了，包括什么消息以什么顺序来流动。这确实是最困难的部分。
其他方面，如定义角色，我们只是列出一个名单；消息类型，我们使用一些模式，如WSDL/XSDish。这种方式是可行了。但是当问到会话的规则是什么时，就如之前Jim所指出的： WSDL表达输入/输出、输出/输入、只输入、只输出。运气很好，是吧。因此，这部分是如此之难，而采用BPEL的方法可以解决；如果我没理解错的话，你的问题是说BPEL比普通编程语言好很多。
我认为，这是对的，但BPEL作为一个业务描述语言它仍然有一定的局限性。它具有活动（activity）、并行执行和顺序执行、具有与实际业务引擎类似的相关机制。如果你将包括发送和接收消息的业务连接在一起，实际上间接地描述了会话的规则。设想一下，将流程连接在一起――大概比划一下――假设业务开始运行，你启动了两个并行的活动，每个活动都发送一条消息，实际上出现两条消息符合会话规则，但是我对两条消息进来的顺序毫不知情。相反，如果我启动一个活动，并且先发送一条消息，再发送第二条消息，其顺序是完全清楚的：消息A出现在消息B的前面。
所以你们可以想像，如果我有一个业务流程，还有这些发送和接收的活动，它们就已经间接地描述了会话的规则。这是良好的语言需要做到的一点，是吧，它具有所有结构，它具有分支、同步、很容易表示平行的活动，而这在一些编程语言中仍需要相当多的手动编码工作、同步和线程等等，你无需处理任何细节。假设你定义了一个WEB服务，实际工作得很好，是吧，你说这是我的服务，这是我的服务所执行的流程，这是消息输入和输出，你需要更好地遵守这一流程，所以我将确定什么顺序发生什么事情的规则。
如果有五个操作，假定这个行动将最早发生，然后这两个行动之一将随后发生，然后可能是剩下的两个行动最后发生，顺序不定。这正是你想要的词汇。其限制在于，它具有一点点中心服务的特点。因此，假定我们的会话具有许多同级的参与者，没有这样的中心服务，不存在一个人拥有全部行动的情况，这就像在没有事务控制器的情况下达成某种一致。
这里可能出现选择主事件的例子。你有一个事件池，你知道它们之中有一个是主事件，但是在这些查找主事件的过程背后有一个中央协调者。BPEL在这里变得有些困难。因为这里不再存在一个可以通过其内部过程来定义所有消息流的实体。这是因为所有参与者相互之间直接传递消息，它们都了解其去向的相关情况，这里没有中央协调者。
这正是两部分立场的人争论的话题。使用BEPL的人――认为大多数情况下具有一个中央协调者，而且工作得相当不错，非常实用。而使用编排（choreography）描述语言的人――常说小心点，你们做了一个非常强的假设，实际上当我们查看整个会话时，可能有20个参与者，他们都需要发送和接收消息，这时我们不能假定有人能够控制所有事情。这正是人们争辩，然后站起来，并离开的那种争论。我认为BEPL是非常有用的，可能更接近采用C#和 Java写程序的方式，但它是从一种特定的角度看问题的。
你是否认为BPEL更多的是内部使用，而WS-CDL更多的是架构B2B方案？这是否是一个有益的设想？假设当你在企业内部时，存在一个中央协调者，而在每次跨过公司界限时就依靠相互协商的方式？
我不知道如何确定公司内部和跨公司。我认为这有关于会话的实质，即会话是否有更多的概念，例如有人可以对过程做出决定，而其他人则遵守。在这种情况下，BPEL可以工作得很好，也适用于跨企业的环境。如果我是供应商，我可能有一个抽象的BPEL业务，比如： “嘿，各位，这是我的业务，如果谁要跟我联络，请使用这个模板，这是我们会话的规则”。因此，我认为这既能在工作在内部环境，也能工作在外部环境。进一步的问题在于：能否把握平衡？或者说是否存在一个人在内部设立了所有事情的规则？
请不要太过深究。这里有一个交易情形，我是供应商，有一个交易业务，它描述了会话的规则。基本上，当你请求报价时，我给你一份报价，当你想下定单时，你必须提供我给你的报价单的号码。然后我对下的订单进行回应，其中包括了你期待的一些普通规则。我将这些放在一个BPEL业务中，但是在交易中，我实际上将 BPEL业务放在两个独立部分中，一个负责处理会话，另一个负责实际执行该业务。
而被搞乱的流程像这样。你请求报价，这是一个标准的业务。当你正在取回报价时，然而内部业务正在通过一些部门，其中有个人刚喝了三罐啤酒，虚构了一些奇怪的数字，从而产生了奇怪的结果。通常在公共业务和私有业务之间有严格的分割，因此这些过程对你来说都是不可知的。对B2B来说，假设有两个业务可以解决问题。一个业务单纯处理会话，另一个单纯处理我自己的交易方式。例如我可以在另一家供货商的网站上获得报价单，是吧，这就是我的交易流程，这并不属于跟你共享的那个会话。
你在QCon会议上的子讨论会（track）的标题有一个“云”字。请解释一下，人们对“云计算”有何看法？
这有点讽刺意味。在伦敦这里有一个“云讨论会”，这是本年度QCon的一个新讨论会，称作“云是新的中间件平台”。我对名字中的云字样有点担心――我们常说SOA对三个人来说意味着三个不同事物，云对三个人来说可能意味着四个不同的事物。云的意义可能更加模糊，但我认为这是个有趣的主题。让我们稍微回到你前面提到有关会话的问题。我出身于企业集成，这时候只需要关注一个企业本身，或者在企业边缘加上一点B2B的内容；而今天我们看到的是网络…SUN公司以前的口号“网络就是计算机”在某种程度上变成了现实。
现在人们建立的集成解决方案可以直接运行在互联网上，而几年前调用一些WEB服务就被认为是非常迷人的。现在的服务一般连接上其他的服务，可能运行在云中的某处。可能运行在Amazon的服务中，或者Yahoo! Pipes集成环境中。简单地说，可以归结为一点，如果你的应用没有URL，你就不够时髦了。无论你做什么，都需要实时发布出来，有一个发布（feed）接口，有一个URL。可以被定位，可以被共享。这样其他人就可以在你的基础上构造更多的解决方案。对我来说，这在某种程度上就是集成的涅磐。
最终，所有人都可以创造出的东西，这些东西超越了标准协议，可以在世界范围内让别人进行连接，并基于它们建立更高层的应用。对我来说，这真是太棒了。这就是本次会议为什么会有这么一个讨论会的原因。我认为这非常吸引人，但是它仍然需要解决大量在企业应用集成（EAI）中也同样出现的问题。这些问题包括数据格式不匹配、转换格式不匹配、以及其它所有存在的类似问题。既存在一些旧问题，又存在大量新问题。对我来说，设立这个讨论会的确很有趣。
现有演讲者的演讲中有多少共同点？你们是否采用同样的模式？你是否看到一些共同性的出现，或者是多种不同的方式仍然在竞争？
我们在track中试图将范围扩大得更宽。Amazon的Jeff仅仅讲到了Amazon的核心服务，例如Storage、SimpleDB、计算云、队列服务等等，就像实际的技术基础设施服务。Salesforce的Dave的内容更多的是交易软件，如服务系统。Frank谈到了GData，这是基于 Atom Publishing的一个层API。后来Jonathan谈到了Yahoo!Pipes，并做了演示。
这些都是完全不同的东西。我们有意这样安排，我认为它们在一起将工作得很好。我可以构建一个mashup，连接上Yahoo!Pipes，从 Salesforce和GData取回一些东西，最终的一部分可以在Amazon上运行，或者将结果数据存到SimpleDB中――可以很容易想象如何将这些集成在一起。
你的问题是说这些之间有什么共同点，我认为它们各自占据了各自的位置，它们也配合得不错。但是它们也都有自己的设计哲学，即它们是不同的：有些是底层服务，而有些是高层服务，如Salesforce提供的自动化操作。
对我来说，连接它们更像是在搭积木。都具有明确的共同主题，包括可扩展性、安全性等等。每个人几乎都必须谈论这些。它们有一些不同。在这里我试图指出一点，即事务怎么办？事务重要么？Frank可能会说“不”，其他人可能会马上举起手来，Jonathan会说“我认为不是，但是我还没准备好举手”，而 Salesforce和Amazon的人认为某种形式的事务的确非常有用。这些广泛的观点对我来说非常有趣。
根据我们刚刚谈到有关事务的话题，是否难以扩展？如果需要在全球范围进行工作，是否不能采用事务？
我的观点是在那样大范围内不能使用事务。你可以使用事务，但是与系统大小相比，其范围小得多。当我们了解这一点后，显然在集成模式中，消息也有相同的问题：当你发送消息时，将消息放到队列中也是事务性的，将其从队列中拿出来也是事务性的。如果你获取消息时失败了，你进行回滚，消息返回到队列中，这样你可以保证只有一个消费者最终读到这条消息。你也可以制作一个组件来读取消息并发送一个回应消息，如果这个操作非常迅速，这样在运行中间你就可以派生新的事务。
读取消息、计算应答并发送消息可以作为一个整体：可以集合为一个事务，即读取消息者拥有其单独的事务。这里存在事务，但是事务并不是全部。当你考虑整个交互过程，可能采用会话模式，比如将请求、响应当作一个事务更好。因为这里往往有至少三个事务：发送最初的请求是第一个事务，服务提供者读取消息、进行处理、发送响应是第二个事务，发送者读取响应是第三个事务。
这使得事情非常有趣，即采用事务比较有保障，但是该保障比系统总体状况少得多。它保证本地的事情，这非常有用。但是它不能保证我发送的消息能够正常接收，其响应消息能够正常发送，以及两者的一致性。你不能保证这些，我认为你不是不想保证，只不过这些保证是系统吞吐量的最大杀手。我认为完成这些保证有点幻想。总会出现某种情况，系统无法正常工作，从而使得整个交互非常复杂，而且可能导致性能很差。
我的经验和哲学就是采用一个简单的解决方案并深入了解其局限，不要采用那些不停地层层累加的方式来添加恢复机制。我看到有些人这样做，最后这些复杂的系统形成了一些非常有害的特点，即没有人可以预测――事情之间产生了死锁情况，所有事情完全崩溃――而在简单的解决方案中，你知道系统能做的事和不能做的事。我赞同这点，而且我也是这样做的。不要做像构建巴别塔那样的事，因为它会被其本身的重量压垮。
你是说我们必须学会在缺点、错误、矛盾中生存，并试图处理它们？
我认为是这样的。这听起来有些可怕。计算机是0和1的世界，要么是1要么是0，我么喜欢精确。所以当我们说“学会在不确定中生存”时，听起来有些吓人…状态是个很好的例子：一些可能的事情可以突然爆发出来。另一方面我总是告诉人们不要恐慌，因为现实生活就像这样，世界的功能也是这样，我们处理事情也是这样，我们都有一样的不确定性。所以我认为有一些好消息、也有一些坏消息。这的确有点吓人，但是好消息是，在某种程度上，这些系统实际上更像现实生活系统，它们处理的是同样的问题，它们处理同样的因素，你不能假定一些不存在的事情。星巴克没有两阶段提交，如果你假定它有，则事情会变得比直接处理更糟。
我还有很多事例。我有很多朋友在银行工作。上一次在科罗拉多州，我同eBay的Dan Pritchett聊天，他说交易就像是真实的现金流动。事务派的观点是：在银行账户中，你必须保证这100美元和那100美元的完整，它们原子地从这里流向那里，银行保证了这一点。但是你可能会惊讶这之间会发生什么，这里不仅仅只有两个事务，两条记录。这里有很多事情发生。例如――我不说出银行名字，但我确信所有银行有一样――我朋友告诉我有些银行拥有某些神奇帐户，通过这些神奇的帐号，可以随意地存取资金。我也希望我的名字也是这种账户。这些账户用来处理临时性的事情，即平衡发生的特殊事情，并防止账户向任何方向流失。这些特殊事情的确存在。有时候特殊事情发生了，然后就要采取相应的对策。例如他们弄丢了你的50元，而且你是个好客户，他们将在账户上给你加上50元，这样你就不会看到他们的错误了。
有很多这样发生在幕后的事情。我不是想鼓励大家：“随便做吧，钱不重要，只要做了就好”。假如你做了一个系统可以完成某个功能，但是你必须非常诚实，即你的系统有一定的局限性，你可以编造出系统工作得不那么好的场景，而且你必须解决这个问题。这个方法就是在系统的层次上再加上一个层次，然后假装着你已经构建了一种可以预测的方法，而实际上，这种方法是无法工作的。
在谷歌，我们有管理机器方面的故事。我们最大的哲学不是“如果出错”，而是“何时出错”。我们有大量的机器，所以我们面临着机器经常出错。例如数据丢失、磁盘损坏、CPU过热、机柜起火等等。所有这些都会发生，所以我们必须准备处理这些问题。而不是说，如果我们安装了第二块电源或者其它什么，我们就可以避免事故发生。事故必然会发生。某种程度上说，这种架构恰恰就是现实生活的样子，你必须处理它。总的来说，用钱可以修复许多问题。在面对面的交易中，你可以接受该损失，并给客户返回一些钱，你可以有很多种非系统结构的方法来处理这个问题。我们生活在真实世界里，我回答了这么多，这的确是个有趣的话题。
可以合理地认为，至少可以指望人们是诚实的。我认为云计算的带来的问题是你不知道服务是否活得与你期望的时间一样，是否有足够多的服务，是否能达到一定的性能。
非常有趣的话题。实际上存在两种保证，一种是协议和技术的固有的特性，另外一种是服务在两年内将运行良好，他们何时开始收费，是否提高收费。越透明越好，保证的人越多越好。许多服务是免费的。我知道Google就有很多免费服务。问题可能出在你提供何种保证，这个答案简单说来，一般就是我们不提供保证。但是非常非常非常有可能的是，你知道它们将一直提供服务――这对那些使用它的人来说，在一定限制内，往往是标准答案。
因此，快速发展的小企业和初创企业的商业模式正在迅速演变，他们可能需要处理大量其它的不确定因素，而不是处理服务是否在两年内有效的这类问题。这对他们来说不算个大问题。对于已经建立了商业的企业来说，他们可能试图将其某个核心功能移植到某类服务上去，这有很大的不同。他们肯定会吸引更多东西，例如和 Amazon签订合同，你付钱，得到保证，他们承诺服务的可用性，如果服务不可用，你将会得到退款。
我的意思是没有人能给完全的承诺。你也知道这是用多个9来度量的，这里从来都不是用1和0来衡量的。这里从来没有100分，总是有某些不确定因素。所以如果这些人对不确定因素比较诚实，则事情比较好。如果他们处在意外情况，他们做出补偿，大部分时间只是赔钱，这也是最可供补偿的资源。如果我的系统坏了，我给你退钱，这通常是最简便的解决办法。对Google的网站来说――我们提供一些企业级的服务，你可以得到技术支持，例如电子邮件，文字处理。你可以得到企业级服务和一些保证，但是你得付钱。
对于其它所有免费东西来说，主要是一个信任的问题。你知道这是Google，服务通常不会坏掉，一般可以运行一段时间，但是没有人以书面形式写下这一点。这是另一种做生意的方式。对我来说有时候也需要适应。我举例演示一下，其中包括一些云计算的工具。演示中间有一个服务完全失效了，情况非常糟。当时我对任何事情都无能为力，没有人给我任何保证，也没有任何电话支持，我只能希望在接下来的几个小时里，服务会恢复正常。幸亏当时是在一个小会议上。我是一个小例子，但是你可以看到这种事情的确会发生。
如果我运行一个24×7小时运行、永不停机的服务，我希望经常部署软件，尤其是用非破坏的方式。这不正是今天云计算所提供的特性么？
是的，对于软件更新的基本问题来说，热更新无需关闭系统。我认为有一些解决方法。在云计算中最流行的方法是――提供将请求路由到不同的服务实例的能力，这是一个较好的抽象方法。例如URI，你不知道到URI背后到底是什么，人们一般有多个数据中心，请求可以被路由到不同的地方去。很多请求就可以依次直接得到更新的服务。
基本上所有人都采用这种方式，原因是：人们软件发布得非常频繁，特别是与Web 2.0有关时，软件的发布周期消失了。新东西随时会出现，同时你也许将发布你的新软件，也许将回收某些不满足要求的软件。大多数人主要做两件事：在某些机器上进行生产，并控制那些消息可以流向新机器。Canary可能是比较合适的软件，人们将1％的流量发送到新服务上，并观察系统中发生的事件，这样就可以控制系统的运行。然后他们缓慢地加快系统的转换。这样你必须处理的事情就是不同的客户使用了不同版本的软件。
这事儿很有趣，即使在Google，我们有时候收到类似的问题，如“哦，我的朋友在Gmail里看到了这样的输入框”，而我却完全不知情。这样也是个好机会，毕竟有人发现了这个新的试验东西。有时候对有些新的特性，有人看到了，有些人又没看到。关键问题在于需要一种版本的兼容性。这样你就可以调和这个矛盾，即一些人谈论新版本，而另一些人谈论其他的版本。
然后，你当然需要确定你是否需要版本之间的关联关系。这样一旦他们谈论新版本时，可以确保总是同一个新版本。当你给出你的会话cookie或其他东西时，处在试验软件中的人至少在本会话中也在同一个试验环境中。否则，将会出现在同一会话中涉及到两个版本软件切换的问题。据我所知，这些是常见的技术，你可能有点多疑，或者你碰到了不同的场景。
既然现成的技术可以解决这一问题，你为什么要采取新的做法，你为什么不直接购买能够解决你问题的技术？
我并不主张从零开始建立所有的一切。我只是说明这是一般性的机制，由于这是一种非常常见的问题，你可以买一些有用的解决方案。要小心的一点是，你可以买到的方案能够提供一定的机制，但你仍然有可能在自己的层次里带来问题。因此，既有好处，也有坏处。所以你仍然需要有变化的能力。因为你发布的新软件即使经过所有的测试，仍然可能存在问题。所以如果你购买解决方案，你仍然需要具有可以重新路由和回送某些会话的能力。
就我们而言，我们的确自己构建了很多东西，这只是因为我们拥有非常专有的软件栈。实际上这是一种折中，即是购买还是建造的决定。在大多数情况下，购买可能是个好主意，特别是可靠性非常高的东西。通常随着时间的推移，你会发现你自己所做的东西不如你预想的可靠，也不如直接购买的。购买的东西一般已经经过其它人辛苦的测试过程。这是一个好处，但是你必须在能够自我控制上进行权衡。例如，如果你刚开始建立自己的软件栈，你知道事情到底将如何发展，你可以调整所有的事情。这是一个有关购买还是建造的讨论。最终这是你想要的机制，你可以逐渐地控制机器和用户的流量。
刘涛，博士，毕业于西安交通大学，主要研究网络体系，现在主要从事多核环境下高性能算法的研究与开发工作。曾经进行过多个企业级软件的设计与开发工作。关心开源软件的发展动态，乐于使用开源软件。对前沿的系统软件与技术有浓厚兴趣。
以上文章由武汉网站建设公司整理发布。http://www.tuoruisi.com转发请注明出处。