——何碧波
本文将分享国际中台在云原生下的关于研发效能的一些实践，将先从关于研发效能问题的一个定义上面去展开讲研发效能是什么，以及云原生下带来的一些理念的变革，它带来哪些价值的一些变化。然后基于国际中台的问题，我们是怎么基于云原生的东西去做一些模式上的探索与模式上的沉淀，甚至是架构上的一些变化。最后展开阐述在云原生下能够对研发效能、业务架构带来哪些价值。
- 应用研发下的研发效能
首先从关于研发效能问题的定义，以及它解决的主体去看一下我们整体的方向是什么。
研发效能核心是关于某一个业务需求，它交付效率的问题。那么需求交付中按照研发过程来看，其实包含三个阶段，变更、提测和部署。这三个阶段其实可以拆解成四个过程，然后再分为多个节点，包括变更之前，我们更应该关注什么，比如需求的质量，一些沟通效率，技术方案的一些评审等。然后变更之后，比如我们的编码效率、单测。然后提测之后可能测试环境，包括Bug修复率。然后部署之后可能是构建，然后发现问题的一些效率以及运维效率。
那么在这四个大的阶段里面，其实变更之前我们通常是通过项目管理的优化，以及解决项目上的管理，去实现人员安排或者项目排期。在变更之后，去关注研发模式是不是能够升级业务架构，包括运维能力，也就是测试能力，包括发布机制是不是能够更加优化。
核心来说通过这个去看一下研发效能，它其实是对需求交付过程比较直观的一个体现，同时也是管理维度和技术维度的一个反应，但它其实也不是某一个指标的结果。
比如我们去优化了测试环境稳定性，包括方案的可行性更加高效产出，其实不一定会对研发效能带来一些质的变化，其实它是一个综合的反应，所以说它是一个多元方程的最优解，并不是某一指标的最终结果。
举一个类比的话，比如最近出的 “十四五”的规划里面，就类比我们整体的人均寿命所提高一岁，其实这就是比较直接的一个体现，不会因为某一个指标的改变就能够提高某个人一岁的寿命，而是社会综合的东西发生变化才会带来社会寿命的增长，也是代表一个国家的实力。
- 当前应用研发现状
那么阐述清楚研发效能的定义和定位之后，我们看一下研发的现状，包括变更研发，变更测试，变更发布以及应用运维，其实都是研发过程中需要关注的一些点。
这些点会存在一些不同的问题，比如变更相互干扰，单测成本高，包括一些稳定性联调环境，测试环境的不可用，测试环境的排队，以及Bug的修复效率。包括变更的发布，应用构建耗时，发布流程的管控以及分支相互干扰。
应用运维这里包括告警，监控，定位复杂度，其实都会影响业务的效率。所以从最开始看，它里面的每一个点都会影响研发效能，但它每一个点并非优化之后就能直接反映到研发效能上。
研发过程的复杂性以及不确定性，也就是变更保障机制基础能力的缺失，包括发布之后运维基础设施的不齐全。通过这些问题，我们现在通过发布管控以及发布成本控制大家的发布频次，提高大家对发布的安全认知，但是最终结果可能会影响我们研发效能，导致需求不能被快速交付。
所以基于这个现状，其实我们提出了的五个问题，第一个是变更范围能否最小化，也就是变更的确定性，测试环境是不是能够快速稳定地交付，以及各个业务东西能不能分层分批地进行增量交付，应用发布是不是一定要通过构建才能发布，是不是可以做一些增量发布，从而提升发布效率效率。
我们通过这五个问题里面去看一下，云原生对这五个问题是否有相应的新解法和新方案。
- 应用研发下的云原生技术理念
下面我们看一下云原生带来的一些技术理念，在介绍技术理念之前，我们先看一下云原生之前的容器时代，它的应用架构是什么样子的。
如上图所示，比如应用，它抽象来看会包含上面大的模块，第一个是包括运维组件、中间件，包括技术业务组件的SDK、业务功能模块。我们核心关注的是业务功能模块，其他模块是业务研发不怎么关心的，它只是需要使用这些能力，需要集成这些东西。
应用的一些迭代会蕴含着对四个模块的变革阶段，包括运维组件SDK的升级，技术业务功能迭代，基础组件的SDK升级，其实都会通过应用去生效，这个是什么原因导致的呢？我们要通过应用变更、统一构建、统一部署、统一运行，去完成这四大部分的自动交付。
那么这会导致什么结果呢？比如资源隔离性很差，容器的一致性不可保障，以及研发交付的复杂度，因为交付内容不只是业务本身，非业务态的东西都随着应用一起交付上去，交付过程的单一性，就是我们只能通过应用去完成交付。
最终的一个结果就是，我们的业务架构或者应用架构容易被其他的非业务东西进行腐蚀，或者业务迭代会更加复杂化，那么应用也会变得逐渐臃肿，部署内容也不可控。
本质的原因是应用源码作为一个集成声明的唯一载体，然后应用统一构建作为发布镜像唯一来源，应用容器作为运行态的最小单元，应用的进程是作为隔离机制的最高级别。这会导致上图中间一个容器的大致分布，可能不管是从进程隔离，线程隔离，或者是没有隔离，甚至客户端没有隔离，只是一个功能集成，这会导致容器的稳定性、隔离性很差。
这里抽象一个词来表示，它是一个All In One的研发模式。One代表是所有东西通过应用去驱动研发的过程，这是云原生之前的研发过程所暴露出的一些问题。
那么现在看一下云原生下应用研发过程是什么样子。
从研发生命周期去看的话，从研发态、部署态、运行态与运维态，在云原生里都有相应的手段和机制去保障，提供新的方法和模式。
比如研发态里面，我们将镜像作为模块化的唯一交付物，然后以声明式的方式做统一的功能集成，通过K8s完成功能的编排式交付。在运行态里面，我们通过类似于Match这种方式实现能力下沉以及能力分层，从而实现不同能力的分层迭代。
运行态通过运维组件，通过组件化以及标准化去实现它，而不是通过之前组件SDK的方式给业务提供支持。这样实现整个模式以相对比较灵活高效的方式来支持业务交付，从而确保业务交付的稳定性。
通过上面的模式，我们拆解下面新的云原生研发过程，还是以上图的应用作为设计来阐述。云原生里面可以拆解成四个模块，四个模块里面比如中间件、运维组件、业务组件和两个业务模块之间，它们会有独自构建的Pipeline去完成自身的变更和交付，最终各自会产生自己的镜像。镜像之后，它们最终会通过应用的 IaC文件完成运维能力的声明，最终是通过K8s完成将Pod作为唯一一个交付单元，进行最终部署上线。
这个Pod里不是一个单容器，它是一个多容器，通过容器提高功能之间或者组件之间的隔离性，这相比于单容器里的进程隔离或线程隔离的隔离性要好。这里提供了面向人的分布式研发模式，这个分布式体现在对非业务相关的，或者跟非业务之间模块的分布式并行迭代的能力。
介绍完研发效能相关的一些基本问题定义和云原生的一些理念，以及云原生能带来的一些思考，下面我们看一下面对国际中台自身的业务问题与中台问题，怎么基于容器去解决。
- 业务视角的云原生
在讲问题之前，我们要先有一个体感，就是在业务视角下，云原生做了哪些事情。
在业务研发里，我们更关注的是软件工程的实施过程，在开源软件工程的定义里，它是研究和应用如何以系统性的、规范化的、可定量的过程方法去开发和维护软件，它涉及到编程语言、数据库、软件开发工具，系统平台、标准以及设计模式等方面，最终完成要达到的一些事情。
基于这个定义，我们看一下云原生做了哪些相关的事情。
在系统性方面，云原生通过从基础设施和技术架构集中进行云化，上层研发模式基于Gitops构建研发体系，并不是单个模块或者能力去进行升级。
从规范化上来说，它规范了镜像作为交付标准，OAM作为应用研发交付模型，并且通过 Baas化的方式实现基础能力交付的载体和通道。
对于定量，它的可度量性也就是可确定性，云原生里面就更加直接，比如说不可变性作为云原生的一个基本原则，也就是基础设施不可变，轻量级容器、镜像不可变。
确定性是指发布内容的确定性、资源交付的确定性、运行态的确定性。
基于以上看的话，它想要做的事情跟软件工程是比较匹配的。
介绍完之后，我们可以看到云原生所做事情涉及的范围跟软件工程比较匹配。这就涉及到面向云进行架构升级，包括技术架构和业务架构，包括基础设施的能力升级，面向云的基础设施，包括资源，中间件，一些想要的技术、容器或中间件的内容，包括DB、缓存等都是面向云的，也就是基于Gitops的研发产品体系，然后以围绕镜像编排构建上下联动的运维研发平台，建立镜像标准基础设施的推进。我们也有可能去探索面向云的一些软件设计模式，这也是一个方向。
这样看的话，其实云原生是以云的思想去探索全新软件工程的最佳实践，以及面向云的软件工程的研发标准和规范，最终是构建面向云的研发、运维产品体系，基于这个寻找业务研发的新方向，最终通过底层的全面升级实现研发效能提升带来质的变化。
基于以上内容，大家对云原生解决的问题以及做的事情，可能会有整体的认知。
- 国际中台业务现状
有基本认知之后，我们看一下现在国际化遇到的一些问题，就是国际中台希望通过一个中台支撑上面不同的业务模式、规模、形态的电商实体，给业务架构提供更加开放的模式，让业务实现定制。
这里涉及到组织协同，包括管理机制上能够出现更加灵活的业务提供给业务方，这也是国际中台的一个挑战。
目标的话，我们中台能够实现能力的下沉，并且具备可编排、可增量、可定制化的交付，并且业务方也能够基于中台实现更加自主高效的变更迭代和业务演进，这是我们想要达到的目标，同时也是一个挑战。
基于云的基本理念和基本思想，包括云带来的技术能力，对于以上目标与挑战，我们该如何解决？
- 国际中台业务架构升级
上方是基于云原生实现国际中台和业务架构升级的示意图。
这里面的核心是我们将平台能力实现了轻量化，业务实现了应用化，平台能力基于镜像作为载体，去完成自身的迭代演进，业务基于应用做好研发过程中持续迭代的交付。
基于业务的应用化之后，业务中台和中台之上的各个业务站点之间能够实现全生命周期的解耦，包括运维，变更，管控态等，都是独立业务，这就会提供给业务更加高效的迭代和变更能力。整个过程是基于国际化中台，基于云原生构建的研发运维平台实现和落地的。
从过程来看，我们在研发态安全管控，运维应用管理，运维能力等平台管控方面都实现了看得见的一些价值。核心做的事情是中台能够提供给中台之上的业务独立变更运维和管控的能力，提高业务自身的研发效率和自主率，从而实现业务需求的持续交付，提供平台更加高效和独立自主的迭代演进能力，而不依赖于业务的某个东西，这样的话它们之间能够相互解耦。
这是中台基于云原生做的架构升级，抽象去看的话，运用在业务架构上，它的模式是比较通用或适配的。
先看业务架构演进的过程，从当年应用微服务到现在云原生提的平台化交付以及SaaS化的交付，其核心是云原生镜像编排，实现架构分层交付以及分层迭代，同时依托Baas的统一资源的申请交付，实现资源统一托管，也会清晰地计费，这是云原生在架构演进中做的核心事情。
回归到上面基于国际化中台实现的平台和业务升级之外，从业务本质看到实现了基于镜像作为平台能力的载体，提供平台独立演进和独立交付的能力，实现平台和业务的独立迭代和交付解耦的交付模式，整个过程就是上图中所展示的。
平台会有自己独立的工程，业务应用有自己的工程，那么平台会依托于云原生业务镜像的交付平台，去完成各自的镜像构建和交付。
在应用的库里面，它是作为一个应用持续迭代，在应用构建之后，它们构建出应用镜像，在应用镜像发布的时候，可以选择用什么样的平台以及版本，最终完成一个Pod作为单元进行交付，从而实现多容器的集成。
这是通过国际化中台升级模式比较业务架构去看过程中它本质做了什么事情，以这个推演这个模式里不只是适用中台和业务的场景，还适用更多更加普适性的场景。
- 云原生下的业务架构升级
比如基于这个模式实现客户端下沉以及面向容器编排的合并部署，客户端的下沉的核心是当前现状的客户端里面的逻辑比较复杂，无论是内存还是CPU上，对应用总体都存在一些资源的抢占。
基于这种编排我们把富客户端整体下沉到容器里，通过容器壳的方式把它包装起来，然后实现资源在容器层面的隔离，隔离性上有一个本质的提升。
最终我们通过进程通信，实现富客户端能力和业务的集成，这就是依赖于Pod的一些基本特性，包括网络共享、存储共享，以及进程共享等能力实现交互和集成过程。
基于这个，对富客户端带来一些独立迭代和独立交付能力，它的交付过程可以不依赖于应用的一次发布或者应用的一次构建，在智能轨迹上就更加明显了，这样的话它不只是一个进程隔离，它是个容器隔离，可以有独立的CPU，独立的内存，甚至是独立的存储，去达到一个更高级别的隔离。
合并部署方面，比如我们当前的合并部署方案可能需要将被合并的东西以JAR包或源码的方式拷贝到目标的合并应用上，这里会发生什么变化？这改变了应用的部署结构，甚至是工程结构、业务架构结构发生变化，这让合并部署方案实施过程的成本变得很高。
基于云原生进行编排的话，我们可以实现同一个工程结构既可以完成应用形态的部署，也能够完成镜像编排交付，这降低了合并部署的实施成本。
对于隔离性，我们可以通过一些手段，不管是内隔离还是Spring容器实现运行态的对象隔离都能实现。资源包括运维效率、运营成本和机器资源的使用，也会降低一个资源成本。这也是我们发现云原生的模式不只是适用于中台业务，还可以被用于更多场景。场景核心是基于镜像编排，实现独立交付和独立迭代变更。
- 云原生架构落地情况
介绍完一些具体偏向业务架构的落地成果之外，我们在过程中对于一些云原生的技术能力也进行了整体的拉平。
比如我们的资源全面K8s化，从K8s去完成国际化的资源交付，以及Match化，实现了国际站点的Match化覆盖率，应用要实现云原生的改造，支持云原生模式。云原生架构升级这块，实现了一些比较通用的架构模式演进，实现了云原生项目业务价值的挖掘。
那么基于这四点，我们最终完成了三件重要的事情。
第一个是云原生理念规模化，让更多人去理解、接触、使用云原生，让它不再只是一个理念的东西，而是研发过程中实实在在感知的东西。
第二个是标准规模化，我们基于云原生去构建云原生下面的应用标准以及镜像标准，之后进行大规模的推广。
第三个是创新规模化，基于中台的模式进行架构的落地。
最终我们实现了云原生从零到一的规模化，建立了大家对新模式认知的一个体系，梳理了现有模式的缺陷，搭建全新的模式去探索未来研发效能和业务架构上的新方向。
- 云原生下研发效能整体表现
以上是站在整体的层面上去看，回到云原生下研发效能的整体表现，我们还是围绕整个研发过程去展开，我们做了一些相关的事情。
比如变更迭代，实现了编排解耦，实现独立的迭代能力。测试环境方面，我们提供了一键测试环境交付，除此之外还有发布过程、启动效率、运维效率等方面，我们对每个阶段都做了一些具体的事情。
我们也看到了一些已经可以被量化的结果，比如容器交付效率，我们通过 Smart Policy智能发布管控，实现了发布等待时长缩短，以及测试环境的一键交付，实现了测试环境冲突频次降低，基于中台进行编排，提高业务平台的交付效率。
从这些方面来看，我们已经有一些可以被量化的东西，但是通过这几个量化的东西，能不能真正影响研发效能，或者直观反映到研发效能提升，这我认为现阶段是比较难，因为研发效能是体系化的整体性东西，不是某个单点优化了就能够带来一些质的变化。
- 云原生下的研发运维技术体系
所以基于以上，我们去梳理需要建立云原生下研发运维的技术体系，这个技术体系核心就是依托于之前介绍的云原生的基础技术能力、技术理念，同时叠加我们自己的一些场景，去探索一些我们原先定义的标准和规范，构建围绕研发运维生命周期的产品体系，支撑上面的一些场景，比如构建国际化研发运维的平台。
在这个之上的话，可以看到我们可能是从应用交付的过程，以及流量调度，甚至云原生的一些资源使用上去提高和改变现在的一些问题，从而定义一些新的场景，最终实现站在国际化中台的业务架构上，去看如何支持好国际化基础架构的落地，包括中台架构以及基于多站点租户的架构如何基于云原生落地，这是我们基于云原生构建两个研发体系。
最终我们是要以新的理念去解决现有问题，以现有问题去填充和丰富我们在云原生里面的一些理念，从而达到我们看到的一些实在的结果，最终形成一个自下而上以及自上而下的双通道，去探索云原生的价值。
以上是我们通过体系化进行升级，从而推动研发效能带来一些质的变化。
- 云原生下问题 & 挑战
我们发现在做这个事情的过程中，存在一些挑战和问题。
第一点是现有的研发运维产品体系对云原生理念的约束，比如我们现有的应用研发模式对镜像编排不友好，基本上可以说它没有镜像编排这个东西。镜像编排对业务这一侧是没有感知的，这一块是否需要构建面向镜像编排的运维研发产品体系。
第二点是新架构模式欠缺配套研发能力，包括以镜像作为业务交付的载体，如何构建研发配套基本能力，比如镜像之后，单个镜像可能就不具备独立的启动能力，怎么实现单测或本地测试的成本。
第三点是云原生业务价值缺乏定量度量。上面讲的一些国际化场景里挖掘的价值，有一些是定量的，比如业务架构一些模式的创新或者业务架构的一些模式沉淀定量的结果。但是定性的东西，比如云原生一些新的理念，包括镜像的交付，这对于业务研发来说，可能它的价值感知不明显，如何把这个价值做得更显性化，基于云原生理念做一些新的输出点，从而增加一线业务研发对云原生的理解，从而愿意投入更多的成本，让更多的人参与到云原生，这是我们认为当下比较大的一个挑战。
- 云原生价值挖掘——Mesh化
基于现状与挑战，后面能够做一些事情，比如在Mesh化里，能够挖掘一些业务价值。在社区提出Mesh化之后，在实际生产场景里其实没有带来业务价值，核心原因是虽然它对基础架构进行统一升级，但对于业务层它没有带来一些质的变化。
所以站在业务上来说，我们认为流量调度这个东西在Mesh能够带来一些业务价值，我们会统一基于Mesh的控制面构建业务流量调度的统一体系，对业务带来价值，那么这个架构体系我们怎么去建设？
核心过程可能你是谁，你要去哪里，这是流量调度的一个抽象表达，是构建流量调度的能力。对于云原生场景来说，它要实现对于流量的单场景和多场景怎么识别流量，然后要去哪里，无非就是对服务地址，以及怎么去更好地归组管理。
回到Mesh里面，它是要构建面向Mesh的流量场景定义和多场景的叠加，怎么进行Mesh的构建。以及要去哪里，比如进行Mesh实现服务归组的标准化定制以及自定义规则的标准，如何在Mesh里落地。
基于以上，这个模式可能不只是国际这边的一些东西，我们要构建线上线下的流量调度体系，将产品体系进行标准化、统一化，降低流量隔离和业务调度，包括环境的稳定性，同时也能实现面向服务的产品体系。我认为这对业务测试有价值，而升级基础设施带来的价值不是很明显，Mesh的价值比较明显。
- 云原生价值挖掘——Baas化
进入Mesh之后，我们下一步要做Baas化，Baas化的核心是要去完成应用态对基础设施的依赖声明和定义。
我们会将基础设施进行云化之后，它可以被定量和定性交付，这样的话它通过Baas完成定义和声明的时候，能够实现资源的统一管控、使用和接入。
最终站在国际化场景，提供了SRE更灵活的资源管控，有统一的管控视角去管控国际化，或者是面向不同业务维度的资源管控能力，基于Baas提供业务研发统一资源申请、交付、接入标准，提供业务管理者灵活的计费能力。
以上三点是我认为Baas化对业务侧的价值核心，主要是站在SRE、业务研发以及资源管理角度去看带来的一些价值。
我们发现Baas化或Mesh化是技术体系的升级，但是围绕研发效能来说的话，它不只是技术体系，研发生命周期过程都要升级。
- 云原生价值挖掘——研发模式升级
因此，我们回到如何基于云原生升级研发模式，从研发、测试、构建、发布、运维这几个阶段去看一下云原生还能做哪些事情，基于云原生重新定义每个阶段该怎么更加合理、高效地去做，最终提升业务研发效能。
以上是本次分享的内容，核心是围绕研发效能的基本问题定位，以及云原生的理念价值，最终回到国际化场景，基于这些理念和价值带来一些变革，或带来一些新的研发模式或新的能力升级，促进研发项目的提升，从定性或定量上进行一些改变。
