云原生软件开发与运维 · 大咖微访谈，来咯~

Posted 2021-04-03 腾讯云原生

云原生软件开发与运维

智能化软件开发微访谈

背景介绍

包含容器化、微服务、服务网格等技术在内的云原生已经成为新的技术浪潮，深刻地改变着软件开发、维护和运行的方式。根据Gartner的报告预测，到2022年将有75%的全球化企业将在生产环境中使用云原生的容器化应用。与此同时，大规模云原生应用的运维管理也成为一个新的挑战。本次微访谈针对云原生软件开发与运维这一主题，邀请了来自工业界的多位专家围绕云原生对于软件开发和运维所带来的思维和技术变革、企业实践探索及未来发展方向等多个方面的问题进行研讨和交流。

主持人

彭鑫

复旦大学教授

嘉宾

张冬梅

微软亚洲研究院副院长

张峻（Bobby）

腾讯云原生首席架构师

曲显平

百度云原生业务负责人

郑然

百度主任架构师和基础架构技术委员会主席

王含璋

eBay应用研究员

孙凯

京东零售集团技术中台效能平台负责人

林帆

阿里巴巴研发效能部技术专家

杨志博

华为技术有限公司华为云核心网软件总工

访谈主题

云原生软件开发与运维

01

您是如何理解“云原生”这个概念的？例如，这个概念是如何产生的、具体是什么含义、对于企业带来的收益等？

02

“云原生”目前在您所在的企业和部门落地状况如何？目前已经形成或采取了哪些新的方法、工具和实践？取得了什么样的效果？

03

云原生对于软件工程带来了哪些思维变革？软件开发方法和技术，特别是软件架构设计和软件开发过程，发生了什么样的变化？

04

云原生对于软件开发、测试和运维带来了哪些新的问题和挑战？

05

面向云原生时代，您对于目前计算机及软件工程专业的学生的专业学习和技术发展有什么建议？对于软件工程领域学术界的研究者和研究生们的研究思路和方向有什么样的建议？

Q&A记录

Question 1

主持人：您是如何理解“云原生”这个概念的？例如，这个概念是如何产生的、具体是什么含义、对于企业带来的收益等？

张冬梅（MSRA）：

我理解云原生这个概念的核心是要充分利用云计算平台，实现应用的快速迭代，大规模扩展，以及high resilience。这里快速迭代和大规模扩展都容易理解。High resilience指的是应用能够对错误做出快速反应，并且仍然能够运行。

云原生对企业实现以数据驱动为核心的数字化转型起着至关重要的作用。数据驱动需要收集、存储、处理、分析、建模大规模的数据，并根据分析和预测的结果及时对已有业务进行调整，或者发现新的业务机会，扩展业务范围。所有这些需要强大的IT平台和技术作为支撑。一般企业尤其是中小企业很难通过自己的IT部门实现这些业务目标。而云原生提供了解决方案，使得广大企业的数字化转型成为可能。

观点讨论

@彭鑫（复旦大学）：嗯，看来既包括快速迭代和扩展，又包括运行时的质量保障。

张峻（腾讯）：

云原生(Cloud-Native)这个概念一直在发展中，所以在不同的时间段会有不同的定义。“云原生”这个词是由Pivotal公司首次提出的，在2015年，CNCF(云原生计算基金会)对云原生起初的定义包括三个方面：应用容器化、面向微服务架构及自动化管理。之后随着容器、Kubernetes、服务网格等技术的演进，现有定义已限制了云原生生态的发展，在2018年，CNCF对云原生又重新进行了更广泛的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。”

云原生其实不是要求应用在云上开发，或者业务部署到云上，而是描述了一个如何创建，开发应用的一个过程。云原生有三个主要特点：容器化，动态调度，微服务。这些在方便了应用管理，应用扩容，资源隔离的同时，更是解决了一个团队合作的问题。同一个业务的不同团队可以开发多个微服务来支撑同一个业务，它们之间可以自由选择自己的技术栈，不再需要统一编程语言，日志格式，系统依赖等一系列问题。

云原生能够有效的为企业提高收益降低成本、提高效率以及提升服务稳定性等。

观点讨论

@彭鑫（复旦大学）：我们应该可以从内涵和外延两个角度去理解云原生。从外延看可以看相关的典型技术和实践。从内涵看可以考虑云原生背后的精神，我的理解是软件应用的架构、开发、部署和运维都充分考虑并利用云的特点（分布、可伸缩等）。

曲显平（百度）：

个人觉得核心含义是用完全面向云的模式去实现软件架构，最大化释放云的价值。对于企业来讲，最核心的收益就是极致的资源弹性和业务弹性（成本、效率、稳定性），全面提升研发效能。

郑然（百度）：

上面的嘉宾说的非常有价值，云原生cloud native在英文里是两个词，代表下一代云计算技术。cloud 代表了第一代云计算技术， 以IaaS 资源虚拟化为核心，解决了资源弹性的关键问题，云计算资源可以让企业可以按需使用按量付费，通过规模化效应降低企业 IT 成本。但是资源的虚拟化没有解决应用的弹性问题，包括应用的可用性，交付弹性，研发效率等问题。native 的思想核心是应用按照云的特点设计，让应用天然生长在云上，天然的具备面向应用的弹性能力。资源弹性和应用弹性相结合，充分释放云计算的技术红利，从弹性，敏捷，可移植三个层面给企业的数字化转型提供良好的技术支撑。

