软件架构发展至今，经历了从单体架构、互联网分布式架构、到现在的Serverless 架构。2022年，云原生技术以势不可挡的之势，大规模在不同行业落地，并依然霸占技术话题热度榜首。2023年随着企业业务的快速恢复，对于云的使用将会达到新的水平，如何用好云也将成为企业角力的关键。本次对话，希望通过阿里云云原生应用平台负责人丁宇（叔同）的观察和理解，帮助更多的企业决策者厘清技术价值，提供借鉴参考。叔同：有两个方面我的感触比较深，一个是开源的发展，一个是应用的构建。我解释下，过去几年阿里云有很多技术进行了开源，尤其是这两年开源的速度变得更快了。很大程度上受到了容器与 K8s 发展的推动。目前，容器和 K8s 进入了一个平稳推进和普及的阶段。但是在这之上还有大量的领域需要重新定义，开源在一定程度上是逐渐帮助各个领域建立标准。举两个例子，一个是今年3月 Knative 进入 CNCF孵化，5月 OpenFunction进入CNCF 孵化，以及 9 月 Serverless Devs 进入 CNCF 孵化。这三个典型的项目意味着新的趋势正在到来。像函数计算、事件驱动这样的架构形态，逐渐有了开源体系的支撑。从开发者的视角，大家的技术认知常常是通过开源项目去了解一个新的领域，当这些架构师觉得开源项目不错，就会推动在企业场景中应用，慢慢地形成了广泛落地的趋势。所以，通过大量的函数计算、事件驱动类的项目进入CNCF 孵化，也会给行业带来一些正向的、新鲜的技术血液。从应用侧，我举两个例子来说明。一个是阿里内部的案例，从2021年到2022年这两年时间里，阿里云实现了核心产品的云原生化，这是业界唯一做到的云厂商。一家企业要做容器化，对于新应用来说相对容易一些，而老应用往往会面临很多挑战，需要时间去改造。而对于阿里云这样的平台，能把核心产品容器化并顺利完成，是一个里程碑。从外部案例，阿里云支撑了云上大型体育赛事，实现核心系统百分百上云，以云原生的方式去使用云，能够在云上快速构建应用。这也向业界释放了一个信号，无论是历久弥新的系统，还是海量访问的系统，或者是不同周期、形态不同的系统，都可以实现云原生化。从云服务商的视角，2022年11月云栖大会上，阿里云宣布核心产品全面Serverless化，我们认为Serverless 将成为云原生下一阶段重要趋势。从函数计算、事件驱动到容器化为基础，最后会形成统一的软件架构的方向，慢慢的业界上云用云的蓝图逐渐完整，指引企业如何演进应用架构，云应该如何发展，研发范式如何升级等，所有这些变化的根源都是云原生和 Serverless 驱动的。叔同：我们从一家企业的IT诉求来看，如果一家企业正处于业务高速增长阶段，没有太多资金压力，那么降本往往不是最高的诉求，但是提效会非常重要。因为要支撑业务的快速发展，需要非常灵活敏捷的架构，各种形态的业务能够快速试错；如果说一家企业在业务发展上遇到了压力，需要将精力投入到降本中，但降本的背后也需要成本，无论是时间成本还是人力成本。企业在不同的发展阶段会有不同的取舍点，也会对技术团队提出不同的诉求。但是业界其实缺少了一个普适化、可以解决大家降本提效诉求的技术。
上云能够解决过去一代的技术问题，在过去的十年里，行业逐渐形成了上云的思路转变，但是在下一个阶段，云上应用构建又面临新的挑战，尽管业内有非常多开源项目，可以使用很多云产品，但是没有一套通用的标准和技术，购买服务器、选择规格、部署服务、定制应用及运维等，都需要耗费研发和架构师大量的精力。云服务本身其实也在发生变化，从提供资源到提供能力。云的弹性能力很强，但是如果说云上的服务没有弹性，云上的应用没有弹性，就很难发挥出云的价值。从企业的视角也是如此，如果 A 企业技术水平较高，有 2000 个工程师，确实可以将应用、服务维护得很好；但是国内大部分的企业很难具备这个工程师的体量，尤其是我们希望越来越多的创业公司可以尽快将核心放在业务发展上，而不是基础资源、技术层面的工作，越来越多的企业希望云来承担这样的角色，具备标准化、开箱即用的能力。对于企业而言，取用能力即可。所以，随着容器成为新的云计算基础设施，帮助企业标准化地享受到 Serverless 服务。这就是从需求侧到供给侧带来的降本提效，并且是企业和云服务商一拍即合、自驱演进的方向。
企业是否要应用 Serverless，跟企业的规模有关系吗叔同：与规模没有关系，我们恰恰认为 Serverless 能够抹平技术鸿沟。以互联网架构为例，想要搭建一套完善的体系，最少也需要20几人，从数据库、缓存、网络、消息、微服务等都需要维护，并且不见得可以维护得很好，这其实给业务创新带来很高的门槛；甚至现在很多企业从初创开始只有几个人，要如何去构建自己的系统？所以，我们希望无论是大企业、还是中小企业，都可以抹平技术的复杂度，不因为技术能力影响到大家的业务起点。阿里巴巴从 2006 年开始做互联网架构，2009 年开始做云计算，我们已经具备了近20年互联网架构的经验，以及十几年云计算的经验，我们把这些能力封装提供出来，企业直接开箱使用即可，就避免大家重新再走一遍弯路。
叔同：海外相对来说对 Serverless 的接受度更好一些，主要跟市场成熟度和客户的发展阶段有关。在国内，阿里云提出核心产品全面 Serverless 化、组装式研发，也是希望引领整个市场生态的成熟。阿里云的产品 Serverless 化，底层是容器技术支撑，是更彻底的、自底向上的 Serverless 化。容器的优势大家都很认可，基于这些优势来构建 Serverless 的基础，并推动更多的产品，如数据库、消息、微服务等实现 Serverless化。
FaaS 和 Serverless Container 有什么区别？叔同：FaaS 的核心价值在于让整个云产品体系及其生态形成一个有机整体，而不是单纯的提供弹性资源。这是 FaaS 和 Serverless Container 根本的不同。当一个云产品 Serverless 化后，那么它就不再是单纯的提供资源，而是要成为构建应用的要素。未来整个云的产品体系都会全面 Serverless 化，而且这些产品之间通过事件驱动等方式深度集成后，那么用户可以通过 FaaS 组合其他云服务，快速的实现弹性、高可用的应用。这样的研发模式我们称之为组装式研发。我们比较认可 Berkeley 宣导的 Serverless = FaaS + BaaS。Serverless container 本质上是帮助用户更容易实现 Serverless 化的 BaaS 服务，所以它和 FaaS是为了解决不同的问题，二者可以搭配起来使用。我们认为 Serverless（FaaS + BaaS）未来会成为解决大规模复杂软件开发挑战的关键，这是云未来发展最重要的价值。
叔同：Serverless屏蔽掉了底层的差异性，对于运维领域是一个颠覆性变革，运维会升级为运维研发，因为传统运维需要关注的扩缩容量、网络布局等，都由云服务商来处理了，他们可以有大量精力投入到开发新的平台、推动业务发展、提升产品体验等，不用从事一些手工运维的工作。
叔同：推进 Serverless 在国内的大规模落地不是一蹴而就的，今年阿里云有20多款Serverless 产品，未来也会把产品全面的 Serverless 化。对于我们来说，有一些踏踏实实的工作需要落地，把用户需求高的产品逐渐 Serverless 化，同时也会把函数计算、Serverless 应用引擎SAE、Serverless 容器 ASK 这类产品变得更加普适化，应用在更多的场景中。一个技术趋势从产品能力完备到行业普遍应用，需要一个较长的时间周期。阿里云认准了这个趋势，并且会长期投入，推动大规模落地。
目前我们在行业里也积累了非常多典型的案例，包括南瓜电影、世纪联华、新浪微博、高德等等。相关阅读：南瓜电影 7 天内全面 Serverless 化实践
相关阅读：订单峰值激增 230%，Serverless 如何为世纪联华降本超 40%？｜双11 云原生实践
相关阅读：成本节省 50%，10 人团队使用函数计算开发 wolai 在线文档应用
我们认为 Serverless 代表云计算最先进的生产力，也是云原生的终局，所以我们希望这些案例、最佳实践可以推广到千万企业和开发者中去，从这个维度来看，今年是一个很好的开始。基于你的观察，企业应用 Serverless 最看重哪些方面？叔同：屏蔽技术鸿沟，这个是最吸引企业的地方，当然降本提效也是。很多企业对于一些新技术或者是说明知道这些技术引入到企业中是有好处的，但是受限于人力、资源、成本等等因素，对于一些有价值的技术只能望而却步。现在我们通过 Serverless 形态，让所有企业都能享受到同样的技术起点，在生产工具层面抹平了差异性，大家真正的竞争点就放在业务发展上了。叔同：容器可以从两个方面来看，一个是运行时，另一个是编排调度。今天运行时的发展已经很标准化了，并且拓展了安全、机密计算、安全容器等方向，已经大规模铺开使用。但实际上我认为，铺开的速度还不够快，因为企业在做容器化改造过程中不可避免会遇到很多阻力，比如遗留系统、技术债务等。互联网公司已经都容器化了，或者说正在进行容器化，但是仍然有一些行业因为种种原因，虽然认可容器的价值，但还没有真正落地。在编排调度侧，比如中间件、数据库、大数据AI、基因计算、区块链等，所有的这些新型负载以及大规模异构负载，全都跑在K8s上，因为标准化、通用化带来了提效的好处。今天，混部已经成为了一个新的常态，将不同特征类型工作负载协同调度，充分利用负载之间的削峰填谷效应，让工作负载以更稳定、更高效、更低成本的方式去使用资源。今年，阿里巴巴开源了云原生混部系统 Koordinator，通过开源，我们希望将更好的混部能力、调度能力开放到整个行业，帮助企业客户改进云原生工作负载运行的效率、稳定性和计算成本。相关阅读：阿里巴巴云原生混部系统 Koordinator 正式开源
相关阅读：Koordinator 1.0 正式发布：生产可用、面向规模场景的开源混部系统我们也看到，很多企业对于降本有很大的诉求，但是企业对如何降本、成本如何可视化、如果做成本治理比较困惑，所以今年阿里云也发布了容器 FinOps 套件，通过数字化手段和智能化方法，帮助企业实现成本可视化、可优化、可控制。
叔同：我们不能把FinOps 这件事妖魔化，更不能本末倒置。降本和FinOps 是一个目标，但不是终极手段，企业真正的抓手还是要回归技术本身。如果企业的架构不够先进，没有使用容器、混部这类技术去提升资源利用率，仅仅关注在成本治理的表面，是解决不了核心问题的。最终解决问题依然要靠技术，靠先进的技术，在这些技术之上通过FinOps 工具找到可优化、可控制的点，并持续去优化，这是一个正向的过程。所以在我看来，FinOps 只是辅助的工具，真正优化的核心还是技术本身的先进性。当然，企业的降本不是技术团队的事情，它需要各个部门协同，通过将财务引入，以市场化的方式运作，从粗放式管理、经营演进到精细化管理、经营。未来一段时间，FinOps 都会是大家的关注点，但我更希望大家能看到成本优化背后的技术和架构。云平台其实就是致力于让大家的降本提效更加普适化，我们慢慢把产品技术打磨好，产品能力夯实，不管是传统企业还是新型企业，不管企业用哪种形态的云，最后都可以低成本地实现降本提效；而不是说企业为了降低20%的成本，反而要投入20%的人力来做，这就本末倒置了。我们希望，企业用上了云，就天然可以具备这些能力，帮助企业做好这些事情。
叔同：容器是一个确定性的趋势，企业都在容器化。但是如何用好容器，这是一个非常挑战的事情。我们一方面提供 Serverless容器服务 ASK，让云平台多帮企业和用户来管理。另一方面我们将容器服务向智能化方向演进，包括智能化混部（Koordinator）、智能化成本治理（FinOps）、智能化运维诊断（AIOps）。本质上，还是希望降低容器的使用门槛，降低它的技术复杂度，让企业低成本地用好容器。阿里云容器服务 ACK 已经不再是薄薄一层，相反 ACK 是非常复杂的、也是非常先进的，它能够与计算、存储、网络深度结合，充分释放弹性，简化运维界面，简化异构环境的复杂度，还可以将软件部署在分布式云的场景里，甚至做多云混合云管理，不断拓展云的边界，就是我们说的“ACK Anywhere”。但是这解决的是边界拓展问题，还需要让容器更加普适，这就需要跟智能化手段相结合，比如 AIOps、FinOps、混部等，因此今年阿里云容器服务全面进入智能化时代，就是基于这样的背景。
叔同：随着容器的快速普及，应用都云原生化以后，传统网关已经解决不了云原生时代遇到的问题，如果要解决所有的问题，就需要投入很多组件。但是组件多了以后，运维就会变得很复杂。所以今年我们开源了云原生网关Higress。
它是新一代的云原生网关，最大的特点是流量网关、微服务网关、安全网关三合一，三合一的好处就是运维简单，用一个组件来解决这些功能需求。Higress提供丰富的插件扩展机制，满足客户灵活路由和安全定制需求，支持最全面语言扩展机制；当然我们为了降低客户使用门槛，默认集成了数十个插件，并且通过插件市场方便开发者贡献通用能力，产生良性互动。此外，随着微服务的发展，系统架构会越来越复杂。随着微服务越来越多，上下游依赖都很复杂，在这种情况下，怎么保证微服务治理、链路追踪、灰度、应用管理与配置等，这些事情要统一去解决。所以我们在2022年4月与B站、字节跳动等联合开源了OpenSergo项目，OpenSergo 致力于在不同的微服务框架、通信协议之间达成共识，形成服务治理规范。让业务开发者不会因为不同的语言、不同的框架而产生割裂。让架构师能够用统一的规范来描述自己内部的微服务架构。让中间件开发者能够和现有微服务框架对齐，增强微服务框架之间的互操作能力，促进微服务框架在企业落地。叔同：在容器领域，混部会大规模落地。随着各种负载都部署上来了，必然面对一个问题就是负载如何“和平共处”，提高利用率，因此混部会成为一个确定性趋势。
另外一个就是 Serverless。今年是 Serverless 落地元年，我们有大量的工作要做，比如云产品 Serverless化，对应的研发模式要升级，也需要丰富的产品形态去支持工作流、事件驱动，可视化、拖拉拽开发等。要推动应用架构 Serverless化。随着越来越多行业标杆案例的产生，更多的企业已经感受到 Serverless 带来的好处，现在我们需要一种推动力，让优势成为一种共识，大家都知道应该往哪个方向走，并且去尝试 Serverless 技术。2023年一定是 Serverless 规模化落地的一年，我们会保持长期主义的信念来做成这件事。
本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿
鲁公网安备37020202000738号