从解决规模问题到集成AI，谈谈云服务的发展和挑战

架构师 架构 叶航军 云服务 ArchSummit

北半球秋冬已至，但激烈的云计算市场还没有停止竞争，云服务也不断地被创业组织和传统企业所接受。在这供需两端力量仍在不停地扩大时，云服务内部架构问题在技术战场上却不断涌现：如何做一个大规模分布式数据的云系统？如何避免云服务架构设计上的瓶颈和不足？

2016年12月2日-3日，ArchSummit全球架构师峰会将在北京举行。本届大会组委会策划了“云服务架构探索”专题，并邀请了小米云技术团队总监叶航军老师担任该专题出品人，我们借此机会采访了叶航军老师，他为我们分享了有关云服务的实践经验和对云服务趋势发展的看法，希望可以为大家带来启发，如果读者对实践云服务有疑问，也欢迎报名参加ArchSummit北京站，与现场的云服务专家一同交流讨论。

受访嘉宾介绍：

叶航军，超过10年的互联网从业经验，先后就职于IBM、Google、腾讯、小米。现任小米云技术团队负责人，负责分布式存储与计算、基础框架及深度学习基础平台的研发，支持小米公司内部和小米生态链公司的云端需求。2003年从清华大学计算机系获得博士学位，研究领域为计算机视觉与图像检索；2006年加入Google北京，任高级软件工程师，参与和领导了多个搜索体验相关的项目；2009年加入Google美国，作为核心成员在Google总部参加下一代搜索引擎“咖啡因”的开发；2010年加入腾讯，任腾讯搜索Crawl团队技术总监，领导开发了腾讯搜索的分布式文件系统和新一代Crawl系统。个人主要关注领域包括搜索引擎架构、分布式系统、云计算及人工智能。

InfoQ：能否分享2009年加入Google美国作为核心成员在Google总部参与开发搜索引擎“咖啡因”这段经历？作为技术人而言您收获到哪些经验感悟？

叶航军：我是2009年从Google北京内部调动到Google美国去参加“咖啡因”是这个项目的。当时Google有“Reverse Ambassador”的计划，从Google海外的研发中心抽调一些资深工程师到总部参加核心项目的开发。叫“Reverse Ambassador”这个名字是因为更早的时候Google有“Ambassador”计划，从总部抽调一些资深工程师到海外帮助Google当地研发中心建设，而这个计划是反方向的，所以叫“Reverse Ambassador”。

“咖啡因”是当时Google研发的新一代搜索引擎系统。之前Google搜索的索引更新是个“批处理”系统，即使只有一小部分网页发生变化，也要重建整个索引。所以每次索引更新都会有大量的重复计算，这不仅浪费资源，也影响索引的更新速度并增大延迟，最终影响搜索结果的新鲜度（Freshness）。

“咖啡因”就是把索引更新变成了一个“增量处理”的系统，只根据变化的网页进行必要的索引重建工作。这个变化听起来比较简单，但由于搜索引擎要处理海量的数据，这个挑战是非常大的，同时也需要对基础架构和上下游的依赖做根本性的改变。Google发表了一篇文章描述了“咖啡因”底层依赖的一个处理系统——Percolator。

我当时参与的是网页抓取的调度系统。网页抓取是索引更新的上游系统，索引更新主要也是被网页抓取的结果触发的。我当时的工作是为了让网页抓取也能变成“增量处理”，最终提高搜索结果的新鲜度。

Google在解决技术基础问题的决心和投入是非常大的，经常会在当前系统运行的还可以的时候就开始投入新一代系统的研发，也经常有些天马行空的项目出来。这些被选择要解决的基础问题也比较接地气，一旦成功，会给产品带来比较大的提高，这个还是很值得学习的。

InfoQ：能否谈谈搜索技术与云技术之间的关系？两者之间在知识体系上有哪些交叉和区别？

叶航军：我个人的理解，最初云技术很大程度上要解决的是“规模”的问题，先是“规模很大”，后来是规模上的“弹性”，而搜索引擎是目前为止规模最大的应用。所以我们可以看到：目前云技术里的很多技术，尤其是和分布式存储和计算相关的，Google做了不少开创性的工作，包括最早的GFS，BigTable，MapReduce，还有后来的Spanner。这不是因为Google一开始就把“云”当做它的商业模式，而是因为搜索引擎要处理的问题规模实在太大了，所以需要这样的技术。