观点讨论

@彭鑫（复旦大学）：嗯，弹性不仅仅指运行时的伸缩和资源弹性，也可以包括业务扩展的弹性。

@张冬梅（MSRA）：非常赞同。

@彭鑫（复旦大学）：@郑然（百度） 从资源弹性到应用弹性，让云上的软件应用成为原住民。

@郑然（百度）：没错，彭老师说的原住民这个词非常形象~~

王含璋（eBay）：

在云原生被“泛用”的今天，我理解它是：一种创建高性能、安全、可靠的分布式系统的指导思想；一种围绕松散耦合的微服务和高效敏捷开发的设计方式；利用容器化、DevOps等构建和运行服务程序的技术体系；也是一种对应用层提出约束和infra层提出要求的“协议”。

云原生在CNCF的官方定义中，我们也不难发现其对业界的最终收益主要围绕在资源利用和开发效能上。

孙凯（京东）：

关于云原生的概念，网上有非常多的阐述，基本可以归类为2种说法：

（1）一种说云原生=持续交付+DevOps+微服务+容器化；简单解释为云原生是一个概念集合，可以说既包含技术（微服务、容器），也包含管理（DevOps 持续交付、康威定律、重组等）可以说是一系列云的技术和企业管理方法的一种集合。

（2）第二种是在CNCF官网的一段描述定义：

“云原生技术有利于各组织在公有云，私有云和混合云等新型动态环境中，构建和运行可弹性扩展应用。云原生的代表技术包括容器、服务网络、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好，易于管理和便于观察的松耦合系统。综合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”

谈起云原生就不得不提起云原生的计算基金会（CNCF），K8s V1.0版本是在15年推出，CNFN基金会也是15年诞生，基金会的成立致力于推进云原生的发展，可以说：云原生的诞生、以及被大众接受 和CNCF基金会的成立有着密切的关系。

我们在谈论云原生的时候，已经很难避开谈论容器技术，容器已经改变了企业内软件的开发方式和软件的交付方式，相信越来越多的企业也正在拥抱云原生带来的红利。

观点讨论

@彭鑫（复旦大学）：@孙凯（京东） 两个定义好像一个侧重外延（技术和实践的集合），另一个侧重内涵（根本的追求）。

林帆（阿里）：

云原生这个词比较公认的来源应该是Heroku的创始人Adam Wiggins在2011提出的云原生12要素，后来Pivotal的Kevin Hoffman出版了《Beyond the 12 factor App》这本书，基于原12要素新增了3个新要素，变成云原生15要素。

目前流行的云原生定义有CNCF和Pivotal的两种版本，具体内容前面嘉宾基本上也都提到了。相对来说，CNCF的定义更强调容器、弹性、不可变基础设施，Pivotal的定义偏向DevOps和微服务。可以说云原生这个概念从一开始就带有很强的一种商业属性，但同时也具有很强的实用性。

企业会普遍接受云原生，既是因为Google、Pivotal等大公司牵头倡导，同时也证明云原生确实为企业带来了实际收益，最典型的一个方面就是成本下降，具体有两个关键方面，一是标准化，云原生把集成设施层以下的部分全部标准化起来了，特别是对于中小公司，可以把有限的技术人员投入到产生更多价值的业务上去；二是弹性，服务云原生化以后能够充分的利用云的弹性，更好地应对流量峰值和低谷，并且达到降本提效的目的。

其实从云厂商的角度来看，技术生态的开放性会带来的新红利，云原生能更好的帮助云厂商扩展云的市场，既吸引更多的开发者共建生态，又推动了企业业务全面上云，获得平台和客户的双赢。

观点讨论

@郑然（百度）：同意，云原生让基础架构能力不断下沉， 从而让应用逐渐减少对基础架构 的感知。

@张冬梅（MSRA）： 是的，共建良好生态实现共赢。

@彭鑫（复旦大学）：@郑然（百度）  这个跟软件工程和系统软件的历史发展脉络也是相符的，不断沉淀共性，使应用开发者专注于业务。

@王含璋（eBay）：作为私有云的开发/使用者，此时非常羡慕各位公有云产品可以直接让更多用户使用，我们都是服务内部。

杨志博（华为）：

其实云原生一直在演进中，没有一个标准化的定义。个人理解，云原生是一套理念和优秀实践的集合，主要是为了应对日益复杂和频繁变化的需求，提升研发效率用的，是敏捷开发的进化和实例化。

观点讨论

@曲显平（百度）：同意，云原生的定义一直在演进中。

@郑然（百度）：非常赞同，云原生其实是云厂商，开发者和用户共赢的技术。

@李辉（百度）：云原生的出现可以叫业务侧逐渐聚焦在自己的业务上，不论是基础设施还是服务逐渐做到透明化，未来弹性、敏捷等都是原生的能力，就好比一个孩子刚出生就有三头六臂了。

@彭鑫（复旦大学）：@杨志博（华为）我追加一个临时的问题哈，今天其他嘉宾基本都来自互联网行业，而您来自华为云核心网部门。在云原生的理解和实践上，您觉得与互联网行业有什么区别吗？

