在（CCTC 2016，）上，百度开放云首席架构师徐串发表了题为《》的主题演讲，并接受CSDN记者专访，深入分享了他对架构及设计的认识，对架构师工作和技能的理解，以及百度开放云架构满足大数据和人工智能等不同应用需求的实践经验。

徐串表示，云计算环境下的架构，除了高吞吐、可扩展性、稳定性的需求，灵活性的实现也很重要。架构师的工作就是在各种矛盾之间坚持或妥协，如高吞吐和低延迟的矛盾，优雅架构和紧迫需求的矛盾。保证业务的需求，是设计架构的一个基本原则，要成为优秀的架构师，就要学会理解业务，和一线产品经理沟通，找出最核心的诉求来解决。另一方面，架构师除了以宽广的技术视野跟进最新的技术，也必须深入到到底层了解程序员的工作和痛苦，才能做出让程序员满意的取舍。

架构设计：矛盾下的坚持与妥协

自2008年加入百度，徐串先后做网页搜索底层的分布式存储，后来的分布式计算、Hadoop相关的领域，和整体的底层大规模集群管理系统工作，在底层的分布式系统上摸爬滚打将近6年，到了2014年百度开始决定投入开放云产品，他开始涉足面向公有云的分布式系统的设计和研发。

最开始做分布式架构的时候，徐串通常考虑两个因素：

1. 高吞吐。一定要把大量的数据存储和处理起来 ，用最大的吞吐量来解决。
2. 可扩展性。百度的数据增长非常迅猛，几乎每一年都会翻倍增长，要求系统有最大程度的可扩展性。

开始做云产品以后，徐串更关注的，是怎么使架构在稳定的前提下保证灵活性，因为需求千变万化，需要丰富的功能组件更好地支撑快速的变化。

但也有不变的东西，就是一个取舍。架构师的工作，基本上就是不停地在各种各样的矛盾中正确地取舍，比如做分布系统时高吞吐和低延迟是一个矛盾，很难在高吞吐的时候做到实时响应，必须取舍到底业务更想要什么；做公有云的时候，实现架构设计的优雅，与特别紧迫的需求，也是一个矛盾，怎么样控制节奏，在某些时候做一些妥协，某些时候要坚持，在保证架构整体干净的情况下能更好地适应业务的发展。

关于坚持和妥协的决策，徐串分享了他的核心原则：首先要保证业务需求要被实现。

架构师很多时候会抱怨说：“我们的客户需求太古怪，或者我们的产品经理经常迫使我们做一些很肮脏的事情”。但是徐串的经验认为，很多时候客户的需求都是可以改变的，关键是架构师一定要找出那些最基本的需求是什么——客户通常会讲很多东西，但其中只有一两点是他最核心的诉求，其他东西都是附加的，满足他的核心诉求其实并不需要太多东西——这个核心在于做底层架构的人不能脱离开业务，必须到第一线去和产品经理、客户真正地商量，发现他的核心需求，从而在满足核心需求的同时保持架构的优雅。

百度实践：开源、容器、大数据和人工智能的影响

作为内部技术的开放产品，百度开放云和百度私有云架构一致，是一个复杂的系统。百度私有云最底层是IDC系统，提供主要的硬件基础设施，在上面有一层完整的集群操作系统，用来管理所有的机器和提供整体的资源调度，在这上面还有分布式系统，包括各种各样的分布式存储、分布式计算，还有数据处理层，包括能够管理大数据的数据仓库、数据接口、BI等，再上面是有一层PaaS，为内部的服务提供中间件各种服务，再这之上是百度自己的应用。徐串表示，在每个业务、每个产品都会选择一套自己适用的技术栈，但是最底层都包含这个框架。当然，百度并不是一开始就有这么多东西的，总体来说，经历了三次比较大的改造。