我自己也是因为在Google搜索团队时用到了很多内部的技术，自己也对“规模”问题很感兴趣，所以后来有机会就转到了云技术领域。这两个领域有很多问题是相通的，比如大规模系统下故障的必然性和不可预测性。但它们本身处在技术的不同层次，云技术要解决的是更通用的问题，搜索是它的一个典型应用。总的来说有其中一个领域的经验，再去学习另外一个领域要容易不少。

InfoQ：结合您在IBM的工作经历，能否谈谈传统企业云化意味着要做什么，为什么传统企业云化那么难？现在有什么解决方案？

叶航军：我直接了解的传统企业的云化案例并不多，不过也能想象到会遇到哪些困难。我觉得最大的困难首先是观念上的，其实是个信任和信心的问题。人对自己不了解的东西是天生怀疑的，所以对这种新生事物，尤其需要把核心的数据和服务托管到第三方提供的基础设施甚至共享机房里，总会有很多疑虑，如果在实施过程中遇到一些困难就更容易动摇了。对有互联网从业背景的人来说这可能不是问题，因为已经对这个方式有很多了解，我周围创业的朋友基本都是直接用云化的架构来搭建服务。

另外一个困难我觉得是传统企业如何在架构云化的同时保证现有服务的运营质量。变化总是有风险的，基础架构的变化风险更大。对于新创企业，他们并没有什么存量业务，因此这个问题倒不大，传统企业就不一样了。

我个人的建议是如果有可能，传统企业可以先从新业务开始采用云化的架构，慢慢熟悉这个新的方式，积累运营经验和信心，最后再改造存量业务的服务架构。如果一开始就全面云化，一旦中途出现困难，影响了现有的服务，就容易透支完信心而没法再推进下去。

InfoQ：那什么时候是企业云化的时机？

叶航军：企业迁移到云的时机主要还是需求驱动的。如果是新创企业，尽量一开始就用云服务，如果是已经有存量业务的企业，主要要看这个投入产出是否划算，自己是否有足够的技术积累。具体举个例子，有爆炸式增长可能性的业务，就会有“弹性”的需求，比如网游，这种业务就很适合迁移到云。

前面的话题已经讨论过传统企业云化的问题，道理应该是相通的。如果有可能，先从新业务开始，最后再改造存量业务。

InfoQ：什么情况下企业需要迁移到新的云服务厂商？迁移过程中如何尽量平滑和减少损失？

叶航军：企业选择云服务厂商时可能会主要考虑几个维度：商务、能力和成本。

• 商务上主要是技术之外的考虑，比如是否有潜在的利益冲突，厂商是否把云服务当做长期的战略目标等；

• 能力包括功能、性能、完备性、成熟度、可靠性、容量、地域分布这些；

• 成本就不多说了，不同的企业有不同的需求。

如果当前的云服务厂商在某个维度出现了明显的问题，可能就要考虑迁移到新的云服务厂商了。另外一个情况是云服务厂商也是供应商，有时候必须要增加新的厂商来平衡和供应商的关系，降低风险。

云服务厂商的迁移是个比较有挑战的事情，尤其是持久化数据（存储服务）的迁移。迁移的过程不能影响线上服务的质量，需要做好充足的准备、测试和各种意外情况的应对甚至回滚的计划。

如果是新增云服务厂商的同时也保留原有厂商，那尽可能只把增量数据放到新厂商，避免不必要的数据迁移。如果一定要迁移存量数据，最好先做数据迁移，后做服务的迁移，这样对业务的影响可能会小一些。

数据迁移过程中一般会有双写、验证、上线几个重要阶段，过程比较复杂漫长，也容易出错。所以整个过程中最好能对业务无感，比如提供接口兼容的服务，或者在中间搭建gateway服务，在这个服务上控制整个迁移的过程和进度。一是可以尽量减少对业务的影响，让迁移过程平滑，另外少一些环节也可以减少出错的可能性。

InfoQ：在您看来，对于即将云化的企业而言如何判断选择公有云、私有云还是混合云等技术选型？对于云服务提供商而言，您如何看待国内外目前的IaaS、PaaS、SaaS等市场？

叶航军：对于IT规模不太大的企业，如果没有特殊原因，公有云应该是首选，如果有特殊原因应该主要是安全或者合规等方面。对于一般的企业，IT本身不是它的业务，而是达成它业务目标的工具和手段，那么这些企业应该专注于自己所擅长的业务，而把工具尽可能交给专业的企业来做。公有云能把这种高效的社会分工模式进行得更彻底，企业基本上只需要保留和业务强相关的技术团队，而不需要专职的团队去解决太通用的问题。