@杨志博（华为）：对云原生的理解上大家都一样，但是在具体实践的时候还是会有很多不同，华为毕竟是面向运营商交付产品，产品最终是在运营商自己维护，而非华为自运营。所以在具体实践上会有自己的特色。

讨论环节

@张可（复旦大学）：各位嘉宾好，我是复旦大学软件工程实验室的学生，想请问一下，容器技术的什么特性使得其能成为云原生基石呢？或者说他的哪些特性比较契合云原生的“气质”呢？谢谢！

@郑然（百度）：非常好的问题，很多同学也问过我同样的问题. 我认为容器镜像是云原生领域最极致的创新。因为容器镜像让软件交付这件事变得非常容易了，我上学时候看到 linux live CD的时候就感受到这真是一个神奇的技术，完全不需要那么复杂的装机过程，插上 CD 就可以运行操作系统了。容器镜像技术其实就是达到类似效果的创新。

@张峻（腾讯）：如果只能用一个词来说明的话，我可能会选：可迁移。Build once,  run anywhere!

@郑然（百度）：对，彻底解决了软件运行环境的问题，从而实现了 build once,  run anywhere。

@彭鑫（复旦大学）：build once, run anywhere 。以前Java好像说过 write once,  run anywhere。

Question 2

主持人：“云原生”目前在您所在的企业和部门落地状况如何？目前已经形成或采取了哪些新的方法、工具和实践？取得了什么样的效果？

孙凯（京东）：

京东从很早开始就拥抱云原生，京东作为 CNCF 云原生基金会的白金会员，京东是 CNCF 开源项目最大的使用者与贡献者之一，我们一直都在积极采用 CNCF 的项目、参与开发贡献并与其他成员一同合作共建社区。京东在每年的618和11.11大促期间，都会面临到海量的数据和流量的增长，无论是从前端的网站、订单、结算、支付，还是搜索、推荐，以及到后端的仓储、配送、客服、售后等各种业务系统都面临着前所未有的超级流量挑战。因此，京东自然更需要一个灵活的、有弹性的、可规模化扩展的平台。目前京东运营着全球最大规模的 Docker 集群、Kubernetes 集群，以及最复杂的 Vitess 集群之一，目前我们已基本实现了“All in Containers”，是目前全球容器化最彻底的互联网企业之一。

京东分别在docker、Kubernetes、harbor、Prometheus、Helm、Vitess等云原生产品上都有非常丰富的生产实践。效果：全球规模最大docker、k8s集群，承担目前京东零售几乎所有的线上业务；2016 年，京东需要云原生的 Registry 维护其镜像中央存储库，为京东节省了大约 60% 的镜像中央存储库维护时间；京东早期的mysql数据库在发展过程中变得越来越大，导致性能下降，运营和维护成本上升。我们通过Vitess实现了京东的JED弹性数据库，实现大规模数据库服务进行可伸缩的管理，目前也是全球规模最大的Vitess集群。

王含璋（eBay）：

eBay最近10年做了3代云计算平台，在和各个不同种类的应用打交道的过程中逐渐成熟，上几代的APP已逐渐完成容器化的迁移，而新系统基本都是围绕“云原生”去实现的。因为我们是私有云，所以创新的内容大多是围绕核心功能及其可靠性。

简单介绍几个我参与的创新项目：

1. 我们设计并实现了围绕微服务、微服务调用关系和调用特征（流量，延迟等）构建一个“承上启下”的知识图，用于实现跨栈及跨域知识获取、效能分析、生态分析、架构异常检测等功能。

2. eBay内部有一个自研的云原生的分布式数据库系统（Nudata），我们在去年为该系统制作了一个基于图的可交互故障排查工具：先铺了底层信号，也就是各级组件关键时序数据预警，然后在包括 rack/ host/ disk/ pod/ replica/ shard/  namespace 的实时拓扑图上传导并推荐故障组件。

3. 今年我们制作并上线了一套带可视化的根因检测工具：通常由业务域异常或程序强异常触发使用，在程序依赖图上采集多种运维异常及开发行为，使用类似专家系统+图传导进行事件层的根因分析，主要优势在于情境感知（Context-aware）、异常检测种类和支持范围广，可扩展性强。在我们内部实际测试和使用统计表明准确性较高，现在也成为了日常SRE工具之一。

观点讨论

@林帆（阿里）：含璋的异常检测论文我有专门拜读过，写得非常的落地。

@彭鑫（复旦大学）：@王含璋（eBay）所介绍的eBay的实践侧重于智能化运维特别是异常检测和故障定位。

@张冬梅（MSRA）：大规模的知识图谱构建相当不易 能分享下及时维护和更新方面的经验么？谢谢。

@王含璋（eBay）：我们是batch daily update，维护更新确实挑战特别大。数据有变动就要跟进修改，而且图结构也要经常调整。

杨志博（华为）：

容器/微服务/servicemesh这些典型的云原生技术都有落地，可以认为我们交付的是一个完整的面向电信领域的私有云解决方案，追求极致性能机制可靠性，所以很多实现会自己研发。

郑然（百度）：

