辽宁-大连-甘井子||点击17次|课程编号：
目前Java在许多行业的企业信息应用方面的应用非常多，比如OA、邮箱、股票、金融、考试、物流、医疗、矿山等信息方面的系统。该方向和行业密切相关，所以，这是一个经验型的发展方向。Java开发者在这方面的需求也非常大，待遇也相当不错，3~5年工作经验的*在15至20万这是一个很正常的水平。
爱尚教育IT培训-课程优势：
1、技术内容和知识点符合企业实际项目技术需求
2、主流技术栈+主流框架+项目案例实战
3、师资力量：多年项目研发经验和授课经验丰富的技术讲师亲自授课
4、班型设置：10人项目组式小班型授课，教学效果好，学习质量高
5、项目案例:ERP管理系统/金融系统/B2C电商平台/行业门户网站/企业*
学校成立10余年，建立*部门，与IT企业建立长期的人才输送，让学员有更多的*选择机会
爱尚教育IT培训-适合学习人群：
1、致力于从事IT相关岗位，软件开发，软件测试，Web前端等
2、上班族：在职转行，离职转行，在职技术提升
3、学生：在校生，应往届毕业生
4、0基础可学习，年龄18~35岁，能够接受国内项目，对日项目，及欧美项目
爱尚教育IT培训-学习目标：
}
北京市海淀区中关村南1条甲1号ECO中科爱克大厦6-7层
北京市公安局海淀分局备案编号：号
}
今天想跟大家分享几个话题。第一个话题算是有点老生常谈了，就是云原生的概念。今天大家对这个概念都已经非常熟悉，可能不同人对云原生也有不同的解读。所以今天我想先从个人视角跟大家分享我的一些不成熟的看法和见解。第二方面是从如何从构建一个高速业务增长引擎的视角来分享如何用好云原生技术。最后一方面会把字节跳动内部的一些最佳实践拿过来跟大家分享，来佐证前面我讲的一些论点。
我预感今天内容比较多，但还是简单提一下，火山引擎是字节跳动旗下的企业服务平台，我们希望能够把技术、解决方案、增长最佳实践这三位一体联合起来，赋能其他行业实现业务高速增长。
首先我想从我自己的视角回顾一下云原生的发展历程，包括我们在实际落地中可能会面临的挑战。
我这里引用比较骇人听闻的一句老话，大家可能都很熟悉：「软件正在吞噬整个世界」。这里我们更激进一些，这句话放在现在可以说是「云原生在吞噬整个世界」。
这张图非常形象，软件现在很大一部分是以开源的形式提供出来。而今天在整个开源领域里，云原生又是非常庞大的主导力量之一。所以一路推演下来，我们就敢说云原生正在吞噬整个世界。
除了这样定性的论调以外，我们还可以看一些具体的数字：根据 CNCF 去年的统计，在全球被调研的企业中，已经有超过 80% 的企业开始在生产环境中使用云原生技术。在云原生整体的技术体系中，又有超过 70% 的企业在使用大家已经非常熟悉的 Kubernetes 这项技术。云原生体系的演化到今天已经不仅仅是容器或者是
Kubernetes，还有很多新的技术，类似服务网格（Service Mesh）、Serverless，其中Sevice Mesh 在这些企业里面将近占到了三成的比例。所以今天大家使用云原生技术也不仅局限于最基本的容器，而是越来越丰富，不断在向前演化。
作为一个开源的项目，Kubernetes 聚集了更多的开发者，所以在整个云原生社区里，我们也有超过了几十万的开发者一起在做贡献。
这里我想再分享一个我们内部的最佳实践。我相信在座的各位在自己企业里已经充分享受到了云原生的红利，字节跳动也不例外。可能大家都看了今年的春晚，也感受到了在春晚过程中，我们通过抖音的红包雨与全国十多亿观众进行互动。但其实我们当时接到和央视合作任务的时候，距离春晚开播和产品上线只有 27
天时间。在座有不少小伙伴都来自互联网企业，可能也知道打造这样一个全民级的应用，往往需要两个月甚至更长的时间。但是我们在 27 天的时间里，通过一系列云原生技术承载了这种超大规模的流量，保证了系统的稳定性，并且实现了跨几十个部门、上千人的产品工程协同，这是字节跳动内部从调度上来讲一个非常典型的例子，从中我们可以感受到云原生确实给很多企业带来了不同程度的红利。
在这个故事背后其实有很多云原生所带来的助力，比如通过云边协同的调度方式，并使用边缘汇聚机房，可以扛住流量洪峰；通过云原生实现离在线混部，在承载海量流量的同时，还能保证资源够用且高效。在整个开发过程中，我们通过一系列测试和压测手段以及充分的演练，保证业务按时上线，在整个春晚过程中业务非常平缓，没有任何事故。
通过这个具体的例子，我们确实可以看到，企业正在享受云原生的红利。
相信在座各位对云原生到底是什么有不同的解读，这块我想分享一下我的看法。过去跟一些同行聊天，我们也经常发现大家有一个误区，容易把 Cloud Native 和 Cloud Hosting 划等号。有时大家会觉得，我在云上开了一个账号，就是云原生；因为我用云了所以我就是云原生，当然我相信大家都知道这是比较浅的理解。
另外一类场景会认为把业务系统搬到云上就是云原生了。我不光有账号，我的应用都跑到了云上，这时候我就是云原生。这块我用了一张比较形象的图打个比方
其实过去我也听到业内还有一些比较有意思的比喻，云原生这个技术和工具本身可能像高速公路（我们称之为信息高速公路），但我们还是经常会在这个高速公路上跑牛车、驴车，可想而知这个速度还是快不了。虽然我们的基础设施（也就是云原生的计算）效率很高，体系非常敏捷，但是我们上层的业务系统如果还是用比较老套的方式在运行，就是在高速上跑牛车，业务增长的效率还是很难提升上去。
所以对我来讲，什么是云原生呢？我觉得一个最关键，也是最好理解的一点，就是我们看云原生定义的主语是谁。从我的角度来看，云原生的主语不是平台和基础设施，而应该是应用和业务。也就是说，如果我们仅仅是采用了一系列的工具、平台和技术，我不认为这是云原生，而当我们通过这些工具和技术手段，真正把上层的业务系统变得更加敏捷、弹性、模块化、稳定以后，这时候我们是实现了所谓的云原生化。
另外一个同行和朋友经常会讨论的一个点，就是云原生到底是 IaaS 还是 PaaS。我们经常会听到有这样的讨论，有的甚至说云原生是不是底下一定要搭载某些 IaaS 来用。
我最早在谷歌工作，参与了整个 Kubernetes 从无到有的过程，所以这块分享是我们的理解。其实谷歌推出 Kubernetes 之前，谷歌云也有很经典的两类产品，就是 IaaS 产品和 PaaS 产品。IaaS 产品就是各种计算、网络产品，PaaS 产品就是大家熟悉的谷歌 GKE。
那时候我们发现，不管是 PaaS 还是 IaaS 都有两难的困境：首先对于 IaaS 来讲，它可以给用户极大的灵活性，因为用户上来以后就是一台云主机，可以做任何的配置，就像我们进入一间毛坯房可以做任何的装修。但缺点就是在管理性很差，所有的中间件、框架、很多的运维和业务层面的管理都要自己来进行。
但是 PaaS 是另外一个极端：提供了很强的管理性，尤其像 Google App Engine 这样的产品来说，抽象得过于黑盒了，所以当我们想用支持之外的语言或者我们自己喜欢的第三方组件的时候，往往有断崖式的成本在里面。
所以不管是 IaaS 还是 PaaS 其实在可管理性和可扩展性方面都有一个不可调和的矛盾。那时候我们通过推出 Kubernetes、通过云原生技术，希望打破这个僵局。Kubernetes 一方面自带很多高层的自动化管理能力，另外一方面又会暴露很多底层可调用的入口和参数，同时能够兼具灵活性。
讲完了这一些以后，下一步我们就看看如何把云原生技术联合起来。理论上其实是很美好的，也有不同的人总结云原生各种几要素，比如第一步先容器，第二步再编排，第三步再微服务……但是在实际落地中，会发现理论上很简单的事情一旦投产放到现实中以后，就会变得非常丑陋，有很多挑战。
上面又放了两张图，左边的图就是技术栈越来越多、越来越复杂，光容器、Kubernetes 本身也很难形成一个闭环的技术体系去支持业务增长。所以最后出现的情况就有点像俄罗斯套娃，很多技术不断地堆积，一层套一层，相互之间也不一定有非常好的整合性或者通融性。
另外一块就是右边这个情况，有点像我刚才说的在高速公路上去跑驴车或者牛车，但很多时候对于云原生的一些最佳实践，我们并没有用得很好。我们经常会发现在上面跑的就是一些 WEB 应用或者边缘化无状态应用，所以虽然我刚才讲了半天云原生是什么，但是非常遗憾它又变成了新一代的
CloudHosting的平台。所以这都是我们在实际落地的时候发现云原生带给我们的挑战：环境和运维复杂，配置和参数复杂，应用类型多样，仍属于相对底层技术语言。
基于这些挑战，我们就想做一件事情：打造这样一条高速公路，不光高速公路基础设施本身很快，同时提供一系列的改装店或者 4S 店，甚至直接把上面跑的马车和驴车也变成一辆跑车。也就是在打造这样一个系统的时候，不仅考虑平台和工具，而且会直接把很多最佳实践嵌入上层业务，帮助上层业务实现更好的架构，支持业务增长。
为了把这个目标和传统的云原生技术本身区分开来，我取了一个名字叫原生云，看起来有些拗口，但其实这里不只是一个文字游戏，下面我就来解释一下什么是原生的云。
首先，原生这两个字是一个定语，我们要看原生面向的是什么。这里我觉得是要原生面向以下几件事情：
第一要原生面向现代化应用形态。什么叫现代化的应用呢？以前我们写软件的时候，可能都是一个本地运行的软件包，后来出现了 client-server 的架构，然后是 BS（browser-server）的架构。但是今天应用的架构已经呈现了很多新的形态，比如说应用变得越来越移动化，这个移动化不光是原生的手机
APP，可能还是小程序、H5，当我们考虑云原生、CI/CD 的时候，能否面向这种移动化的应用去进行更好的构建。
第二块就是应用变得更加分布式化。这个分布式化，不光是说把应用拆分成多个微服务，甚至不光是跑在云上或者端上，它可能是从端到边到云，呈现一种分布式云的形态，这是现代化应用的一个新的形态。
第三个就是敏态化，这个已经不用我多说了，我们都需要小步快跑，快速试错和迭代。所以说当我们去打造这样的原生云的时候，我们可以从一开始就把一系列的条条框框、最佳实践建立起来，基于这样一套体系构建的应用就是现代化应用的形态。
第二个要原生面向的是新的架构形态。传统的架构是单体应用，后来我们都在提云原生，可能会觉得现代化的应用架构都是基于云的。但技术总是演化的太快，今天甚至我们有的应用、有的计算又从云上到云下了，可能直接运行在端侧，或者是边缘节点、边缘的汇聚机房上，所以说我们在构建原生云的时候，应该天生的就面向这种现代化的、从端到边到云的混合架构形态。
第三，我们希望原生面向的是多云的基础设施。刚才也提到了“云-边-端”，云是里面非常重要的一环，但是今天大家在用云的时候，已经不再是单朵云。这里云可以是狭义上的公有云，也可以是私有云，甚至是混合云或者多云的态势。美国有很多机构做过调研，在国外平均一家企业已经在用 5.2
朵不同的云了，包括私有云。这里要强调的一点就是新的多云的形态，不光体现在基础设施是多云，还体现在应用本身也是面向多云架构的。它有不同的场景，比如说一个应用如何在不同的云之间做弹性，不同的应用如何快速在不同的云之间分发，包括我们根据业务、延迟、用户的分布，在服务层面上做到服务层的多云，这也是我们现在希望去原生面向的新形态。
总结下来，原生云英文叫 Native Cloud，最主要的就是能够原生地面向现代化的应用形态，原生地面向多云的架构，包括云-边-端协同的设施，从而最终帮助业务层面实现高速增长。也就是说我们希望从拉动业务增长的角度去定义这样一个新的体系和平台。
第一，打造 Native Cloud 我们有一些大的原则。这里用英文，比较容易对照出来。
-
From Container Management to Service Management：第二块我们希望能够从面向容器进行管理，变成面向服务进行管理。过去大家都喜欢讲云计算 x.0，也有人说 1.0 是面向资源，2.0 是面向容器，那我认为 3.0 是面向服务，4.0
是面向增长，其实我们希望不断的能够向业务转化。
-
From Automation to Autonomous：进一步从自动化到自治化，所以这个 automatic 和 autonomy 还是有一定的区别的。Kubernetes 里面有很多自动化的东西，自动化的问题在于我们需要有很多前验的经验，需要很多人肉的配置。相信在座各位都用过
Kubernetes，里面有非常多的参数，怎么分配 resourcelimit、quota、报警的阀值，确实这些试好了以后后面会自动化运行了，但是设置的过程很痛苦，设多了也不对，设少了也不对。所以我们希望从自动化到自治化，很多时候业务可以自己动态的进行优化和调优。
基于这些要素和原则，我分享一些不成熟的见解，我们怎么构建 Native Cloud 呢？这里我做一个类比，因为新鲜的事物总是难以被接受的，一个比较好的方法和已有的事物做类比。大家对操作系统非常熟悉了，我们知道可以分成底层的硬件态、内核态和用户态，所以当我们去打造一个新的 Native Cloud
的时候，也希望可以从这三个维度去建立不同的联系。时间关系下面就其中具体一些点分享一下在字节跳动内部我们过去做了哪些相关工作。
首先提一下背景，既然要讲字节跳动内部最佳实践，我们先讲一下字节用到什么程度。如果字节内部没怎么用，讲出来也没有信服力，或者说我们的场景不一定适用于所有场景，所以先把我们的背景讲清楚。
字节跳动是非常深度的云原生用户，本身也是 CNCF 的白金会员。大家都知道，字节跳动旗下有非常多的 toC 的应用，所有这些 toC 的应用现在加起来已经达到了 19 亿月活，所以在这么大的流量，这个业务量背后，我们有非常庞大的云原生规模。比如说这些云原生内部的业务是运行在近万百台服务器节点上，包括我们现在微服务的数量已经超过了
8w，并且还以每个月 2000 左右的速度在不断新增。在任何时刻，我们同时运行的 Pod 数量有 750w 左右。这个口径很重要，大家知道容器的生命周期很短，但这个数据是我们任何一个时刻同时运行的 Pod 的数量。所以大家做一个简单的除法可以看出我们平均一个 Service 背后可能将近有 100 个 Pod
实例在做支持，同时我们的敏捷交付也支持每日超过一万多的迭代。我们单集群的规模上万，平均一个集群差不多 5000 节点，这个数据量也是以非常高的速度在增长。以上这些是背景信息。后面我讲最佳实践很多都是面向这种大规模、高性能、多业务形态的场景做的，可能对有的小伙伴比较适用，但是对有的场景可能不会适用。
还是回到刚才的 Native Cloud，我们说分了不同的层级，有内核态、有用户态。我们挑其中一些有意思的点来展开。
Native Cloud 之“云原生内核”：极致高效的基础设施
第一个跟大家分享一下我们所谓云原生的内核，如何通过云原生打造极致高效的基础设施，里面列了几个关键词。
第一关键词是全栈。回到大家刚才说云原生是什么，是不是容器，是不是 Kubernetes，或者说稍微广泛一点，是不是 PaaS。其实从我们的角度来讲，云原生渗透了从 IaaS 到 PaaS
全栈的能力：在硬件层和存储层面，通过云原生做到更加分布式、更加可扩展；在数据库一些中间件上通过云原生做到更好的存算分离；甚至在网络层面，通过智能网卡做到更多的硬件的卸载，去提升性能。
除了技术维度以外，云原生本身涉及到了安全和流程等其他运营方面。比如说在安全层面，通过云原生我们可以更多向左移或者向下移。向左移就是说安全我们不光是看运行态的安全，而是向左向前渗透到开发测试各个环节。向下移也是说云原生安全不光是容器层面、应用层面的安全，而是可以下渗透到网络，甚至包括到宿主机层面的安全，所以这是第一个关键词。
第二个关键词就是大规模。刚才我们已经分享了，对于字节跳动来讲，业务体量是非常海量的，第一点就是如何在海量的业务下，如何对这么多的碎片进行更加统一的配置，去控制相互之间的互访，提供高效却又稳定的运行时环境，以及这么多的研发团队和模块如何做到 DevOps 协同。这是我们要解决的一个问题。
我们也提到大的集群节点数已经上万，平均也有五千个节点，如何在这么大规模下去提升性能，比如说通过镜像的预热、预加载，以及刚才提到的云-边-网协同，如何在弱网环境下提供更好的边缘计算的能力，如何面向 AI 的业务提供 GPU 的能力，都是我们在内部最佳实践中去解决的问题。
最后一点是离在线混部。当我们达到这样大规模体量之后，整个系统的开销和成本会越来越多，从另外一个角度就是随着业务量的增长，如何能够在有限的资源下支持更多的业务也是很重要的难题。我们也积极探索了离线、在线混部，通过把在线的业务和离线的业务统一复用底层的计算、网络、存储资源，达到更高的资源利用率，这几个维度其实都是我们在整体云原生基础设施方面做的一些工作。这块跟大家分享一些具体的点。
比如刚才我们提到的如何做到更好的全局资源利用率的优化。大家都知道，企业的业务形态有在线业务和离线业务，对于不同的业务形态我们会提供不同的资源保障，有 besteffort，有 guaranteed
等。实践证明，要想达到一个足够好的资源利用率，一定是要利用离线业务进行削峰填谷。在线业务往往有比较明显的潮汐属性，白天可能负载很高，晚上负载就退了下来。如何在晚上在线业务消退的时候运行更多离线的任务，就是我们希望去解决的问题。
在字节跳动内部，我们通过超售策略、弹性收缩和混部控制来实现有效的离在线混部。最终我们全天全局的资源利用率可以超过 60%，这在业内是非常领先的水平。
具体我们怎么做呢？这块我们提炼了一个所谓的六步曲，如果做离在线混部，可能一开始大家觉得需要一个非常好的调度平台，也就是我们的第六步，其实在这个前面还有五个非常关键的步骤。
第一，就是我们要有一个更加准确、完善的监控指标体系。大家用过容器都知道，监控无非就两类，第一类是面向容器的，第二类是面向宿主机的。面向容器的往往我们可能用 cadvisor；面向宿主机的，我们可能会用 ganglia、atop 等工具。但是我们发现这些工具都有一些问题：比如 cadvisor 的数据源更多是从 cgroups
来的，atop 等工具可能更多是从 Linux、snatch proc 等暴露了一些内核指标来的。但是这些指标可能更多还是围绕 CPU 和内存，但是对于磁盘 I/O、网络带宽并没有很好的覆盖。哪怕是 CPU，当我们有多任务共享 CPU 的时候，它其实给出的指标也是不准确的。所以说第一步要打造一个更加可靠的监控指标体系。
在字节内部，我们研发了一个叫 Sysprobe 的监控工具，主要基于 eBPF 这样开放的工具，获得更多维度的，包括磁盘和网络相关的一些监控指标。有了好的监控指标，我们才能对当前的时局去做更好的判断。
第二就是业务分级。当我们做离在线混部的时候，一定要有资源的拆借，一定有 preemption，这时候我们就是挑软柿子捏，知道谁是硬柿子，谁是软柿子，也就是需要对业务进行分级。刚才提到了，一个非常粗的粒度就是把业务分成在线业务和离线业务，但这样还不够。比如说在线业务，又分成了有状态的应用和无状态的应用，甚至分为了基于微服务和基于
socket 的应用；甚至在有状态里面，又可以细分成是否需要本地的 LPV（local persistent volume），甚至包括需要 LPV 的时候到底是一个本地的硬盘，通过 LVM 管理，还是需要挂再一个 TEMFS？所以这些业务分类我们要做的非常细。
有了业务分类以后，我们还要对每个应用的特性做评估。性能评估可以做性能的摸底、压测、仿真，在字节跳动内部我们有 APIG 的工具，把生产的流量做镜像然后进行回放，对整个应用性能进行评估。
以及我们可以通过混沌工程随机注入故障，真实测试一个应用的韧性和稳定性。因为当我们做离在线混部的时候，一定会带来更多应用层面的 disruption，所以这些都是要提前做好的。
做好这些以后，我们要制定好资源管理机制，更多的是行政的机制，不同业务不同团队大家申请不同的 resource
quota，甚至为此承担一定的成本，并且为此设定合理的预期，这个预期包括整体的利用率、出让率以及离线业务的利用率等。有了这些以后，最后才是打造一个所谓的调度框架，在字节跳动内部，我们自研了一套离在线混部的框架叫 Godel（哥德尔），时间关系暂时先不展开。
除了离在线调度以外，我们刚才也提到了，其实今天面向 AI 类的应用，我们不光要能够调度 CPU，还要能够去调度 GPU。大家可想而知，其实在字节跳动这么多业务的背后有大量的 AI 应用和 GPU 的使用。从我们 GPU 卡的数量到我们任务的数量，可以看到其实也达到了非常高的资源利用率。这个资源利用率达成，不光是说我们可以做从任务到 GPU
的分配，或者分布式的调度策略，更多还要有很多自治的、能够动态调节的能力。比如能否根据实际的训练情况，动态的调整参与到 AI 训练的 GPU 实例；能否部分根据业务排队的时间，所需资源的情况动态调整业务所需要的优先级；包括支持一些高优任务插队等。所以这些是在整个调度体系里面，我们面向 GPU 这个视角所做相关的优化。
除了刚才讲到的很多大规模调度以外，我们这块再分享云原生的裸金属。这也是回应我刚才提到云原生不光是 PaaS，也可以做 IaaS，甚至可以深入到硬件层，通过智能网卡做更多硬件层面的卸载和计算，做到更多存储层面的存算分离，从而实现虚拟机的外表，物理机的心脏。
Native Cloud 之“开发态” – 多体验全栈敏捷构建
刚才我们讲了很多 Native Cloud 内核态，下面我们上升到 Native Cloud 用户态。这个用户更多是业务技术同学们，是软件研发人员，所以就需要从软件研发人员的生命周期拆解 Native Cloud
几个核心的要素。我们可以归纳为第一个是开发态，第二是交付态，第三就是运行态。所以我会从这几个状态，分享我们比较有意思的最佳实践。
当我们从 0 到 1 开发一个业务的时候，这里想强调一点，这个开发态面向的是多体验的全栈敏捷构建。什么叫多体验？今天我们写软件的时候，不光是一个后端的架构，不光是一个传统的 browser 的Web Appcation，它甚至是一个移动化的，H5、小程序、或者是低代码的，我们怎样去面向这样一种新的应用形态。
第二个就是全栈。因为我们不希望前端同学用一套技术框架，后端同学用另一套技术框架。一个公司内部有很多不同的 DevOps，很多不同的 CI/CD 流水线。所以我们希望达到全栈的效果。
再讲具体实践之前，为了佐证我的观点，再分享一个数据，或是一个论点，就是软件正在走向移动化。以字节跳动为例，我们内部已经有上百款不同的 APP，字节跳动本身也是在移动互联网时代成长起来的一家公司，目前字节跳动的研发人员达到了万人级别，其中专门开发前端应用的研发团队达到了数千人的规模，这是我们看到的一个非常明显的趋势。
面向这样一种新的移动化应用，我们内部有一个平台叫多体验开发平台，简称“Mars（火星）”，一个比较响亮的缩写。我相信今天这场大会也有不少人会提到 DevOps 或者 CI/CD，但是我们希望能够把这个概念再细化一下。通常我们提到 CI/CD 的时候，整个流水线的步骤划分粒度比较粗，最粗的就是有 Dev 和
Ops，再细一点的有开发、测试、集成、发布等等。但是再进一步细化的时候，我们能够拆成十个不同的步骤，就是这里列的，从设计到开发到调优等等。这里面我们真正去精细化拆开，再逐个击破。
比如设计阶段我们内部研发了一些工具，能够自动化把设计转成代码，基于设计师的设计稿可以自动转化成可执行的代码。除此以外在设计验收的时候，前端的小伙伴都知道有一套流程是设计的走查，有切身体会的同学大家都知道是非常痛苦的，设计师和开发人员进行海量反复的沟通。针对此环节我们也设计了一个自动化的工具，能够自动把设计师的设计图和最终产出的产品做对比，看哪一块不一致。
第二，在开发阶段，我们也知道今天的开发确实有非常多的框架和工具，仅仅是前端就有原生 APP 的一套开发工具，有 H5 的、有小程序的，有 Flutter，有非常多的环境，一个公司内部不同的研发人员可能有不同的技能，所以在开发阶段我们也提供一系列完整脚手架和一系列开发工具，让大家都能发挥出来。
开发完了之后就是调优，调优是从多个维度，包括性能调优、包体积的调优等方面帮助 APP 达到最优。在调优的过程中，我们也和其他的 APP 做横向的对比，包括在历史的版本期间做横向的对比。
之后是集成。刚才也提到了，字节跳动有上千人规模的前端研发团队，我们也说软件现在越来越微服务化，所以集成过程是非常复杂的，我们的策略是原则化，从应用的编译、模块的集成、到代码的扫描，构建成一个个可复用的“院子”，再通过复用这种流水线编排的能力，不同的业务团队可以根据自己的喜好定制自己集成的流程。
测试环节，我们除了可以做云真机，在全球有手机机房去做测试，包括功能性、非功能性的测试以外，还有很大一个挑战，就是我们有一百多款 APP，每个 APP 发布之前一定要进行很多回归测试。时间久了，一个 APP
的回归测试就是成百上千，再乘以数百个应用，如果每一次我们把这些测试案例回归都要全跑的话，哪怕我们有一个自动化测试平台，平台的性能也是跟不上的。所以我们又做了一个精准测试，能够根据本次发布中我们改的代码和模块去识别一些需要真正区别回归的测试，来加速整个测试的流程。
后面还有一个环节就是审核。大家过去在新闻上可能经常看到某些应用可能因为踩了政策的红线，或者有一些新的监管要求出来，导致应用不得不下架；或者在应用市场发布的时候审核没有通过。这对于很多前端开发小伙伴来讲是一件非常痛心的事情，因为 APP
的发布周期和流程非常长，要经历漫长的审核。所以在审核环节，我们会把市面上最新的市场和政府监管部门的政策拿下来，自动化转化成一系列规则，然后自动审查代码和应用，发现有不合规的地方，及时通知对应的产品和研发人员，从而避免发布了以后被退回或应用被下架。
审核之后就是发布、部署，时间关系可能就没办法详细展开，但是其中想提到很重要一点就是最后的动态化。还是我们刚才说的，一个移动 APP
的发布周期是非常的漫长的。首先要经过内部的开发集成，然后要在应用市场里经过人工审核，审核通过以后还要通过用户手动点击，这个应用才能最终被装上。如果每一次我们有更新的时候都要再经过这样的过程，流程可能从数周到数月不等。动态化能够让我们把应用模块化，对于其中的一些组件，可以通过热修复、插件化的方式不用重新走整套流程，完成局部功能的更新。
-
我们不光考虑到后端的开发，而是充分考虑到现代化应用、移动化的形态。
-
我们认为如果简单的进行 DevOps，粒度还不够细。所以我们将其拆分成十个非常精细的步骤并且做重点的逐个攻破。
这里举一个实践的案例。我相信在座不少用过字节跳动系列的产品，以今日头条为例，我们就是通过前面提到的这一系列的能力，进行敏捷的发布，并且进行整个应用的调优。对于前端的应用，公司都会很关注一个指标，就是投放转化比，前期投入最后转化来多少用户。这里面有非常多的因素，但其中一个非常技术的因素就是安装包的体积大小。谷歌在 2016
年做过一个统计调查，一个 APP 的安装包大小每增加 6MB，新增用户的转化率就会下降 1%。当一个应用安装包达到 100MB 的量级的时候，新增用户转化率会呈断崖式的下降。所以安装包的体积是非常关键的。除了影响转化以外，对于内部的软件工程和迭代也是很不利的。所以我们就对今日头条
APP 做了一系列的优化。比如根据功能拆分成 40 多个不同的模块，不同的模块采取不同的策略，核心模块还是要放在安装包里，但是一些增强功能可以采用启动后的静默加载，就是不影响下载和安装，只是在启动应用以后默默的把这些增强功能加进来，整个过程对用户体验是没有影响的。对于一些低频的功能甚至可以按需加载。通过一系列优化，我们把今日头条 APP 从 120MB 缩到了
10+MB。最后通过数据证明，也极大提升了用户的新增和转化率。
除此以外，再跟大家分享一下，我们刚才所说的十个步骤里头第一个步骤，开发。
过去开发大家就是撸起袖子写代码，啥也别说。但是今天随着 PaaS 技术的发展，我们进一步向上演化产生了所谓的 aPaaS（APP PaaS），或者低代码平台，可以通过一系列写更少代码甚至不写代码的方式，让业务人员更快速开发应用。听到这儿大家可能会比较害怕，说业务人员能写了，还要我干嘛？这个没有关系，我们做更多有价值、自动化的事情，我们的 Native
对于低代码来讲，很多人分为所谓的模型驱动和表单驱动，但我们其实分的更细。相信在座各位大家都了解软件开发里头一个比较经典的就是 MVC 的一个模式，有 View、Model 和
Controller，控制业务流程和逻辑。低代码平台也可以分成前端搭建型，更偏一些运行型的产品，是页面驱动的；以及前后台搭建型，这时候我们就需要模型驱动，去建立源数据引擎和流程引擎，能够对上层复杂的业务流程进行建模；第三就是数据搭建型，基于多维表格构建不同的低代码的产品。时间关系这块不展开了。
最后仅剩的一点时间，我抓紧跟大家分享一些重点。我们刚才讲了开发态，真正到了运行态的时候，我们做了哪一些优化呢？首先是在微服务层面。字节跳动的微服务有几个特点：
怎样解决这些数量爆炸、多语言、跨服务间管理的问题呢？我们是通过一整套体系化的方式支持端对端微服务。比如说从最底层提供可观测平台，中间提供一系列的治理平台，最上层去做一些技术间的创新，实现端对端微服务方案的管理。
这里面我们我们开源了一套面向 GO 语言的 RPC 和 HTTP 的框架，希望对大家有帮助。
在微服务治理层面，我们基于服务网格自研了一套微服务体系叫做 ByteMesh，可能从架构图上大家会感觉和标准的 Istio 差不多，通过 sidecar 无入侵的方式，通过控制面下发各种路由策略、安全策略等等。但在内部我们其实做了一系列的性能优化，比如说如何实现零拷贝的 proxy，这里详细介绍一下。传统的 sidecar 有两次拷备：把业务进程写到内核里，写到 Unix
Socket 里，读出来的时候，还要拷备一次。但我们通过共享 IPC，业务数据直接写到内核里，然后我们内核的同学又写了一个 TCP Socket 的 API，从内核里导出去，当然通过一些 Metadata 来实现这种能力。
其实本来我应该是今年的五六月份在北京站的时候跟大家分享这些话题，但是那会正好赶上北京疫情，我被隔离了，所以没有来得及分享。今天也是因为云原生这样一个话题把我们又重新联结在一起。所以回到开篇，云原生可能不是吃掉这个世界，反而是云原生在更好地重塑和连接这个世界。今天演讲就到这这里，感谢大家。
10 月 30 日，火山引擎开发者社区 Meetup 第六期邀请到了火山引擎 AI 中台的 5 位大咖，为大家介绍字节跳动在语音生成、语音合成、视觉技术、机器学习、机器翻译等热门场景的技术实践，带你走近字节跳动的 AI
技术！扫描下方二维码报名活动，点击【阅读原文】也可报名哦～
}
点击联系发帖人