1. 2008年的时候，百度在IDC之上中间只有很薄的一层，上面就直接是百度的应用。在这个情况下，百度发现自己的业务在飞速增长，数据也在飞速的增长，没有大数据系统是不能支撑需求的，所以在上面发明了分布式存储系统（包括分布式文件系统、分布式表格系统、分布式对象存储）和分布式计算系统（包括高吞吐离线计算平台、大规模机器学习平台、实时流式计算平台）。

2. 虽然有了分布式存储和分布式计算系统，整个公司的数据处理还是显得杂乱无章，每个产品线基本上都有自己的构想，这对数据的管理以及业务之间的交互、打通形成很大的障碍，驱动百度做一层完整的数据处理层，把整个百度数据统一管理起来，提供一个规范，很方便地管理处理各种数据。

3. 两次大迭代之后，百度在IDC的使用中发现，因为数据量在飞速增长，如果没有一套系统能够把资源充分地利用起来进行调度，浪费是很严重的，所以研发了集群操作系统进行资源调度。

4. 容器与微服务架构

   容器技术目前在私有云领域的应用极其广泛，徐串表示，百度很早就开始做容器，现在所有的应用都是放在容器里面。2012年，容器技术还没有那么像现在这样的繁荣，只有最基本的内核技术CGroup，技术还没有成熟，百度做了很多的工作，现在形成了自己的一套技术，而不是采用现在流行的Docker这样的成熟的容器解决方案；容器管理技术，因为发展其实比较早，也是自己研发的，但是百度会关注Kubernetes、Apache Mesos等业界的最新方向，希望找到一些先进的思想可以借鉴，引入到百度容器体系里面（百度开放云目前还没有完整开放容器技术，只是开放云底层基于百度自己的容器技术运作，包括云主机的整个开放底层都是构建在百度容器技术之上，未来在成熟的时候百度也会把容器作为一个服务开放出来）。

   而对于目前很热的微服务架构，徐串表示，微服务很难定义，百度的确有大量的底层分布式服务，由于业务太复杂，从顶到下可能要经过五六层，这个东西能否称为微服务值得商榷——微服务理想的情况，是把每一个工作模块拆分到最小并分别将其服务化，但是一般来说拆到这么小粒度的，架构上会有极大的挑战，首先是功能需求的变化，可能就贯穿到前后很多层的变化，这在服务中接口是一个重大的事情，需要完整测试。如果拆分太细，QA会经常说环境部署太麻烦了，本来只是测试，但不得不部署整套服务来做这个事情。所以，微服务的粒度到底控制在什么样的程度，这是一个值得商榷的事情。

   徐串认为，一个好的架构师，在微服务概念出现之前的架构设计工作中，其实就会有意识地发现一些瓶颈，或者一些高扩展的东西，但是要把这个粒度要控制住，一定不能造成不可控制的复杂性。百度的模块拆分原则，是从最简单的开始迭代式演进，强调不要过度设计——最开始是一个小服务的时候，可能就是一个单机系统，把所有的东西放在一起，当发现有部分代码经常升级、形成瓶颈，就马上做重构，把这部分拆分出来，形成一个独立的服务——不是一开始就被服务化或者SOA的概念所困扰，一定要选择适合业务发展水平来迭代式地发展。

   PaaS与DevOps

   整个PaaS的推进在中国最早不是很成功，徐串认为最关键的原因PaaS最初只能适合单一的技术，只适合起步阶段的公司，但是任何一个公司业务发展起来以后，单一的技术基本都无法满足需求，企业会担忧受制于某个PaaS平台，业务不能很快地发展，所以即使一开始选择PaaS，也希望是自己来搭建环境。所以，百度开放云的PaaS会提供PHP、Java、Python、Node.js等的支持，提供MySQL、MongoDB、Redis、Port、Cache服务，同时为企业成长设计了一套方案，可以一步步地升级。

   运维自动化也是PaaS强调的一点。徐串表示，国外的程序员对DevOps理解得更透彻一些，国外大公司的趋势是讲全栈，不但要做开发，也要做运维测试。国内的DevOps潮流刚刚起来，传统模式下研发、运维、测试还是分得很清晰，研发往往认为运维的工作运维就能搞定，研发不用去考虑。但是百度在实践中会发现，一个系统研发上线以后运维要投入大量的人力，因为系统在运维上设计的不完善，比如怎么做升级，怎么做一些小流量测试，这些东西如果做得不好，经常会对稳定性产生集成产生巨大的影响。所以百度逐渐要求在设计阶段就要考虑，一个系统上线以后一定会涉及怎么升级，要怎么样在不影响业务的情况下做这些设计操作，怎么样方便部署，怎么样提取出更多的信息，要提供对外的接口，方便地观测到内部运行情况，让后期能够很方便地发现系统中潜在的问题。所以在整体上来说，DevOps的趋势绝对是正确的，如果不能在设计、开发阶段就把可运维性考虑充分清楚，对可靠性将是巨大的挑战。

   百度的自动化运维，慢慢地从日常业务运维转向自动化运维，比如监控、部署都可以平台化、标准化，让所有的平台设计综合自动管理对接。从把代码提交到代码托管SVN以后，后面的CI集成、上线发布、小流量控制，都是一套完全自动化的全流程。工具方面，百度使用的基本都是内部研发的，包括监控平台、日志收集系统等，在集群操作系统里面进行部署操作，进行小批量升级、流程控制等，这些东西会运用开源的思想，但是不会直接用开源，因为百度的需求要解决的时候，社区往往还没有成熟的开源产品。

   开源的借鉴

   百度在多个技术领域都有对于开源技术的借鉴，徐串表示，百度会时刻密切关注开源技术的发展，思考开源技术到底对百度业务有什么样的作用，哪些应该引入，哪些不应该引入，最新引入的是在做Spark的一些工作。

   • 最开始是Hadoop，整个分布式存储和分布式计算都是2008年开始从Hadoop发展出来的，到2009年百度的需求就超出了社区的需求，社区主要面向的还是一些机器数在1000台以内的中小型企业，而百度很快就到了3000台的瓶颈，只能自己优化Hadoop内核，再到一万台的时候，百度和社区同时开始做，已经产生了巨大的分歧。

   • 数据仓库层面，百度借鉴了开源的Hive、Impala来构建自己的产品和服务，包括列式存储、MPP架构等重要思想。

   • 容器集群管理方面，百度并不落后于Google太多，开始之时还没有开源的Kubenetes。Kubenetes比较好的一点，就是它把一些先进的理念标准化、规范化，百度会观察Kubenetes标准化定义了什么东西，能否用于自己的容器管理调度，为后续要开放自己的容器服务提供参考。

   从大数据到人工智能

   大数据的工作涵盖数据收集、存储、统计分析和应用，百度主要关注高效数据传输、海量数据存储、海量数据处理和数据仓库建设与管理，基础还是分布式存储系统和分布式计算系统。分布式存储也不完全是做大数据，也会支持一些图片、视频、手机软件的分发，日志，同时一些做基因检测的公司也会把一些低成本存储需求放到百度开放云；在计算方面，百度开放了BMR——一个Hadoop、Spark云端托管服务，把现在完全开源的生态集成到百度开放云端来，利用百度运维、管理经验和核心优化，为企业提供更好的服务；此外，百度大数据还做了一个做报表和多维分析的OLAP引擎Palo。

   大数据的高阶应用是支持人工智能技术发展，人工智能对于百度开放云架构的影响包括硬件和软件两个层面。

   1. 硬件层面，面向通用计算的CPU，其性能不能很好地满足人作为一个工智能平台的需求，百度正在尝试两种方案：

      • GPU加速。大规模机器学习需要的大量矩阵、向量运算，是GPU所擅长的，用GPU加速成为业界通行的做法，尤其是在分布式深度学习训练中。百度也构建了大规模GPU集群，GPU数量在这两年有飞跃式的增长，支持各种机器学习任务。大规模GPU集群同时也意味着高性能网络改造的需求，因为单机性能增强，能处理的数据量提升，百度此前已经完全升级为万兆网络，但从人工智能的发展情况来看，节点和节点之间的交互也越来越频繁，百度也在高速网络方面试点做一些预演性工作。
      • FPGA加速。 GPU虽然计算性能好，但耗能比较大，会影响IDC的成本，而在相同能耗下FPGA能够提供比GPU更好的性能，可能将来的人工智能算法会有专用的FPGA。百度目前也在探索FPGA的规模应用，基本所有支持在线广告的机器都插一块FPGA卡。最大的障碍，是FPGA本身还具有一些硬件的特征，涉及到布线、功耗优化、流片，一个FPGA程序的迭代周期要远比单纯的程序迭代周期要长。如果未来FPGA开发具有像现在软件编译器一样的工具，能够智能化地进行功耗的调优，减少对芯片工程师编写代码的能力的需求，迭代速度就会大大提升FPGA平台也允许快速迭代，包括功耗测试。这需要很长的时间来实现，需要业界共同努力，百度目前是根据业务的情况，以自然增长的方式进行探索。

   2. 软件层面，百度在人工智能工程化上发现一些比较重要的东西其实是通用的流程，如底层网络通信的优化，可以说跟算法不相关，但是实际上应用的时候不可避免遇到这些问题，百度基于大规模的机器学习的经验构建一个统一的平台，包装成BML产品提供服务，让算法工程师只需要关注自己的主要算法，怎么更好地设计人工智能策略，而不用关心底层大规模平台的设计。BML目前基本上实现全流程托管，包含了20多种最常用的机器学习算法——百度发现需要对现有经典算法做改动的需求很少，大量工作还是在数据处理、特征提取上——用户可以基于标准流程自定义成自己的平台。

   架构师必须是程序员

   尽管百度在积极利用人工智能技术，百度架构师也在努力为人工智能的发展提供更好的平台以促进该技术的进步，但被问及人工智能能否简化架构师的一些工作，徐串认为这在目前还很难，因为架构师面临的最大问题是取舍，这是一个很复杂的事情，要从业务需求出发，在人工智能能够理解这个业务的情况下，这会是一个趋势，但是这还需要一个很长时间——如果人工智能能做到这样，人类现在大部分工作都可以由人工智能取代了。

   谈到架构师的自我修养，徐串表示，一个比较好的架构师，既要有很宽的技术视野，也要能理解业务需求。

   1. 架构师必须是程序员，如果不能理解程序开发中的痛，就不能理解程序员为什么对需求的变化那么敏感，考虑为什么会有这些架构的代码的时候，很难作出让程序员满意又能满足业务需求的取舍。所以架构师首先必须必须深入到底层了解程序员在做什么事情，开发框架是怎么样的，要跟进最新的技术。

   2. 程序员和架构师的差距，在于不能脱离底层编程的工作，从更高的高度来看待问题。在一个系统复杂的时候，底层程序员常常只看到比较底层的一部分，但更重要的是业务需求到底应该怎么拆解的，过于复杂的系统应该怎么分析，所以架构师需要提升自己的高度，真正地去看业务上有什么样的需求才需要做这个架构的变化。

   对于架构师应该怎么关注新技术，徐串推荐了两种途径：

   1. 关注一些国际顶级的会议。因为最新的一些思路、研究方向，都会在一些国际顶级学术会议上发表论文。而等到书籍出现的时候，意味着该技术已经比较成熟，所以书只适合程序员，他们刚刚进入新领域的时候，找一些经典的书籍去很快地了解该领域有什么东西。

   2. 跟进整个开源界。现在开源成为大趋势，基本上很多新技术都会进行开源，所以架构师要紧跟这个潮流，同时结合自己的业务经验来做一些判断——虽然很多开源技术很繁荣，但也有很多开源技术只是昙花一现，所以架构师要理解技术的本质，到底是在解决一个什么样的业务问题，才能做出正确的判断。