百度最早在 2011 年就在探索云原生的思想，从早期用最原始的利用夜间空闲资源的思想，到自研的 PaaS 和微服务框架，再到向云原生社区更标准的和开放的技术，一直在积极的进行探索。目前百度的 PaaS 平台托管了上千万个容器，每周数千次变更，支撑着上万个工程师共同研发，超大规模的混布技术也是大幅提升整体资源利用率的核心武器。从 2018 年开始向 CNCF 社区的技术演进，从去年开始截止到现在，百度信息流大部分流量都运行在以 istio+envoy 为核心的服务网格技术之上，业务的微服务架构和服务治理架构效率提升了10倍，可用性提升了1个数量级。今年我们启动了百度地图全站迁移到 K8S和 servicemesh 架构的项目，单个 K8S 集群机器数过万台， 数万个服务实例运行在 servicemesh 上，优化了 envoy 的转发性能，大幅度降低节假日流量突增带来的成本。

张冬梅（MSRA）：

大约在2010年以前，微软的一些重要应用，例如Office，开始从on-premise开始向云平台迁移，转变为云服务，Office 365在2011年6月份正式推出。这个过程对工程团队而言是个重要的学习过程，的确是边学习边实践。我们的团队也是从那个时候开始做Cloud Intelligence (也叫作AIOps)方向的研究，包括数据分析，算法研究，工具开发，系统搭建，等等。当时我们和产品团队密切合作，在动态系统监测和故障诊断方面做了大量的工作，我们的工作部署到了生产环境当中，对提高系统运维的效率有很大的帮助，尤其是在产品模式转变过程当中起到的作用尤为显著。

Bobby（腾讯）：

腾讯通过推行“开源协同、自研上云”为基调的公司内部技术改革战略，助力自研业务上云。在自研上云的过程中，首先实现基础实施了上云，把网络和设备搬到云上，实现资源的统一调度和管理。为充分发挥云的优势，之后又提出更高要求：使用云原生的研发模式，利用云的能力。让TKE(腾讯云容器服务)作为自研上云和开源协同的统一容器服务底层提供者，助力自研业务实现云化架构，拥抱云原生。

目前在腾讯，大部分核心业务已上云，并实现全部或部分云原生化。大家熟悉的一些腾讯产品，比如近来比较火的腾讯会议，已经实现全量云原生化，轻松支持日活千万。

林帆（阿里）：

阿里服务的容器化进行得比较早，我们开源的Pouch容器历史可以追随到Docker还没诞生之前。然后在去年，也就是19年阿里内部最大的一个基础设施工程我们叫“集团上云”，把非阿里云机房的容器逐步下线，全部迁移到云机房的新集群，这里就埋了一个伏笔，因为云机房的新集群底层调度全部是基于Kubernetes实现的。但为了兼容原有服务的部署方式，在运行环境上做了很多定制改造，实际上还不能说是云原生。

今年最大的一项工程就是“云原生化”，把交易链路上最复杂的核心应用进行改造，一部分中间件改造成Sidecar，成功部署到了阿里云的ACK集群里，这个ACK服务就是大家在阿里云上直接能用的那个，全称是Alibaba Cloud Container Service for Kubernetes。早上看了一下，具体数据目前也已经公开了，今年双11交易核心业务链路80%的服务都是部署在ACK上的。

讨论环节

@李博文（复旦大学）：各位嘉宾们都谈到了容器，k8s，服务网格等云原生技术在公司的实践和落地，现在Serverless也比较热门，我想请问一下各位嘉宾在企业中有没有在Serverless方面有过一些实践经验呢？

@彭鑫（复旦大学）：关于什么样的业务或功能适合用Serverless，大家怎么看呢？或者反过来说，什么样的业务或功能不适合Serverless化？

@曲显平（百度）：Serverless层面，百度的AI技能训练落地非常广泛，比如小度开放平台给数以万计的开发者开放了技能训练的能力，开发者可以使用函数计算这样的服务，简单上手，快速实现，还具有超强的弹性能力。

@林帆（阿里）：Serverless对流量型的应用场景是个很有潜力的方向，阿里系有不少用户端的入口应用都已经函数化部署了，现在大家打开手淘，看到的各种商品内容，都是通过Serverless函数来运行和支撑的。

@郑然（百度）：类似 AI 计算或者小程序这种轻量级计算特别适合函数计算的产品。

@张峻（腾讯）：说起Serverless，除了大家常说的FaaS以外，我们也在实践Serverless Kubernetes。

@彭鑫（复旦大学）：嗯，是不是流程性、事务性比较强的业务和功能不太适合Serverless？

@张冬梅（MSRA）：Event-driven applications会比较适合吧，有时批处理，有时idle， pay-as-you-go会经济些。

@林帆（阿里）：流量非常稳定的后台服务，Serverless化以后成本可能不降反升。

@彭鑫（复旦大学）：嗯，就是那种流量爆发性强但持续不强而且比较轻量级的功能？

@张冬梅（MSRA）：嗯，持续性不强是关键吧。

@李博文（复旦大学）：请问这种流量型的应用场景，运用Serverless的优势在哪里呢？

@林帆（阿里）：不用提前预估流量，确保入口不会被打挂。对于链路太长而且实时性要求又很高的服务来说，Serverless也不太适合。