对于IT规模比较大的企业，这个问题可能会更复杂。除了安全和合规之外，还要考虑成本、可控性、灵活性甚至商业战略合作等问题，这个应该没有统一的判断标准。

市场方面，目前IaaS还是主流。虽然大家都觉得PaaS可能是将来的方向，但目前看它还不够成熟，限制还是太多，服务质量的可预测性也不够。Google一开始也想通过PaaS切入公有云市场，和AWS差异化，但几年下来市场并不太买账，最近也开始在IaaS上发力。最近兴起的CaaS想弥补PaaS的这个问题，是个比较有意思的尝试。

SaaS相对特殊一些。我个人的理解，它本质上是一个个云化的应用，而不是解决通用问题的，比如团队协作、在线文档这些。所以SaaS虽然抽象层次更高，但并没有遇到PaaS的那些挑战，反倒市场的接受度还比较高。

InfoQ：云服务如何应对数据爆炸式增长？能否结合经历谈谈从软件和硬件两个方面能做哪些优化？

叶航军：规模是云技术要解决的核心问题，所以这也是云服务最大的挑战之一。我个人的体会，目标和规划是第一位的。云服务本来就是要让业务无感的，而基础架构的演化周期比较长，所以一定要未雨绸缪。如果规划到位，即使数据出现爆炸式增长也是计划内的事情，可以化解。

不过总会有突发事件发生，导致业务规模超出基础架构的服务能力，这时候最好能做到服务降级，先保证产品的核心体验是正常的。这个前提也是事先要有服务降级的设计和预案。

从技术层面看，在云服务的架构设计和实现上，需要把对规模和故障的考虑贯穿始终，这个比较常识，就不再细说。我的另一个体会，可能也是大家容易忽略的，就是对服务的监控和追踪能力要到位。

比较多的时候，数据或者业务规模出现爆炸式增长，超出系统的容量，大家只是看到服务出问题，并不容易知道到底是哪个环节的容量不够了。如果对服务的监控和追踪能力到位，找到问题就会很快。

达成这个目标不是靠一个外围的监控系统就能搞定的，也是要贯穿在云服务的设计和实现过程中。如果云服务的内部状态暴露不够，外围的监控系统也没办法定位问题。

InfoQ：如何减少大规模系统宕机，在保护用户数据上有什么可以做？如何保持在各云平台上的数据一致性？

叶航军：对云服务的质量评估有多个维度，其中一个比较重要的是可用性。外面看到的公有云服务商的重大故障主要是可用性故障，这也是云服务需要重点优化的一部分。云服务本身的设计都考虑了对故障的处理，所以偶发的故障一般不会引起系统大规模宕机。

我了解的大规模故障主要原因是误操作、网络设备故障和突发流量这几方面原因造成的。如何优化网络设备故障和突发流量引起的故障在上面的话题已经讨论过了，这两种属于天灾，主要靠监控和预案。

误操作是人为失误，人其实比机器不可靠得多。要想优化，除了尽量依靠自动化工具，减少人的现场决策之外，流程和辅助工具上也可以帮助减少很多错误。

多平台的数据一致性，做到强一致应该比较困难，成本和延迟一般都会比较高，因此必要性也就不太大了。如果技术上充分利用消息队列来做增量同步，应该可以实现最终一致。

InfoQ：谷歌将旗下云服务品牌统一为Google Cloud，并集成了AI功能，您觉得云服务集成AI对技术团队而言需要具备哪些能力，如何做到？集成后能产生怎样的效果？

叶航军：我个人的判断，通用的AI能力集成到云服务里是一个趋势。因为云服务本来就要解决大规模的数据处理问题，而AI除了算法和数据这两个挑战之外，另外一个挑战就是处理能力。这几年深度学习的突破性进展也和GPU、集群管理等技术引起的处理能力提高有直接关系。所以通用的AI能力可以认为是云服务的一个自然延伸。

目前Google在它的云服务里推出了一系列的AI服务，既包括Speech、Vision这种抽象层次比较高的能力，也包括Cloud Machine Learning这种更通用的AI能力，这应该是云服务厂商里在AI服务上走得比较快的。

云服务里集成AI服务确实需要相当的技术积累。比如如果要推出类似Google Cloud Machine Learning的服务，至少需要深度学习框架和GPU集群调度方面的技术。不过另一方面，现在开源的技术非常多，有些成熟度已经比较高了，其实也降低了云服务厂商集成AI服务的难度和门槛。​

InfoQ：感谢叶航军老师接受我们的采访，期待ArchSummit全球架构师峰会上您策划的云服务架构探索专题。