@王含璋（eBay）：Serverless 在现有的架构中做减法，减掉了很多管理和配置工作。我很好奇它的迁移成本比如换平台是不是要比传统微服务难得多？

@郑然（百度）：迁移到函数计算类的产品， 确实成本较高。国内企业使用类似函数计算的产品还处于初级阶段吧， lambda 可能在国外比较容易被接受~

Question 3

主持人：云原生对于软件工程带来了哪些思维变革？软件开发方法和技术，特别是软件架构设计和软件开发过程，发生了什么样的变化？

张俊（腾讯）：

微服务在云原生时代的演进的过程中，有效的解决了微服务生命周期管理以及运维管理难题，使得微服务架构和体系能够和云与云上面的服务、平台，以最佳的方式工作、协同在一起，降本提效。

业务逻辑与支撑组件分离。通过中心化的日志，监控，链路追踪，业务应用可以把许多业务逻辑之外的功能从业务应用中分离出来，交给平台来完成。更能够通过为业务应用部署sidecar的形式在不侵入应用代码的情况下对应用进行更加细粒度的监控和控制。比如说大家常常听到的Service Mesh，就是利用了sidecar这种模式，通过部署在平台的统一控制面对应用的安全、网络流量、监控、测试等提供了更多强大的能力。

云原生特别是Kubernetes为资源提供了一套统一的抽象，容器减少了对底层系统的依赖。这大大减少了技术人员对每一个应用，每一个环境所需要做的适配。这直接促进了CI/CD，多集群，多云等技术实践的快速发展。

郑然（百度）：

云原生更倡导敏捷的研发模式，可以说重新定义了软件生命周期。特别是以 DevOps  为核心的技术和文化，相比原来的瀑布模式，DevOps  更强调自主化，这不仅仅会影响研发，还会影响企业的组织结构和企业文化，帮助企业有效的打破部门墙, 提升企业整体的效率！以技术撬动整个文化，恐怕云原生是第一个了。

观点讨论

@彭鑫（复旦大学）：@郑然（百度）是云原生造就了DevOps，还是DevOps推动了云原生的发展？

@郑然（百度）：@彭鑫（复旦大学）哈哈，我个人认为是云原生推动了 DevOps，如果没有成熟并且被广泛接受的云原生技术，DevOps 的思想还是很难落地的。

@曲显平（百度）：@彭鑫（复旦大学）在云原生理念之前的DevOps，更多侧重分享、协作、文化等方式的传播；在云原生之后，更技术和产品化，更落地。

曲显平（百度）：

云原生，让原本耦合在业务架构里的很多基础架构能力下沉，这样业务能够更加专注于业务本身逻辑的实现，减少对于基础架构的关注，全面提升研发效率~

王含璋（eBay）：

云原生让软件开发更自由：比如开发者可以相对更自由地选择最佳的语言和框架组合开发，这对于特定语言友好的项目（如Python for ML）是很大的优势。更敏捷：一个会统一下API就可以各干各的了，ownership也更明显，再加上CI/CD实现敏捷DevOps 和自动化。更效率：无状态的服务变得非常轻松，有状态和涉及持久存储的服务会受到一些影响，但总体乐观。韧性更强（个体）：高可用性和灾难恢复能力更好。在此背景下，大家的思想更开放，灵活，但耐心也变差了。

此外，云原生向不同角色普及了“好系统”应该具备容错性好、易于管理观察、松耦合等特性。随着云原生的不断推广，软件开发、测试和运维这三个角色有了一定程度的“融合”：开发人员认识到除了完成自己的业务逻辑的部分，一个好的软件设计还应该受到哪些约束以便于建立一个弹性可扩展的系统。而运维人员往往需要提供更多的自动化的手段和更多的实现云原生的技术来和开发人员一起建立这个弹性可扩展的系统。这也是为什么CNCF在致力推广一系列开源项目来建立云原生系统的原因。

观点讨论

@彭鑫（复旦大学）：@王含璋（eBay）比如开发者可以相对更自由地选择最佳的语言和框架组合开发：但是我从一些厂商听到，为了便于问题分析和定位，一些大规模微服务系统还是尽量采用统一的技术栈。

@王含璋（eBay）：@彭鑫（复旦大学） 是的，还是有大环境限制，这也说明了observability 还有提升的空间。

孙凯（京东）：

云原生给软件工程带来了很大的改变，在云原生之前原来一个产品可能会拆分成几个模块，然后分别由几个团队部来开发，最后在整合在一起，而现在通过微服务理念的拆分，把一个产品拆分的更细，可能是一个人或者几个人负责一个服务的开发，每个服务之间又都是相互独立的,并且相互通信，这些服务都是围绕一个业务。全部都是各自通过自己的机制进行独立自动化部署发布，这些服务可以是不同的编程语言，甚至可以使用不同的数据存储机制，最终实现业务的正常运转。

林帆（阿里）：

先说结论，目前阶段，对现有的大型软件系统来说，云原生对软件架构的影响还有限，但对开发过程的变化已经能看出来了。

这里架构我指的是整体系统的组件结构，理论上说，云原生应该能对软件架构产生一定的简化作用。像容器统一编排、流量统一管控、应用去状态、引入Sidecar、引入BaaS等等，都能通过将一部分原本要在业务代码里完成的功能下沉到平台来实现，从而让软件架构变薄的目的。

但事实是，对于已经相对成熟的业务开发团队来说，把部署环境迁到云上去，可以，但如果要让大家都来改项目代码适配这种云原生的“架构简化”，就比较难推动。

阿里这边，交易的几个核心应用是改动比较大的，特别是配合Sidecar化的改造。其他的业务线上，改动主要在中间件和运维系统上，业务也要配合改造，但通常不做架构层面的大改，而是像升级一下依赖的中间件版本，局部替换某些有状态的代码片段这种。

在软件开发过程方面，我们通过引入了基于GitOps的发布模式和基础设施BaaS层，通过OAM应用模型来统一描述应用的各种依赖和能力，把以往要在多个平台界面配置的流程全部实现了代码化。

每个应用自带全套的运行环境和BaaS依赖描述，在调整基础设施参数的时候只需要在代码上直接修改、提交就可以了，这套流程目前收到的反馈还不错，接下来应该能比较快的推广开来。

观点讨论

@王含璋（eBay）：@林帆（阿里）这个观察非常同意，我们之前的系统经过多方讨论，最后权衡下来只做容器化。

@彭鑫（复旦大学）：@林帆（阿里）嗯，改造都是循序渐进的，因为要考虑风险以及性价比。我们调研发现业界很多微服务系统改造都不彻底，很多都带着一些尾巴：粒度很大的遗留系统被包成一个大服务与一些更标准化的小服务共同支撑业务应用。

@郑然（百度）：@王含璋（eBay）哈哈，我们也有这种情况。

@王含璋（eBay）：然后云原生上的“继子们”穿上了新衣服，继续调皮带来各种挑战。

@曲显平（百度）：新的价值 > 旧的价值 + 迁移成本。否则肯定是不划算的。

@郑然（百度）：@曲显平（百度）技术要给业务带来价值。

@林帆（阿里）：任重而道远哈。

@张冬梅（MSRA）：软件工程的问题从不只是技术问题。

@王含璋（eBay）：所以对于学术界挑战特别大。

@张冬梅（MSRA）：@王含璋（eBay）是的，所以倡导研究人员深入实践看到真正的问题。

@彭鑫（复旦大学）：那看来不是架构影响不大，而是性价比和迁移成本、时间、风险的原因，所以先放弃一部分收益而先去收割另一部分容易获得的收益。

Question 4

主持人：云原生对于软件开发、测试和运维带来了哪些新的问题和挑战？

林帆（阿里）：

云原生把过去讲了很多年的PaaS思想以一种更加灵活的方式落地了，但这种大PaaS的结构在一定程度上也给开发运维带来了更大的黑盒和系统规模化的坑。

对软件开发来说，要去遵循许多云原生的规则，比如不确定的服务启动顺序、服务随时可能被调度到其他主机、应用的状态可能随时丢失等等。我们实际还遇到的一些挑战在于，业务规模太大，从业务侧逐一去进行改造的成本太高，怎样平衡业务在云原生的投入和效果这样的问题。

运维方面的问题特别多，尤其是中间件Sidecar化以后，很多适配性的问题要解决，包括安全问题、可观测性、异地多活等等。

杨志博（华为）：

云原生相比原来单体、SOA架构更加解耦和轻量化，开发效率是更高了，但是小独轻松的微服务如何串联起来组合为一个完整系统，其中有很多挑战。比如，5G要求端到端毫秒级时延，但我们微服务解耦以后消息交互更多了，如何保证业务流端到端更低的时延呢？比如分布式云化场景下基础设施出故障的概率更高了，如何进行故障检测确保实时业务迁移？比如，如何提供整体的运维界面，保证客户操作的一致性？这些都是比较大的挑战。

王含璋（eBay）：

我从生态和运维两个视角讨论一下。

生态：在我们观察公司微服务宏观生态时候，架构问题就显现了：比如一些“微”服务长“大”了、资源不合理配置以及不理想或不健康的依赖关系等等。管控就更难了：推动难 - 新功能比重构要诱惑大得多；估值难 - 技术债务很难有效且客观的评估；执行难 - 很多“瀑布”式的债务修复代价太大。最后从技术上来看，无论自动手动，实现上层架构分析的同时感知底层环境真的很难，这点还要加上传统系统的数据质量和断层问题。这点我的感悟是不要想太泛，卖力具体地解决具体问题还是机会的。

运维的挑战也很多，可靠性越强的系统，失败的时候往往越可怕。微服务虽然个体的韧性和可观察性强，但发现故障时，整合信号并实现根因定位是很大的挑战。对于核心业务，纵使有专业的SRE和开发人员值班监控，排查故障的过程也会遇到很多干扰，比如“软”错误，比如跨依赖、域、架构（软、云、硬、内网、外网）和人的排查问题。再从底层举个例子，开发人员设置的告警很被智能系统地利用，而统一部署机器学习预测的异常又很难做到高泛用性。所以，如何高效高质系统地开发各层级监控信号，再贴合运维需求和习惯地提供有效可靠的自动化/智能化辅助是一个很有趣的挑战。

所以，银弹是绝不存在的，微观个体的独立自主必然带来宏观生态的管控挑战。微服务的自由和速度是把双刃剑。心态上我们变得更容易“迁就”了，技术上也更容易实现“迁就”。最后，面对一个“只对开发者可见”的灰盒们凑成的黑洞，挑战自然就来了。

观点讨论

@林帆（阿里）：对运维的挑战会特别大。

@彭鑫（复旦大学）：生态这块的问题应该就是传统的软件演化和设计退化在云原生中新体现。而且云原生系统一定程度上打破了原来的软件系统边界，基础设施也越来越复杂，因此服务和演化治理的难度更高。感觉有点像一个不断膨胀的城市带来的可持续发展和治理的挑战。单个微服务开发难度降低了，但复杂度并没有消失而是上升到架构层面了。

孙凯（京东）：

传统的软件开发过程，会将软件的开发、测试、运维拆分为各自独立的部门，每个部门的角色不一样，各自有着不同的KPI，针对每个部门不同的需求，不同的KPI，怎么调和？而云原生中提出DevOps的理念，DevOps是一种重视dev和ops之间沟通合作的文化和运动，云原生的变更绝对不仅仅是通过工具的变更，而是从思想到方法，再到工具的一整套理念。只有解决这些问题和挑战，才能更好迎接云原生时代的到来。

郑然（百度）：

云原生会进一步模糊开发，测试和运维的边界，我们很多团队都是由研发来完成开发，测试和上线的全过程的。云原生基础设施更好的帮助企业实现了这个过程。如果没有云原生技术，仅仅通过机制或者人工的管理手段，是不可能实现全流程自主化的。百度也一样，原来都是运维同学才能操作上线，每次上线都需要研发发单，运维来操作。为了提升效率，我们希望研发能够自己完成上线过程。后来开发了自动化的 DevOps 平台，大胆的实现了研发自主上线的过程。另外业务架构需要遵循云原生的技术特点，我们在落地过程中设计了一些云原生服务的指导原则，帮助业务开发出适合云原生的服务。

曲显平（百度）：

DevOps改变着角色的职责，也改变着组织模式；传统的测试QA和运维OP角色逐渐在减少，现在更多是负责构建流水线、构建自动化测试能力、构建资源调度、容量管理、智能运维等能力。

张峻（腾讯）：

感觉问题还是很多的，大家提了很多。我说两个很直白，却很实在的：

1）学习成本、应用迁移、业务改造。云原生归根到底是一个新的标准，业务上容器上云和业务云原生改造是两个阶段。云原生改造要求技术人员去学习微服务框架，Docker，Kubernetes等一系列新的技术。

2）版本管理、更新。云原生改造，微服务改造使得业务的快速更新，一天一小迭代，三天一大迭代成为了可能。可是快速的迭代也要求更完善的测试，要有更加自动化的发布和回滚流程。

张冬梅（MSRA）：

云原生依托于云计算平台，因此，云计算平台的可靠性，稳定性，响应速度，运行效率，以及安全性就至关重要。从数据驱动的角度去研究这些问题，如何借助于机器学习技术来研究这些问题，如何有效地把研究成果转化到生产实践当中并不断地迭代改进，都是当今Cloud Intelligence这一方向研究的热点问题。

这里对Cloud Intelligence略作说明。Cloud Intelligence is to utilize AI/ML technologies to effectively and efficiently build and operate complex cloud services at scale。Cloud Intelligence 主要包括三个方面的研究题目 – AI for System，AI for Customers，and AI for DevOps。跨越这三个方面，Cloud Intelligence 的主要问题包括：检测，诊断，预测，以及优化。每一个问题都有各自的挑战。

我们目前的研究主要集中在云平台本身，对云原生应用的运维问题的研究刚刚起步。上面各位专家谈到的诸多挑战很有帮助。

观点讨论

@曲显平（百度）：很大程度上，云原生让业务有了更强能力的同时，也让一个完整业务的复杂度变高了。相应地，其研发、测试、运维工具链的水平和能力都需要跟着提升~

@彭鑫（复旦大学）：“effectively and efficiently build and operate complex cloud services at scale” build这块的支持能举一两个例子吗？

@张冬梅（MSRA）：一个例子是应用预测技术提供负载情况，使得系统能够proactively调度资源实现更高效的配置。没有预测技术只能做reactive的处理。

@王含璋（eBay）：这块感觉需求比运维和安全低一点，我们也想做，但是公司没人响应，大家习惯了各种“安全方案”了。

@张冬梅（MSRA）：如果有可观的经济效益，比如降低成本，是否product team会有兴趣？

@张峻（腾讯）：我的感觉和在公司的实践来看，中长期肯定是非常感兴趣的。短期来说，降成本和保业务之间有一定的冲突，如何能渐进式的推进，正如您之前说，不纯粹是一个技术问题。

Question 5

主持人：面向云原生时代，您对于目前计算机及软件工程专业的学生的专业学习和技术发展有什么建议？对于软件工程领域学术界的研究者和研究生们的研究思路和方向有什么样的建议？

林帆（阿里）：

关注新领域出现的新问题，比如规模化带来的更大的黑盒，更高的不确定性等等。

从学术界来说，从数据着手是非常好的切入点，在云原生里，可以说是一切皆数据，面向终态的配置、可观测性的指标、服务运行的日志等等，而且Kubernetes在一定程度上也统一了各种系统的数据结构，对科研场景来说，可以说是非常好的切入时机。

观点讨论

@彭鑫（复旦大学）：“规模化带来的更大的黑盒”是指复杂性带来的认知障碍？那应该是个假的黑盒，即内部很多关系和数据都能获取，但数据量大关系复杂所以很难被理解和掌握。

张冬梅（MSRA）：

简单分享下 - 从学习的角度而言，传统的软件工程基本功之外，学习并掌握数据分析和机器学习的技能是非常必要的。从研究的角度而言，建议软件工程领域的学者能够加强和企业的对话和合作，亲自到企业去访问和交流，看到软件开发实践中的问题和挑战，从而寻找更具实际意义的研究课题以及合作机会。

张峻（腾讯）：

处于云原生时代，企业上云已成为必然趋势，所提供的开发、运维、测试、产品等岗位，会有需要具备云原生相关的技术能力和思维的要求。所以同学们在学好自己的专业课的同时，也要关注当前主流科技公司中应用到的新的云原生技术，并进行相关技术的学习。

这里建议各位同学：

1）多关注云原生开源社区，更多的参与到云原生相关的开源项目中。

2）多探索高校和企业项目的合作，产研结合，推动研究成果的技术落地。

方向上，除了大家都提到的云原生方面的一些热点技术（如跟数据的结合）外，大家有没有思考过云原生未来在哪里？这是一个很大的问题，我想给大家提一下我们关注的一个关键词：边缘计算。云计算、云原生，是否会进一步进化到边缘计算、边缘原生？云边协同应该如何做，在新基建、5G受到广泛关注的今天，是一个值得进一步深入研究的话题。就说Kubernetes本身，对边缘计算（边缘容器）的支持也还是远不成熟的，这里已经有一些的项目，但感觉更多的是机会。

观点讨论

@彭鑫（复旦大学）：嗯，云原生软件技术研究与MSR这类软件工程研究很不一样，不深入到企业根本看不到相关的问题和数据，因为开源社区只能提供开发态的数据而不能提供发布和运维态的数据。

郑然（百度）：

云原生是实践性很强的技术方向，特别需要在大规模的真实环境中锻炼，所以特别欢迎感兴趣的同学来百度云原生团队实习，参与线上软件的研发工作，理论和实践相结合。我认为云原生技术会向 serverless全面演化，基础架构能力进一步下沉，包括安全容器，webassembly的轻量级虚机，ebpf，服务网格，资源调度和服务管理，云原生安全等领域都非常具有研究价值。

观点讨论

@彭鑫（复旦大学）：云端融合、人机物融合的应用场景中有很多也可以采用云原生的思想和技术。云计算的概念和技术还可以进一步从数据中心泛化和延伸到边缘和终端设备上。

孙凯（京东）：

云原生的技术发展飞快，在云原生时代我们需要不断关注和学习接受新的技术、新的趋势，例如服务治理的能力、Serverless的机遇和一些挑战，学习和研究向来不是一蹴而就的，需要不断汲取理论知识，然后将理论不断付诸实践，最终用于生产给我们带来价值，无论目前是学生还是这个领域的学者，都建议都要拥抱云原生，参与进去，也可以回报社区，最终实现价值。

王含璋（eBay）：

对同学们，我同意各位老师们的观点。首先我觉得云原生并没有改变行业规律，还是尽早参与实际开发以及体验流程和生态，提升实现能力（如学习、算法和写码）和敲门能力（如面试、实习和履历）。其次，前面提到 了云原生时代的角色“融合”，这意味着知识的横向拓展和快速学习能力也变得更重要了，如果没有系统学习的机会或时间，建议抓住机会多看看手上任务的“上下游”。

在云原生的环境下，我觉得高价值（学术和业界双认可）的研究更需要“泛用”性。对于企业来说，科研落地有很多关于成本VS收益的权衡：成本包括重置或集成成本，计算资源等等，收益包括必要性，（中短期）实际收益等等。往往云原生相关的科研在这种“贪心算法”下很难胜出，因为云原生的平台或者系统一般是很复杂且多样的。所以如果是已经走得够深的算法/框架/方案，希望能留意一下可扩展性，数据自由度，易用性等等降低“成本”；或者做一些调研进一步贴近实际诉求/利益。

另一方面，从企业实际产品走出来的成果，很容易面临一些学术质疑，比如算法不够绚，问题已“被妥善解决”等等质疑。这类产品其实非常适合和学校合作，归纳拓展后再探索更专精的方案。最后就是希望学术平台能多吸引一下云原生从业者投稿，去过KubeCon的朋友们就知道我们领域的潜在市场有多大。

观点讨论

@彭鑫（复旦大学）：确实工业界和学术界的价值取向和偏好不一样。工业界实用的解决方案需要对上下文环境和各种限制有充分理解，在此基础上局部的算法到不一定有多复杂或创新，而学术界评价论文还是倾向于有一些新颖的模型或算法什么的。

访谈结束，福利来袭