Techo Hub—云原生时代的高效开发实战（武汉站2021.07.27）原创

尊敬的各位来宾、先生们、女士们，大家下午好。欢迎各位来到我们腾讯云Taco HUB技术巡回武汉站的活动现场，我是今天下午的主持人，很荣幸能够作为主持人和大家一起参加今天下午的活动，分享与交流的活动。武汉光谷聚集着大量的高新技术产业，也曾经创下过无数的第一，在企业创业创新的同时，都需要利用云计算技术高效开发，从而快速抓住市场发展的机遇。在本次活动当中呢，我们将聚焦原云原生技术，从云原生微服务治理架构、服务治理中心到边缘云自制引擎，以及云原生时代的开发新思路和研发效能管理。

多位腾讯云技术专家将携手我们的英特尔和我们武汉当地的优秀技术大咖们一起共同带来我们云原生时代的高效开发实战的内容分享。在正式进入演讲环节之前呢友情提示大家三件事情，第一件事情为了方便大家能够更好的进行交流和学习，我们在现场活动当中呢为大家建立了我们的微信群，大家现在可以打开我们的微信，扫描一下我身后屏幕上面的二维码，大家在我们的活动当中或者是活动之后有任何问题都可以在我们的技术群里面进行现场的互动与交流，请大家可以扫描我们屏幕上面的官方二维码进行扫描进群。

第二个活动呢，在我们本次活动当中，我们给各位所有的大咖朋友们可以设置了云原生以来，快来补齐最佳实践路线图的小游戏，大家在签到的时候啊，每个人都有一张小贴纸，贴纸上面呢印有我们腾讯云原生最佳实践路线图其中的一小部分，大家可以看一下我们手上的这个小贴纸，大家的任务是什么呢？就是要寻找一下跟自己贴纸能够组成完整云原生路线图的小伙伴们，大家可以看一下自己手上的这个贴纸啊，组成小伙伴之后呢，在我们稍后的游戏环节当中，根据我们上面的贴纸，按照标号对号入座，并且完成我们的问卷调查。

的专属代码，并可以到我们工作人员处领取我们的专属奖品。注意，我们的奖品是在我们活动结束之后在我们工作人员手中领取。第三个呢，就是我们每一个嘉宾环节演讲过后就有五分钟的提问环节，当然提问给各路大咖的这样一个问题，希望我们现场的所有朋友们都能够踊跃提问，同时在我们今天提问的小伙伴们呢，也都可以在活动结束之后，在我们工作人员手中领取一份专属奖品，希望我们现场的小伙伴们在稍后的互动环节当中都能够踊跃提问。和我们的讲师都能够多多沟通，接下来呢，就进入到我们本次活动的主题分享环节，首先让我们掌声有请我们腾讯云中间件高级工程师彭子龙老师带来我们的主题分享，为大家带来云原生微服务治理架构的深度解读，大家掌声欢迎一下，OK，大家下午好啊。

然后能够在周末时间来参加我们的take哈，想必大家也是武汉互联网未来的中流砥柱。OK，言归正传，然后呃，我叫童子龙，然后是来自腾讯中心建的微服中心的。然后今天演讲的主题呢，是云原生微服治理架构的深度解读和实践。呃，为什么要讲分享这个主题呢？就是呃基本上现在国内大部分就是公司属于是业务驱动型公司，对吧？然后呢，业务驱动型公司微服务呢，仍然是一个构建一个呃业务系统的一个主流的一个基础站。然后微服务治理呢，也是我们非常非常重要，也是非常现在就是很多很显显眼的一个一个一个主题，然后我们呃，我们微服务中心呢，也是呃，在经过了五年的一个平台的演进，我们对微服务整个自己的一些理念，也是在原生整个浪潮里面，也是不断的进行一个迭代，认知的一个迭代，我们对我们平台总结理念的一个一个迭代，然后就有了我们现在我们每次分对对外分享的话，就是也是说出我们现在对整个微服务治理一个一个最新的一些思考。

OK，然后先简单做一个自我介绍，然后我是呃中国2020原是微服峰会的一个演讲嘉宾，也是EQ全球佳木式峰会的一个演讲嘉宾，也是呃那克开源社区的一个一个成员，然后也是腾讯云呃TV服务平台的一个核心的一个研发。呃，今天呢，演讲主要是从四个方面去切入，那第一个就是我们原生微服务架构的一个思考。

第二个呢，就是我们腾讯云微服治理框架的一个深度的一个解读，呃，第三个是我们整个原生微服的一个治理的一个实践。呃，最后一个呢，就是我们呃的一个演进方向，跟我们后续的一些计划啊，这是一个一个实践性的一个分享，就是不会去呃讲太多一些理论性的东西，然后也会去剥离一些厂商的一些概念，就是一个很开放性的一个一个技术的一个论坛。OK，第一个就是我们云原生微服的一个架构的一个思考。那我们整个呃，微服务构建过程中需要关注的一些点呢？一个第一个就是我们一个分布式，比如说我们容器跟微服务的一个一个理念，还有一个就是我们面向配置，就是分布式的一个配置，第三个就是一个高sa，低开销，高性的一个高可用，还有一个就是可观测性，我们整个集群的一个日志，还有MAS，还有我们整个链路open的一些一些追踪，其次就是一个安全，一个访问授信，比如说我们一个get getway端端的一个加密，然后这也是我们在构建整个呃，构建整个我们治理架构上面也要遵循的这样的一个理念。

OK，你其实接下来就是我们讲一下我们整个微服务治理过程中面临的一些挑战。那我们作为一个云厂商，就是我们要做微服治理这这样一件事情，然后我们服务的是一些To B的业务，然后To B的这些业务呢，他们可能在框架上面非常的种类非常繁多，包括他们有有double协议，或者说有有呃cloud协议，或者他们有一些字研的一些协议，那么这些人呢，都是我们云场上的一些客户，所以说呢，我们要去兼容这样一个协议的一个多样性，我们在整个智理的一个层面，可能要抽象一个更高的层面去适配所有的一个RPC的一个协议。这是我们面临的一个挑战，还有就是我们整个微服务语言的一个多样性，比如说现在构语言的崛起，然后可能会有一些公司会用构语言去构，构建这样一个微服务的一个业务架构，那我们也要去做这样的一个一个兼容。

其次就是我们整个语言寻规服务能力，一个耦合一个业务，比如说我们奈飞原始的那一套能力，对吧，他都是通过STK这种方式，就是会有一定的业务的一个耦合性，比如说如果代码耦合业务的话，这个升级是十分困难的，对吧，就是我们可能在整个改造升级的过程付出的成本也会很大。还有就是我们整个微服拆分，然后一个丰富的一个中文建的一个生态，比如说网关，还有包括呃，森森na，然后还有呃注册中心，这样的注册中心也繁复多样，比如说cons NAS，然后还有娱乐卡，然后我们微服治理呢，就需要站在一个全局的一个角度，那比如说我们每个中建可能是解决一个点的问题，那我们整个微负这里呢，可能是要解决一个整个一个面的问题，它的整个抽象程度可能会要更高一点。他整个站的角度也会更高一点，所以他对整个微服务呃的理解啊，包括整个对微服务全局的技术站的一些了解，可能会要要求会更高一点。

那么这是我们整个微服治理的一个趋势，就是我们做任何事情都是当从我们当前遇到的一些问题出发的，对吧？我们追求任何一个技术，不是因为它的一个先进性，而是因为它恰好解决了我们当前面临的一些问题。那么我们当前就是比如说我们有一个多语言多协议的适配，然后我们还有一个就是我们核心治理能力的一个标准化可扩展，那核心治理能力的标准化是也是会是为了契合我们，比如说我们后面呃整个呃治理的一个多wrong time形式，比如说我们会把我们整个治理能力呢，进行一个一个标准化啊举个例子，比如说我们注册对吧，我们在这个注册场景的话，其实就是这个包括我们整个心跳的一个抽象。那我们把这个抽象抽象出来之后呢，比如说我们去对接其他的一些云长的，比如说我们对接na，对吧，我们把它NAS，或者说把cons的这些这些能力，把它植入到我们的整个抽象里面去，那么就会帮用户完成整个自整个服务发现的一个过程。

那如何做到可扩展，可扩展就是为了能够就是支持更多的一些架构的一些场景，比如说我们一些自研架构，可能有些公司会自研一些自己的东西，或者说就是能够适配更多是中建的一个生态，其实就是我们整个自己能力的一个下沉，包括全面兼容开源，那自己能力下沉的意义就是说我们的整个。就说我们在整个业务升级的过程中会更得更加的顺滑，比如说我们呃，比如说我们呃，呃，就是治理能力加新加了一些功能，比如说呃，比如说我们就通过A技的方式的话，我们可以实现这种就是不展不不更改我们任何业务代码情况下，实现我们整个治理能力的一个升级，就是能够结结我们的业务代码，其实就是我们的一个C的一个一个理念，就是run everywhere，就是我们所有的治理能力能够在任何的框架，任何的语言下面都能够运行，那这个是我们整个治理的一个趋势。

OK，来讲一下我们整个呃，整个腾讯微服务治理平台一个架构的一个设计，然后我们整个治理的一个核心引擎呢，也是分为了三层，那第一层就是我们核心治理层，然后核心治理层呢，就是我们把我们每个呃微服的一些能力，底层的一些能力呢，去把它全部抽象出来，一个个点，比如说发现啊，限流啊，熔断啊，降级，然后其实就是那我们整这就这个呢，就是这个核心治理层呢，就是我们整个腾讯微博平台对微服务的一些必要组件的一些理解，把它聚合在一起，这是我们的一个能力的一个取证。就是我们觉得我就是在我们理解上面，微服一个完整的微服GT平台需要具备这样的一个能力矩阵。OK，其次就是我们的一个平台适配层，平台适配层的作用呢，就是把我们整个核心治理层的这些能力呢，进行一个组装，去适配我们不同的一个平台，比如说我们有腾讯的一个，呃，腾讯的语音平台，公有云平台，还有私有云平台，包括我们现在一个自研平台，还有我们即将的一个开源平台，还有就是我们最上面的是一个协议的一个适配层，那我们要把我们这些治理能力呢，要植入到我们的这个协议，整个整个维护协议里面去，那维护协议可能有多种多样，对吧，那我们在整个植抽，在植入的过程中呢，也是做了一层高高。

层次的一个抽象就是大家都知道smash对吧，Smash他在去接入这些。这些治理能力的时候呢，他们嗯，是通过那种。通通过那种网络拦截，透明拦截的那种方式，就是它在网络的出口跟入口做了一层网络一个拦截，然后我们整个治理的RPGRPG那种植入呢，也是参照这种方式去做，就是我们能够很方便的把我们整个一个智能能力轻松的植入到任何的一个协议框架，那这样有个好处，就是我们在整个一个一套平台上面，然后实现了我们所有协议的一个一个治理，就说你能在我们的这个平台上面看到double的一个一个一个服务，也能看到s cloud服务，也能看到TRPC的服务，在一个平台上面实现了一个治理，一个总的一个服务治理平台。

OK，为什么需要分层设计？之前也是说过，就是我们要做一个东西的话，肯定是要去思考我们现在面临哪些问题，之前可能也谈到过一些，比如说我们框架协议的不统一，包括我们对扩展性跟易用性的一些一些考量。呃，扩展性呢，其实就是说我们我们扩展性现在能做到什么程度呢？就是说我们所有的治理能力，比如说举个例子，比如说我们的治，比如说我们的一个熔断的一个能力，对吧？熔断能力可能现在的厂商组建比较多，比如说有re for，然后比如说有老之前老奈飞的那个ris，还有A这种，它都有这种熔断竞能力。那我们要做的扩展性，呃，第一步就是我们把整个熔断的那一层逻辑封装成一个通用的一个接口，然后我们做成插件可插拔的方式，比如说我们把A的能力把它植入进来的话，我们实现一个A的一个插件就OK了，然后比如说我们要把阶的熔断能力给植入进来，我们就实现这样的一个一个插件，包括我们可能会自己自研一些熔断的一些能力，对吧，我们也可以通过这种插件的方式把它增强它的扩展性，然后植入到我们整个平台里面去。

所以实话它扩展性是做的非常的好的，其实就是我们整个微服中文建的一个一个多样性，就是我们微服中文建真的很多，就是我们要去全面的去介绍开言，像阿波罗啊，像拉S这种，还有就是我们整个平台的一个多样性，就是我们后面的平台也会很多，比如说我们有自己的平台，有开源的平台，很多平台我们都要去兼容这样的一个能力。这是我们为什么要做分层设计的一个一个原因。OK，那就第一层就是我们的一个核心的这个治理层，核心的治理层包括哪些东西呢？就是一个是我们的一个规则引擎，就是治理的一个规则引擎，其次呢，就是我们整个治理能力的一个标准化，还有一个就是我们全全在核心的自己层里面全用，全面兼容了所有开源的一些组件。

还有就是我们整个呃能力的一个口展，就是我们整个一个插件的插件池的一个机制。然后就是我们的平台适配层，就是我们的一个具体的一个spi扩展，还有就是我们适配多样的一个平台。然后然后最下层往最上层，就是我们的层，就是我们的一个插装层，那我们整个三层设计的话，是越往上层是越来越轻薄的，就是我们要要更更改代码量是越来越少。也是比较比较清晰的一个一个设计分子的一个思路，OK，比如列举一下，比如说我们从呃列举一些主流的一些协议是如何的去插装的，然后这是我们整个double的一个的一个流程，比如说整个double协议，它是从root，然后到我们nots，然后然后到filter，我们在每一层里面也是去植入我们的这个能力，嗯。

然后整这个是我们整个spring cloud的一个请求的一个流程，也是举了一个例子，从land到到我们最后的一个路由规则的一个，就是我们整个插装的一些方法的一些一些类，也是列举了一下。OK，就是第一个就是基于我们基于一个标签，基于标签的一个恢复务治理，那我们整个标签呢，也是我们对consumer跟我们provide呢，也是去去打了一些一些业务标签跟一些系统标签，比如说一些可用区，还有包括我们比如说一些它所在的一些部署组之类的一些信息，然后我们把它部署到把它写到我们的这个实例里面去，然后我们每个服务呢，每个服务它有很多实例，对吧，然后我们给每个实例打上不同的这种这种tag，这种tag之后把它注册到这册中心上面去，那比如说那S的话，我们是打到ma data里面去的，像cons索，可能它又会有些T，也是把它放到Meta里面，也是OK的。

然后我们在consumer里面在请求的时候呢，也有一个RPC的一个con r PC content里面也会带有一些tag。那比如说这个请求是从哪个可用区过来的，比如说是从上海可用区过来的，或者说这个请求的用户名叫张三，对吧。OK，呃。科过嘛，然后这个是我们整个服务治理健全的一个流程，就是我们在SDK去请求，Consumer去请求的时候，去根据我们rpc con里面的一些一些一些数据，比如说呃，我们有一个规则引擎，就是比如说来自来自上海可用区的可能可能不不允许访问，然后这样的话，我们在在provide的那个SK或者里面去做一个engine的一个匹配，然后会把这一系列请求给去掉。然后服务路由，服务路由我们也是分为路由的一个出站路由跟流量一个入站路由，还有一个一个同地域的一个优先路由的一个一个配置，也这个也是做在那个规则一起里面，我们分为流量的一个来源和流量一个目的地。

OK，然后多区域的负载的亲和性的一个负载呢，这个也比较简单，就是我们在给服务打标签的时候呢，会给打上一个可用区的一个标较签，我们在整个路由的时候呢，也是优先去选择我们呃同地区的一个服务实例就是一个路由。还有就是我们一个服务的一个限流，那服务限流我们身为标签限流跟全局限流，然后我们也是做了一些很多一些限流算法，比如说漏图算法，然后还有还有逆排统算法，然后去适配不同的一些业务场景，那比如说秒杀这种场景，对吧，可能会更适合这种活动窗口算法，那比如说我们后面接的是一些呃数据，数据层的一些访问，我们需要流量比较平整，那么我们可能会去选用漏斗这种算法，这种算法也是可以动态的去切切换的。然后我们整个算法里面的一些阈值也是可以动态进行一个调整的，包括我们还做了一个直行限流，其实直行限流相对于单机限流唯一的区别就是token放在哪里，对吧？单机限流的token是放在呃实例本本地的，它不具有，它不具有分布式的特性，那我们把这个我们整个token放在一个集中的一个地方进行管理，那就是我们的一个基行限流，你像S这种方式，就是用token serve的方式，然后他他把to，他把那个token，他把应用，他把那个整个to s嵌入到应用里面去，用应用选出一个to s去存放他的一个token，这种访问的这种就是流量，流量可能会都会经过一个应用，一个应用服务，这样对整个应用的稳定性是一个比较大的一个挑战。

然后我们整个规则配置呢，也是通过我们压测进行一个进行配置的，就是你们要对自己的一个接口进行一个容量的一个评估。OK，这是一个服务的降级，服务降级也是后面是这边是微软的一个工业级的一个一个流程图，也是我们也是基于这个去做的一个触发条件呢，包括一些请求的失败率，还有我们一个慢请求率，包括我们熔断比例的一个一个保护，就是说比如说熔断比例达到一定阈值的话，我们是不会再进行触发一个新的熔断。

一个close跟open的一个一个一个理念。还有一个就是我们一个资源隔离，那资源隔离呢，就是我们在整个，比如说特别是在网关的场景，就是你网关下面可可能会接了很多的一个微服务，那么我们希望每个微服务之间的资源是独立的，就是你服务A的，比如说他后面的数据库挂掉了，我们不希望它会影响他服务B，所以说我们想对他整个使用的个资源进行隔离，那比如说我们主要有主流流有有信号量的方式跟线程值的方式，那信号量的多种方式呢，就是我们请求进入的那个流程，跟我们请求分发出去的那个线程是同一个线程，那那深成使这种方式呢，它是不同的线程，所以说它这里有一个问题，就是说它分发出去这种线程，它是会丢失在原始请求线程里面的一些线程的一个本地变量的。

还有一个就是我们的一个无损发布，就是我们在整个发布的过程中呢，就是需要就是我们这里就是服务调用有个异常时区，大家可以看一下，就是我们整个进程关闭，然后到这后中心感知下线，这里有一定的延时性，还有一个就是我们客户端感知下线，客户端感知下线之后呢，就是呃，比如说我们road balance有个机制，就是我们会每隔30秒去获取一个服务列表，然后更新到本地缓存，其实所以说它在中键延迟到日本延迟，这中间呢，它的实例他的实力已经关闭了，但是。但是consumer并不知道他已经下线了，所以说他还是会把新的流量扔给他，这时候他的所有的流量都是会被，都是会出错的，都是会调用异常的，然后我们怎么去解决这个问题呢？就是我们在他下线的时候，会激发会触发一个下线的一个反注射p of事件。这时候呢，我制作中心会去主动通通知可去更新这个缓存，那么我们就消弭的整个制作心感知到我们整个呃，Road balance里面30秒的那一个延时里面，就是他会很实时的感觉到provide的一个下线，然后去选择一个可用的一个实例。

能做到我们这样真正的一个无无损发布，然后然后全天路灰度，全天灰度微商引用这个理念，就是我们每个生产人员就是肯定要有一个精卫生产，对不对，我们那我们希望我们在发布应用的过程中呢，就是把生产商的损失尽量的降低到最小。降低到最小之后呢，就是我们会把一些新的流量，就会把我们一个新的服务呢，去做一个流量的一个分拨，我们把尽尽可能少的一部分流量定时的去分拨到我们的一个新的一个集群，然后做到一个全链路的一个灰度发布。OK，这是我们整个agent的跟我们agent的一个一个一个原理，就是agent的lo跟agent的touch，这是呃agent的一个原理，就是我们在创建ation的时候，每个虚拟机都有自己的实践，比如说呃GM有host的一个实践，是这样的，就是通过监听一个class事件去改我们的字间码，这也是我们在呃治理时，治理过程中呢，就是一个很重要的，就这中间治理下沉的一个很重要的一个技术事件，就是加Java的去做。

那Java a警就是我们以通过一个杠杠AG的命令的话，就可把我们所有的一些能力植入到业务应用上面，业务应用它是无感知的，能够接入我们这些能力的。啊这啊右边呢，就是这三个呢，就是我们目前腾讯云的一个治理的一个一个两个形态，一个是SDK形态，一个就是我们service match的形态，那service match也是通过那我们整个去控下发规则，然后到我们整个数据平面去做一个流量的一个IP table的一个透明拦截。呃，这是两个技术站之间的一个一个对比，两个都能做到一个下沉式的一个治理，那么就是，呃，Java镜的优点可能就是它是Java j vm原生的一个技术体系，它性能可能比较好，呃，接入成本也比较低，它的缺点就是它会启动一个延，延长的一个延长启动的一个时间，因为它启动的时候需要去加载通，通过额外的class load去load，呃，就是应用之外的一些Java文件，而且它是无法跨语言的，然后smash很大的一个优点就是跨语言。

还有就是他，但是他呃是一个独立的container嘛，所以说他在整个问题追踪的过程中可能会比较困难。啊，后续的一些计划就是我们，呃，现在也是准备把我们整个一套，呃整个一套就是治理的这个平台能够能够开源出去，然后希望也是能够给业界去输出一些我们对整个微服自己的一些理解，也是希望大家能够一起去去共建这样的一个一个平台。OK，我现在的今天的分享就到这里，然后呃，因为时间已所以说呃，大家有什么问题的话，可以可以可以相互讨论一下，好，我们童子龙老师的分享到此结束，那么接下来的环节呢，就是到了我们现场的各位朋友们向我们老师进行提问的环节，同时呢，每一位提问的小伙伴们在稍后活动结束之后，都可以在我们工作人员手中领取一份专属奖品，接下来请各位朋友们踊跃提问，举手发言。

你好，喂，你好，诶我我想问的问题就是腾讯在使用servicesh的时候，安全这块是怎么考虑的，比如像证书啊，像K啊是怎么保护的，哦，这个我还不太清楚，因为这个生活标是另外一个团队在做的。我主要是负责K的这块。没事，就是下面可以，呃，我可以去跟对对，OK，大家可以扫描这这个好，我想问一下你们这个能不能实现全局用户使用数据的简易检索以及分类以及简单分析功能，呃，全局数据的用户在我的这个上面用的各种时间段什么东西的这些东西的检索分析这种功能能不能实现，呃什么这个跟这里有关系吗？

有没有这方面的，就是插件或接口，呃，没有，我们我们只是做微服的治理这块，你说的那些，呃，全局数据的这些检索，所以这个好像不是一个领域的吧，嗯，不好意思啊，我们以前公司做的项目有很多是涉及到保密机构，也就是要求离线部署的，嗯，你们现在做的这套东西，如果客户有需求，就部分数据进行部分数据啊，需要放在本地，你们有什么好的方式，就是进行云端和本地的互联互通。而且还要保证数据的安全性。呃，数据本地部署，然后数据存在本地。对，部分数据是必须在本，然后还要支持类似APP的远程访问，这一类就部分数据它会在本地，然后外部可能也会有高并发的要求。

嗯，我们不是我我想想你们这个场景跟我们这个领域好像也没有什么关系吧。嗯。嗯。有没有工具，嗯，是这样的，就是呃，看你们用的协议是什么样子，比如说你们是用的spring cloud，阿里巴巴的原来协议就是你们在其实整个spring cloud基础站是相互相通的，对吧？就说你们其实整个迁移需不需要工具，就是迁移过程中其实最主要的是你设计的一些底层这些基础设施，那比如说你们用到的技中心这种东西，比如说或者用到了从阿里云要迁到腾讯云，对吧？因为整个网络要是要互通嘛，对吧，其实这才是一个一个一个很重要的一个东西，那么我们迁移肯定是有这样这样这些工具的嘛，就说你要做到平滑迁移，平滑就是不可能放一把迁过来，对吧，就是对你们企业来讲可能风险会比较大，那做到平滑经营，就是可能说你们在会会同时在多云的场景上都会要形成这种整个网络一个互通，对吧，就是你们服务可能既在阿里云也要在腾讯云上面，但是要要做到一个腾服务的一个互访，对吧？但是你刚讲的就是在代码层面，比如说你们整个呃，阿里云那边。

死密要迁到腾讯这边，死密在技术上面是没有任何问题的，就是你们只需要去关注底层基础设施也行，比如说rock MQ，然后切到我们这边，呃，C卡不卡，或者说TDMQ这种就是把这个问题解决，就是数据迁移，包括底层的一些中要键迁移，这才是整个迁移过程中需要关注的一些点。

OK，嗯。啊。哦，开源出来的。呃，O，当然o course就是源的东西，肯定是要经过二次，就是开的东西，是需要企业有一定的维护能力的，需要你们自己去去二次改造，或者去契合你们真正的一个一个支术战，对吧？OOKOK，你刚刚提到的告警，其实可能可观测这一块我忘记讲，因为时间的问题，那可观测的这一块我们是目前是怎么做的，我们我们整个维护平台想做的就是治理一套营院是的一套标准，那我们也是，那那我们可观测这一块业界统一的标准的话，应该目前只有openary对吧？那我们也是基于这个去做的，那open也是基于open case跟谷Google的那个open s去进行一个整合，就那他只负责SDK的一个日志的一个规范，比如说open tra这样规范，包括日志的一个采集，那采集之后呢，他具体要输要输出到哪些big hand备，就是他输出到哪些后端，比如他输输出到sky working对吧，比如说输到一个压狗，这个是这个是用户自己去做。

决色的一个事情，就是我们整个微服平台是支持你这样去做的，就是你因为只要你后面的那个那个所有端符合open这样的一个协议的话，你是任何任何一个后端都可以获取我这个日志，然后进行一个链度，一个展示的，对吧。然后你刚刚讲的就是so match这块，So我觉得agent Java agent这块的的那个可观测性应该是会比S会更全面，更更好，因为它本身就是更切合原生的一个技术生态的，对吧。然后呃，对，因为呃A进的，因为像采集这种东西，它是无关业务的嘛，所以说A进这种技术，其实在探针技术，它在日志采集这方面也是比较广泛的，像sky working对吧，它都是包括阿里的arms对吧，包括我们的一个TSW啊，当然我们的腾讯云监控都是基于这样的一个技术去做的，就是用户无感知的方式去进行一个自解码的一个代理的一个改写。

OK，好，由于时间问题呢，我们童子龙老师的分享和提问暂时告一段落，那么接下来如果现场还有小伙伴们有任何问题的话，可以私下跟我们童老师进行沟通，那么感谢童老师的分享啊，请您可以入席就座了，谢谢掌声鼓励一下，谢谢好，接下来让我们掌声有请我们英特尔边缘云系统架构师杨斌老师为我们带来边缘云自制引擎的主题分享，有请杨杨老师大家掌声欢迎一下，谢谢啊，谢谢大家啊，我是来自英特尔物联网边缘云团队的，呃，杨斌。

啊，我今天跟大家介绍的是边缘云的自制引擎，首先呢，就是说呃，大家听到英特尔的话，可能大家印象里面想的是呃，芯片，CPU，服务器，那我们做边缘营，那跟我们的兄弟，呃腾讯做边缘有什么不一样，那我们做编译营呢，其实很多会，呃更关注一些底层的优化和发挥它的硬件能力，比如说让你买一个服务器，能跑出两个服务器的那个能力，计算力出来。然后我相信呃，我今天准备12呢，其实比较简单，我想就是说因为底下在座的都是业界的呃大拿，我们是来做一些呃思想上的碰撞，而不是说我来分享我的一些想法，我希望听到大家一些反馈，然后呢，我会提到一些呃我们做的一些项目，我们做的一些优化一些呃发挥一些哪些硬件性能能力，然后各位如果有一些想法的话，我想呃最好能留多点时间，我们有一些讨论互动，好吧。

就是首先第一个的话，呃，大家可以看到，就是说在边缘云上面一个部署的一个问题，呃，在左边大家可能看到，呃，比如说我们去在PC上装一个乌邦图啊，那么非常简单，把一个USB插进去，一路的next，这一个看装大道直通过我们的啊目标就把一个乌棒头装起来了。那我们可以看到，如果我们要去部署一个集群的话，那我们会啊，碰到很多的困难，首先第一个我们还是要去装一个呃，Linux的一个系统啊，不管是无帮图也好，Santos也好，或者第一遍其他都行，然后我们可能会在上面去部署etcd，去部署K8S，那怎么样去部署一个etcd和K8S，因为它是一个分布式的系统，我们可能一开始准准备好很多的机器，那这些机器该怎么连接，他们的硬件资源该怎么分配，它的网络该怎么样去连接才是最优化的，那你要买几块硬盘怎么，比如说你要买几块SSD几块啊普通的机械硬盘怎么组合它才能让这个呃网络和你的storage发出发挥出最大的性能和最优化我们的成本，像这些呢，是在部署阶段就有很多需要去考虑的，那。

当你把贴8S部署好以后呢，你可能再继续往上面，像我刚才提到的，像网络csi，呃，那我们可能需要部署一些网络的一些service，比如像这里提到的C，那C怎么去部署，怎么去配置，呃，这个可能一个我我我我们根据我们经验一个，呃，一个全新的工程师如果没有做过这个，那他可能花几个星期才能把这个S给摸索出来，怎么去部署。

然后像CI我们会有开有F诺，像现在比较流行还有Co o vn，像很多很多其他的网络，还有包括把这些组合起来一起用，像有些masters，怎么样把几个CNCCI的呃组合起来用，那么一个服务器上它可能有很多个网卡，每个网卡它有不同的呃功能，比如说有一些是OM去做一些呃运维工作的，有一些是做一些呃cost，那那个网络就是说K8之间的一个集群之间的一个通讯，还有一些是做storage的，那么这些网络他们能不能共用一些网卡，或者说你为了优化它的performance啊，利用不同的呃，比如说有一些万兆网卡，做storage的，也是千兆网卡，可能就做OM的，像这些话也要去提前去设计，去优化这些方案，那么当你这些硬件的网络的拓。

都不确定下来的时候，那你再去部署这个CI，去优化这个网络的时候，那这个呢，也是需要很复杂一些砍的，包括怎么样去呃部署和优化好，等你把storage和network都做好以后呢，我们可能还需要一些监控的软件，像修啊，还需要有一些dashboard的UI的工具，比如像现在比较流行的na，或者像K8的dashboard，当然还有很多很多其他的，像更上一层的一些service service match的，还有一些微服务，像我们自己的一些workload，就是我们自己的一些跑的一些应用，那么所有所有这些在部署一个集群的时候，它往往整个过程当中都布满了一些陷阱，一些让你呃变成一些负优化的一些陷阱。

那么我们怎么样能够像部署一安装一个单机一样去部署一个集群，这就是我们碰到一个最大的挑战，我们希望呢，嗯，就像我们当年，呃，Windows和英特尔合作一样的，能够让一个普通的一个大学生没有学学过专业知识就能把一个window装起来，用起来，那我们能不能在边缘云上面能不能做到这一点，那一个啊，没有一个专业训练过的一个大学生就能够把一个集群给部署起来，而且能够，呃，让他的performance能够达到一个比较好的一个结果。啊，这里还有我我这边看到一个另外一个圈，就是说啊，怎么样去管理这个集群，这里举一个很简单的例子，比如说我们要在一个PC上插入一个新的设备用它，那非常简单，就比如像我们的USB，你插上去，那我们一个呃主播就可以开始做直播了，那我相信这个主播可能对呃，USB协议，USB driver以及摄像头的这些port，一些APP，它可能没有任何的专业知识，但他却能很方便的用起来，那如果我们在集群里面想加入一个新的节点。

那这件事情就不是那么的简单了，就是说首先你这个机器码来开箱的时候，它并不是一个开箱即用的，它需要你去装OS，装很多的package，像Co的一些package，像一些，呃，比如说像con的package，像这些package你都要装起来，然后要把它网络配起来，比如说你你的docker从哪里拉image，像这些你都得要配起来。

然后呢，有很多很多的，呃，那个证书你要需要去配置，因为为了安全，为了去加入到你的集群，你需要把集群里面相关的证书要下载进去，要配置起来，好，那除了这个以外还要呃，可能你需要用户名密码，你需要很多很多的command在CRL上输入，然后最后才能把这个一个新的节点装好系统加入到集群里面去，这个的话，在中间的话是呃涉及了很多的专业的呃知识，而且呢，这个中间过程并不是那么简单，而很容易犯错，那犯错以后，那只能去找一些专业人士去帮忙，所以这个事情呢，就不是变得那么简单的，比如说我想买台机器来，我就想把它加入到我集群里面去，增加的我一个算力，或增加我整个集群的一个storage的资源，那这个呢，你怎么样能够让他做到，就像我们的USB一样做到。

即插即用，能够方便我们的呃运维人员去扩展他的网络，去呃让他的扩展他的集群，那集就动态扩展他集群的一些资源。啊，这里呢，是我们一个，呃，我们一个愿景吧，就是说我目前自己还没有完全做到，但是我们正朝这个方向去努力，就是说呃，首先。我们会有一个edge啊，一个自制的一个引擎，然后它会跑到的host，可能大家在座应该都知道，就是说我们在呃搭设一个集群之前，就是说我们有的第一天去部署，呃部署这个集群，那么我们有的az的host呢，就是说相当于说在这个机器上面去装一个普通的Linux系统，然后再装我们这个，呃做装一些那个我们集群部署的需要的一些，呃相当于说一个引擎，然后帮我们去部署这个集群，呃这个对于这种耗呢，它需要网络跟我们的这个集群的网络是相通的哈，大家可以看到这里面的第一步就是说我们的机器马达服务器来了，那有可能买来的当天不是一台，而是十台100台，那把这些机器开箱以后呢，我们接上网络，把网络都接好。

然后再把电源点起来，那我们这边有个Del的host，它上面装了个engine以后呢，它就会比如说第一步它通自动去帮你装这个OS，装这个呃，比如装乌邦图，装这些系统，那他呢是通过呃，比如说是通过那个呃BMC去装，或者说通过我们的呃像扣系列的CPU话，可能就通过AMT去装，或者你什么都没有，你自己按个power button那八是从P叉一启动就通过P叉去安装，就是说它相当于提供了一个自动安装操作系统和相关，呃呃有一些需呃依赖关系的这些软件包啊等第一步装完以后呢，呃，我们在这个系统里面会自带一个A，它的作用就是在第二步它可以去发现你这个硬件的能力，比如说你这个硬件有几张网卡，你每个网卡是，呃，性能怎么样，比如你。

有一张万兆网卡，有一张千兆网卡，那他可能会呃在后续优化里面，帮你把一些对网络要求比较高的一些应用呢，能够让你发挥这个万兆网卡的功能啊，然后呢，它还有一个就是load，这个determination，就是说呃去自动的去呃帮你配置这个节点的一个角色，比如说呃举个例子，它是作为一个c master呢，还是一个workno呢，还是说呃他还能够承担一些storage的一些呃能力，就根据他判断他的硬件的能力来去帮你自动去detect它的一个角色啊。然后在第三步的话，就是一个on board on board就说如果你没有集群，它就帮你把这个集群创建出来，当然你一开始可能要同时接很多台机器，那如果有一个新的机器，你的机群已经有了，你想扩展机群的能力，那就像我们刚才提到一样。

一个USB设备，它是即插即用的，那我们在这里是不是也可以做到即插即用，就是说你把一个新的机器拿来了，把它接入到你的集群的网络里面去，那他就能够接完以后啊，放在那里啊，过个十分钟，他可能就自自动加入到这个集群，然后承担他该承担那个角色。所以这里面呢，有几个关键的点，就是说第一个我们会有一个the的hosts去跑我们这个engine的这个，呃，Software能够去帮忙做这个集群的一个部署和一个新节点接入的管理啊，然后第二个是说能够自动的去安装这个操作系统，通过BMC啊，MT或者P去自动安装，然后它的节点的呃，硬件的capability是能够自动被发现，然后它的漏是能够自动被确定好，然后所有后续的一些pro能够去自动的去完成。

其中呢，有一些的是能够帮你做一些优化，比如说我刚才讲到的啊，你的机器上比如说有两个网卡，一个是万兆的，一个是千兆的，那在你连接网络连接，呃，就是说没有错误情况下面，就你把它就能够自动detect出来，然后呢，能够把你的万兆网卡，比如说让你的network用这个万兆网卡，这样能够优化你的storage。

啊，然后它会提供一个they conflict的一个能力，就是说它相当于说所有的default conflict，它虽然不是最优的，但它也是基本上经过优化的，能够让整个系统能够很正常工作，就像你装一个呃Windows系统，呃，如果是一个呃初初级用户，他可能就一个C盘把所有东西都装上去，但他确实能跑，而且基本的普式基本功能也没有任何问题，能正常用，那我们这里的只要卡菲的，就是说比如像CF，我们可能那种呃很极致的优化可能做不到，但比如说他能够把你的SSD配置成我们的日志系作为日志来用，那机械硬盘作为我们的OD存储PG data来用，这样的话，它的相上，它能够balance你的性能和你的一些呃相当于是提供最好的性价比吧。

这是我们这边的一个呃软件的一个架构，首先在左边的是我们的呃自制引擎的系统的架构，呃它也是跑到一个Linux系统上面，然后呢，它有个pro微的这一个呃frame work里面包含了呃像一些做一些呃系统的一些自动安装的需要用的，比如像DNS maq，大家知道它会提供一些DNSS我以及TFTP呃serve去做P叉的安装，像哈它会提供一些呃发serve以及do的rish，像我们可能国内呃有那个会碰到一些像呃国国外up上面的那些do region些访问速度过慢啊，或者像呃最近出现的doer ho上面hit他们的个腾访问次数，那我们可能在本地会有个哈B的话会好很多，就不管是作为一个mirror的一个也好，还是。

作为你的本地private的对些也好啊，都会能够有很大帮助，然后像mental cube这个的话，应该是现在比较流行的一个开源项目，它能够帮你通过耳罗内克去，呃装很多那个，就是说装操作系统，以及做一些普威许它它也提供了很多其他普的，像像呃AWS啊，Google cloud啊，像这些它都有po的，就会帮你在语音上面去，呃创建你的节点，在你的节点上安装新的，呃安装一个操作系统都是有的啊。然后可以看到在右边的话是我们的target的一个集群的一个架构，首先就是说我们会有一个底层的platform的，呃，Software就是说这一层platform software就跟传统的单机是差不多的，它有它的OS这一层，然后provision是相当于是一个service，它会跑到agent跟我们这边的engine这边top provide talk，就是说比如说他提供本地的一个硬件能力的一个枚举。

或者对本地一些呃，管理。啊，然后还有have的话，我们基本上modern就用what，呃带啊，然后还有long time的话是can能的地，我们这里强调卵time，主要是因为我们现在的呃，流行的这种边缘云话用的是K8S，所以我们在底下的pone这一层呢，就相当于说能够提供一个轮，呃，Contain的一个轮探，把这个准备好以后哈，我们就可以开始装K8S那个costs就集群这一层呢，我们就基于这个container run time，加上一些have wide这个service呢，我们在网上面搭我们的集群，就是说它的K8S或者K3S，如果为了轻量化的话，然后network的话，我们会有多种的C作为选择的安装，像开啊啊，Fi诺啊，还有很多其他的客户OV啊这些，然后呢，就像我刚才提到的根。

据我们这边的agent发现我们的network的一些cap，我们会自动在安装这个C的时候会做一些优化，那你的API network network呢，都会呃做一些基本的优化，好，然后我的话，我们这边推荐是用呃Co沃，呃我们用下来感觉也是呃就比比较方便，轻量吧，比open sta还轻亮一点。然后的话我们装个呃普米修，然后用去安装我们其他的service啊，然后在的话，我们可以装一下或者这些，这样的话就通过呃，把这一些也是通过我们的po把它全部装好以后呢，这样我们整个target的集群就算搭建完成了。

所以呢，这边呢，呃这里画的就没有画很多优化的细节，比如说举个简单的例子，我们如果是呃用上用Co沃里面想去起一个window虚拟机，那window虚拟机的话，它的普通面优化的话，可能会涉及到很多很多优化的细节，比如我们这边需要呃去比如说让呃Windows虚拟机能够用呃water IO的，或者说能够用一些pass给他那个一块硬盘去优化它，然后让它达到工业级使用的performance要求，然后呢，还有一些就是说像那种呃window Windows如果里面对CD啊这些有需求的话，我们可能还要做一些呃GPU的一些呃PASS15啊，或者GVDT的这些优化。

所以这里面呃涉及的优化可以就是说呃，以及那个在普普维信就要做的这种自动化的一些优化会在这里体现出来，就在我们这前面一路一页里面的，就是这边就是我们的engine，就是说不光是说把一个节点加入到我们集群，它涉及到对这个集群的一个proviion，它这个update，比如你加这个新的节点，它需要update它的整个集群，然后呢，呃，比如说会对比如你你有个有加这个节点是做storage扩展用的，那它可能就update s。好，然后一些优化，比如说像我刚才提到的，呃，你的SID和机械硬盘去怎么去优化，让你的赛性能更好。行，那我这边主要讲的就是这些，因为我想把有点时间能够大家呃交流一下，好掌声鼓励一下我们杨老师的精彩分享，那么接下来的时间就是到了我们杨老师的这个提问环节，现场的小伙伴们现在可以举手，然后向我们杨老师进行一个互动交流，提问的环节接下来时间交给你们看一看有哪位小伙伴首先举手发言。

好，我们可以在我们活动现场，好，我们那边有话筒，您拿这个麦克风，呃，我刚才听了一下你的边缘云主要是帮用户在本地进行部署一些云服务，对吧，像是K8S之类的，对这就回到了我刚才在云原生问的那一个问题了，就是在本地做一些离线数据保存，你们是怎么做到和云端做一些数据的一些加密案。就信息安全的之类的问题了，刚才我在第一次问问题，他说问错问错主题了，呃，现在这次应该没问错吧，呃，我虽然不是一个最正确回答的问题的，但是我可以回答一部分你的问题，首先就是说一个数据的一个安全的话，它涉及的一个券，它需要从你的硬件最开始阶段就要对你的数据有安全性的考虑，比如说像我刚才这里面提到的。

你怎么样去，比如说你这个集群你是自己部署的，那比如说你要往集群里面新加入一个机器，里面是放一些你的数据的，那怎么你第一步你怎么相信这台机器，这是个问题，你比如说你随便找一个人去帮你把这机器接上去，那你怎么知道这个机器是安全的，是你自己买的，是这样的，我们这边现在面对的主要问题是。数据客户要求放在本地，但是要求数据要通过云服务能够传递到其他位置，所以客户会有一种焦虑，就是穿透云了的本地化数据会不会被云所窃取？

那这个这个呃，集群本地的部署，集群是你们自己部署的吗。我可以假设使用的是你们的边缘云的一些服务，然后然后云上面的服务，用你们云原，云原生的服务，就是把云原生和边缘云结合起来，嗯，其实我刚才讲的就是说，比如我举个例子吧，你异地的数据的拷贝对吧，就你把从这个集群迁到一个另外一个地方，可以拿这个当例子嘛，可以可以好的，然后呢，我我们首先就是说在两边部署的集群，首先要是安那个安全可信的，那涉及到我刚才提到的，他要帮你去管理这些配置，这这些证书。那么这个证书的话，需要一个安全的方式传到对方，所以呢，就涉及到对方那边机器的那个，呃，也是受你信任的，那么我这边打个小广告吧，就是说我们英特尔有一个项目是叫SE，就secret的device on board，它可以说你在英特尔的芯片内部或者说软件的方式都行，有个script，这就是说这个东西是由你们提供，可以放在这台机器在出厂的时候就放进去，或者说你们预装的软件里放进去，然后你的放到一个异地以后，安装系统的时候，它会连接回到你本地的一个你售信的，你自己提供服务器做验证，然后你给他提供说接入的一个培训，让他接入你的那个网络。

然后这样的话，这个远端的一个相对于远远端的机器就是你受理性能的，而且校验的过程当中，可以把你本地的呃，设置这些文件呢给他，这样的话，你拷贝的时候就不是用户名密码了，就相当于是远程一个安全的拷贝。好，明白了，还有另一个问题是这样的啊，因为做这种混合云的服务的话，通常比较高的风险，就比较担心的就是断网，嗯，你们这个边缘计算平云平台的话，有没有方式，就是正常情况下数据走有线网，就RG45，然后当RG15数据出现异常的时候，数据切换成4G网络或者是5G网络，但是保证整个应用场景就是不会不会中断，嗯，这个我可能要帮腾讯这边打包，我知道你们有个smart edge就做这个用的，对吧。

对，腾讯这边有个有个smart edge，就我相信就是你的，就是说它边缘的一个呃，独立自自理自己，呃，管理自己一段时间的能力。不是自己管理自己，而是从一个网络传输渠道立刻切换到另一个网络传输渠道，就从我现在一个正常，比如说我正在做直播，但是我有线网口被人拔掉了，然后直播的话。

数据立刻变成4G网络，但整个直播流没有任何变化，就整个用户是感知，感知不到的。我有点明白意思，你是那个网络的这一块，就是说能不能无缝的切换，对对对对对，因为这个在边缘，这个是其实是属于SDN部分的能力，举个例子，就像那个open sta里面的牛圈一样的，就是说你的虚拟机迁移到另外一个机器上面，它能带着网络连接无缝的迁过去，其实的话，你说的这个能力有点像牛串里面的佛定IP，在做虚机迁移的时候能够无缝切换，这是属于一个SDN里面的配置问题，这个应该是有，呃，已经有一些现有的方案。当然，在我们英特尔内部有那个open stack的开发团队，他们可能比我更懂这一块。好，谢谢好，刚才那个小伙伴呢，我们现在刚刚老师不知道是否为你解答清楚了，那么没有关系，我们在群里面，今天是各路大神大咖的这样一个交流，在群里面呢，都可以跟其他的没有到场的老师们也可以进行一个现场的提问，或许有其他方面专业的老师会为你进行一个详细的解答，好吗？

好，谢谢我们杨老师，如果还有疑问的话，可以在稍后的茶歇环节向我们杨老师进行一个私下的这样一个提问以及沟通，那么接下来将由我们军工教育创始人邓军老师为我们带来题为教育行业如何拥抱云原生技术的主题分享，从实践的角度来解读我们云原生技术的落地，大家掌声欢迎一下，谢谢各位小伙伴，大家下午好。首先感谢这个T这个邀请这个本人来参加这个我们的这次技术沙龙活动。那么接下来呢，这个我会这个从公司实际业务场景这个跟大家解读一下，我们这个云原生技术啊，该如何去落地。

希望对大家这个有所启发和帮助。当然前面几位大佬已经给大家解读了我们这个云原生架构，还有实现层面的一些这个具体的一些这个细节啊，那我这边主要就是从实际的这个角度来继续大家这个分享。首先做一个简单自我介绍，我是军工教育的这个负责人，邓军。是一名苦逼的成员，也是也是一位正在路上的创业者，所以呢，我呢拥有两重身份，一重是从技术角度，当是从这个角度，我可能会比较追求这个技术上的完美。啊，有点这个完美主义，但是从这个创业的角度呢，我会这个追求，另外一个方面就是如何降本增效。

首先呢，我跟大家这个分三个方面进行这个分享，第一点呢，就是我们这个痛点分析。就是我们这个企业啊。他这个有哪些痛点，我们为什么一定要去接受这个云原生技术的这个优秀的这个架构。还有包括一些这个为什么要去这样去做，难道传统的这个it的这个这个服务的这个模式不行吗。这是一个方面，另外一方面呢，我会给出一些这个我们的一些解决方案，虽然说是局限在我们这个教育行业，但我觉得对各行各业应该会有所帮助，应该其实都差不多。啊，然后最后呢，会有一些自己的个人的一些这个公司的一些展望。还有一些总结。首先说一下这个我们面临的一些痛点问题。这个其实不仅仅是在我们这个教育行业，在很多行业都有这些问题，第一点呢，就是我们新功能这个上线的一个速度。

尤其在我们这个教育行业。因为我们军工教育的是做这个it技能培训这一块的。It技能培训。那么这个。我们之间需要各种各样的新功能。呃，比如特别是因为我们教育培训主要就是有这个招生，还有这个教学这两个板块构成，那么在招生这块呢，我们这个要举办很多各种各样的一些这个营销活动，线上线下的还包括。这个甚至跨界的营销，那我们这个在技术层面呢，我们肯定要支撑这些活动。所以这里呢，记账需要一些新功能啊，需要新功能需要快速上线，要不能太慢，太慢了可能错过这个时间点，或者可能就没有任何意义了，好吧，所以我们也有时候很痛苦是吧，怎么快速的搞定这个事情。当然在教学这个板块呢，这个变动可能不会太大，另外一方面呢，就是还有牵一发而动全身，这个痛苦，我相信很多在座的开发者小伙伴应该有所感受。啊，在传统的这个开放模式下面，我们经常一个一个系统了，我们经常为了增加一些新功能，或者说这个优化调整某些功能板块，经常会导致这个整个系统出现一些问题，这是我们可可能马上想到赶快回归是吧，你比追求这个稳定可靠。

但是这又对我们这个追求新功能的可能有有又是个矛盾啊，所以我们经常这个开发人员和这个运维人员吧，他这个他的一个这个出发点可能就不一样是吧，公司层面的可能需要这个新功能快速上线，而这个运维了，这个可能需要这个系统稳定可靠。当然我们最后一点就是爆款活动，我们是又爱又怕。我们希望我们举办的每一场活动都是爆款，都能有很多这个吸引很多的这个意向学员，但是我们又害怕这个，有时候我们这个后端的技术真的扛不住这种服务器压力啊，这个瞬间的高并发是吧，可能或者数据量太大，我们导致系统直接出现问题。

这也是，所以我们又希望这个事情发生，但是我们又比较害怕系统扛不住，所以我们经常盯着这个，我们后台的这个这个服务器的这个监控面板在那盯着啊，生怕出现一些问题，可能在祈祷啊，这是在传统的这个开发模式下面是这么一种情况，当然这个自从我们这个接触这个云原生技术之后啊，其实在这之前呢，我们并不是很清楚，这叫云原生技术。啊，那么呢，这个后来提到云函数技术这个名词之后，后来我这个思考了一下，觉得我们现在做的这些事情啊，做的这改造，包括技术上的一些开发模式的一些转型，包括思维上的一些这个转型呢，其实就是音乐养生技术啊，所以我个人认为呢，音乐养生技术啊，主要包括这个四点。好，当然是个人拙见。第一点呢是容器化，容器化就是我们将我们的这个各个服务啊，可能把它这个按不同的维度进行这个划分，也就是这个微服划分的微服务，然后微服务呢，当然这个容器呢，只是它的一个载体啊，然后呢，再使用这个敏捷式开发的这个运维开发一体化WS的一种这个开发的一种这个方式思想。

当然这个主要实现的好处就是我们CFD就持续这个集成和交付。那首先呢，这个看一下我们具体的一个解决方案，就是曾经的我们在之前呢，在公司刚开始的时候，我们做一套系统啊。就是支撑我们这个包括招生，包括这个呃，教学和教务。包括甚至包括一些这个教师这个管理，包括合作企业的一些这个系统啊，可以说是一个单体的巨无霸应用。非常庞大，而且随着这个推移呢，是因为越来越庞大。后来发现了这个非常的这个有问题，非常有问题，有的时候我们为了增加一些新功能，可能会导致真的全盘可能出问题，所以后来我们将它这个拆分为多个位，服从不同的这个角度。

学管理划服务，然后每个微服务呢，我们使用一个多卡镜像进行这个管理。好，采用这种方式，每个多个镜像呢，我们有不同的这个个人。不同的这个我们我们团队也不是很大不同的，个人进行这个开发管理，可以使用这个最擅长的这个编程员或者技术站，没必要说统一这个编程员或者是一些技术框架，好吧。这带来一些好处。这样来的话呢，我们这个整个系统啊，就被改造了一下。这样的话就避免了一个问题，就是之前说的，我们这个新功能的一个上线的一个问题。这样的话，因为每个其实我们很多营销活动啊，包括这个一些各种新功能，其实我们后来这个仔细思考了一下，其实他们背后的所这个实现的功能其实很多都是相似的，很多功能都是相似的，或者有一些共同点，没必要说每次都是从零去开发，所以我们这个划分为服务之后呢，带来的好处是非常显而易见的。

然后另外一方面呢，啊，这个上线也会快一些，因为它这个说白了，每一个微服务呢，它代表的就是一个局部的一个功能。啊，可理解性的，包括维护性的都会比以前更强一些，不会导致这个牵一发而动全身这种情况。然后呢，这个每个服务啊，我们它的一个管理方式也更加灵活一些，有这个不同的个人或团队进行管理啊，这样的话呢，对我们整个系统运行来说是非常有帮助的，再说到这个我们这个爆款活动一个问题。因为这个我们一直用的是从公司这个诞生到现在，我们一直是腾讯的这个忠实粉丝，也是客户啊，我个人呢，也是一直在使用这个腾讯云的这个产品矩阵来实现这个功能，这个在腾讯云的这个容器服务这一块啊，我觉得这个做的非常不错。

啊做的非常不错，因为这个容器服务呢，它这个从两个层面可以进行自动的这个伸缩，就是一个是容器这个级别，一个是容器级别，容器级别这一块呢，就是它可以实时监控这个容器的CPU内存带宽这些这个指标。然后根据这个指标，它可以自动的这个扣除。啊，这样的话，我们就毫不用担心这个经常一些爆款活动导致这个服务器崩溃啊等等一些事情，经常这个熬夜啦，这个盯着这个面板是吧，很痛苦，另外一方面呢，它这个集群也是可以基于这个事件进行这个自动伸缩的。它机群也可以伸缩，除了容器可以伸缩之外，在集群也可以伸缩，所以这点来说，这个就没有任何后顾之忧了啊。

所以我觉得这个这也是我们这个在印用来这个觉得非常放心的一件事情啊，所以现在我们在采用这种。这个微服的这个落地这个实现之后吧，我们觉得这个自己的这个突然就少了很多事情，不像以前那么总是那么担心啊，这也是我们我想给大家分享的一个小经验。呃，另外一方面呢，就是我们这个另外一个案例啊，就是我们这个录播课程的一个管理。录播课程呢？这个由用户端呢，他上传这个视频，也就是我们比如我们中国的一些老师，包括全职的，包括一些这个签约的一些兼职的一些教师，他们录好了一些这个课程之后啊，课程的是视频文件，那么他们呢，这个上传，那这边呢，我们之前可能是自己的这个用这个CVM自己去搞，搞定一些事情，后来我们这个用的这个cos对象存储了一下，觉还确实不错啊，这个省了好多事情，好多事情啊，以前呢，我们这个当时用了自己这个C，直接用CM续机的方式发现呢，很多时候这个带宽呢，包括这个实质性呢。

是吧，都会有一些问题，那为了这个，为了承载这个，为了这个这个学习体验更好一些，当时呢，我们这个是越来越大，但是发现了，其实还是达不到这个好的一个学习体验。所以后来我们就换了这个对象存储，那这种方式呢，是按量计费的。按量计费，我们没要说一开始就准备好非常庞大的这个带宽，或者更非常高配置的这个服务器啊，没必要去整这些，包括这些这个海量存储，我们是按量付费，按量付费就行了，这样的话可以降低这个公司的这个成本。啊，因为我们企业追求的肯定就是降本增效，这是宗旨，呃，降本增效如何这个降低这个成本，最大限度降低成本，提高这个效率啊，这是要极致追求的一个事情。

最后刚开始最初觉得这个按量付费，觉得可能也不太靠谱，或者觉得是不是会耗很多钱是吧，但后来实际在使用过程中发现真的很不错啊，真的不很不错，包括现在很多云计算产品都是使用按量付费的方式，我觉得非常不错的啊，在很多这个这个波峰时期可能要耗耗一点费用成本，但是在波谷时期可能会节省很多费用，甚至零费用是吧。然后呢，这个我们将我们的视频呢，传到这个对象存储上存放，然后呢，我们这边呢，这个通过这个云函数，也就无服务器这个开发模式，实现这些视频的一些理包，针对不同的这个清晰的个频进行不同的理。然后进行这个转存到库存边，然后呢，我们不同的这个客户端呢，然后进行这个相应的这个接收，进行这个学习观看啊，整个过程呢，非常的流畅。

啊，非常流畅，也不会出现像之前经常因为带宽不足啊，因为服务器这个并发跟不上，导致了各种各样的一些高延时，甚至这个服务不可用这些情况啊，系统的稳定性呢，也基本上没有任何的问题啊，没有任何问题，具体的没有进行压力测试，但是现在使用来看，基本上没有任何问题，能够承载公司的一些业务的需求啊。那么这边呢，这个最后呢，这个有实际关系，我就不分享更多的业务场景，其实我们还有很多，还有很多这个我们实际的业务功能啊，我们都把它这个通过这个云原生技术这个架构啊，把它落地，并且正在使用之中，如果大家有兴趣的话，这个可以私下交流，我也会知无不言，将我们的实践经验啊给大家分享一下啊，但这里面呢，主要其实在开发层面来看呢，我们具体怎么开发的，其实主要就是一句话就是。

一个镜像，然后三套环境，然后这是什么意思呢？这是我们所有的开发人员了，我们通过get，然后的更新代码，然后提交，提交之后呢，然后进行这个。说白了就提交之后，我们会发布一个新的镜像，这是在开发环境下面进行这个测试就通过了，然后在这个生成镜像之后呢，然后在我们这个测试环境下面进行一些这个集成的一些测试，如果说没问题的话，我们在这个把它发布到生态环境下面进行这个部署，也就是我们这个一个镜像三个环，这个三套环境的一个实践。简单来说就是这样的，可能这个事情很多大家都在采用啊，也没什么多说的。好了，那么最后的这个，我这个说一句啊，就是我们技术和工具啊，永远是为需求服务的。

一般是为需求服务，其实我以前作为我这个作为成选的，我可能想到啊，我要追求最好的一个技术架构，追求最好的一些这个工具，但是作为一个创业者的我肯定要这个降低成本啊，这是一个可能有时候是一个矛盾啊，但是我们要说的是技术工具没有最完美的，只有这个最为需求，这个为针对某一个需求是最合适的，可能就是最完美的。然后后期呢，我们可能会基于腾讯的这个产品矩阵的构建，可弹性扩展的无服务器，后代就是外部包括移动后端了，我们准备可能尝试一下能不能这个无服务器，这样的话就可以免运维，降低很多一些成本。而降低很多成本。直接无服务器。啊，基于这个云函数，包括cos云数据库啊，这些产品矩阵，包括我API网关啊，我觉得这个我还是很有信心的，我对腾讯的这个产品非常有信心，那我觉得非常不错，这样的话会省好多事情，省非常多的事情，可以说真的是提这个绝对能提效，这是没问题的啊，至于这个成本的话，还没有去估算太多，应该成本也会降低，我估计啊。

好，再就是这个我们因为我们要打造自己的专属云端课堂，因为在线教育现在也很火，我们肯定要在教在线教育这一块也需要去这个，需要去这个布局了，那么这个基于实时音视频TRDC这个服务包云函数了，我们可以打造这个专属的云端课堂啊，之前是做过这个，做过这个直基于这个TRTC这个服务啊，做过这个直播间啊，做过直播间这个自己的直播系统，觉得还是体验还是非常不错的啊，体验还是非常不错，开发过自己的直播间，那后面可能是开放我们自有的这个直播间啊，基于这套服务器打造，因为曾经其实也想过自己从去开始去部署，去搭建，但是后来发现各方面的一些问题会浪费很多时间和精力，所以直接基于腾讯云的这个产品跟你去打造，我觉得应该是比较轻松的啊，那么这个。

今天的分享呢，就到这里啊，看各位有没有一些问题，我们一起讨探讨一下，好，您稍等。我们小姐姐把麦克风交给这位嘉宾。嗯，你好老师，呃，我想了解一下，就是你们在使用TRTC的时候是怎么样解决那个直播延迟的问题了。直播延迟对，就是在多端的话，比方说在那个手机上和和在PC上，他看那个直播它会出现延迟，因为我之前也用过，他大概不知道怎么回事，当时好像有大概有30秒的延迟，不不知道不知道呃，老师是怎么优化的，我这边的话，因为T2C嘛，这个腾讯这边已经封装的非常完善了，基本上我们就是阅读它的这个开文档啊，调用台SDK的接口来实现的，所以当时可能按照DEMO来跑的话，一点问题没有。

这个你说的这个问题可能没有遇到过哦哦，这边的话我觉得应该它底层优化的都挺不错的，因为它这个都是一些接口嘛，就调用就完了，感觉也没有太多的一些问题，可能没遇到这种情况，好那我回去再看一下，谢谢老师，嗯，好，还有小伙伴吗？好了，我们一个一个来。啊，请问一下，就是从传统的这种服务器架构，然后转到这种微服务架构，大大概每个模块的这个，呃，费用，还有这个成本是多少成本，这个成本的话，肯定要看具体的一个业务的需求了，这个没有定论，也没有一个标准的计算公式，他说你自己试一下，其实就知道，你比如说时间和人力方面的。

啊，其实你说的可能是不是说像现在传统的方式，可能就经常这个做一台服务器，然后呢，包括把带宽呢，包括把硬件资源都准备好是吧，但可能有的时候会比较过剩，会比较浪费，但是真正这个处于波峰时期，可能也扛不住这个压力，所以造成很多浪费，但按量付费呢，可能有这么一个优势，他可以在波谷时期可能是零费用，零成本，但是在波峰时期的可能高并发的这个访问的时候，可能也会带来肯定会产生这个一定的费用，这个。就没有定论，就是到底有多高哎。那关于那个如果有安全方面的那个等级要等级保护要求的话，这个这个会可以去定级吗？或者是有一些防护的这个策略。

在等保这块，一般来说都是自己内部系统这个去实施的事情，这个我觉得这个云端这些产品了，可能只是提供一个平台。还需要我们自己去保护，包括加密啊，包括证书这些。哦，好，谢谢好的，您将麦克风送给第一排的这位大哥。呃，邓总你好，是这样的，你在讲的过程当中说是巨无霸的个应用，然后拆分成那个语音原生的一个体系架构，我想问一下，就是你在这个微服录的拆分的个原则和实践的这个过程，能不能详细描述一下，嗯，好。那个实现的原则是这样的，就是我们的话，根据我们的业务这个特点，然后呢，这个将不同的功能模块，因为其时我们这个在开发中发现，其实我们很多一些新功能啊，最终也是这些不同某一个功能模块，或者多功能模块之间的一个结合在一起构成的，所以我们按照功能进行划分，比如我们这个的业务非常的单纯，就是有主要来说就有学员的一个管理。

啊，学员的管理，包括这个教师的管理，课程的管理，主要来说就是这些，所以我们基于这些进行划分，然后将它这个功能，把它划分成这个为服务，这个镜像是这样的，比较单纯，可能这个要根据这个自己的真实的这个业务场景去进行行划分，这个应该没有什么具体的定论啊，只是说最好是这个要实现一个高类级低耦合的一个原则吧。那对于你的一些有共性的那些基础性的功能的，是会拆分成更细的为服务吗？

哦，你说进一步细分是吧，对，就是共性的基础性的这些那个组件。我们如果说有些这个有些这个说白了就是使用说比较的一些功能可以立出来，我们就会把。谢谢您的解答。那个豆豆你好，就是那个我们那个从单体架构，巨无霸架构到微服务架构过程中，你的可能开始那个到微服上线过程，有可能你马上就炸掉了，那有在这个过程中，我想请问你一下，怎么能快速定位错误，快速那个预警，或者让我的服务那个就是快速来解决问题，比如从传统的这个架构到这个我这个云原生的一个技术架构，哦哦，是的个有可能你那个在，呃，比如说怎么说呢，就是你，嗯，你从单体那个切到那个微服务过程，如果说你中间没有规划好，或者说如果程序有有一些bug，有可能导致你整个系统会造成那个雪崩效应。

嗯，这个怎么快速那个解决这个问题，来定位问题，来解决问题了，这个我们之前是这样的，我们因为要实现一个无缝的一个牵引，肯定不影响，不能影响实际业务的一个这个正常运行，所以我们之前呢，可能都是在另外一台这个服务器上，然后进行一些这个过渡，也就是说可能在启用之前呢，我们先经过在在另外一个环境下，另外一套环节进行这个测试，然后进行验证，然后没问题之后，我们再可能在某个时候，然后呢，直接切换过去，这可能就不会影响什么。但是你说的是直接，如果说直接贸然的这个切换的话，这个可能比较粗暴的方式切换的话，或者是直接从这个非常这个非常这个太明显的切换，或者是绝对化的切换，可能会带来一些水土不服的问题，但是如果说这个先做好一些其他环境的一个充分的准备，测试，然后验证之后，然后再送切换过去，其实根本不会造成什么影响，我们一般来说都是这样做的。

好，谢谢谢谢，好谢谢我们这边，然后我们时间关系，我们马上到茶歇环节了，我们这边感谢我们邓老师的精彩演讲，好吗？来，我们可以入席就座了。好，谢谢，再次感谢以上四位嘉宾的精彩分享，接下来呢，就是我们活动的茶歇时间，好，感谢大家的回来，接下来就要开始到了我们下半场的分享环节，接下来有请我们腾讯云service list专家架构杨正权老师带来类is more service时代研发效能管理的主题分享，掌声有请我们杨正权老师上台，下面的时间交给我们的杨老师，掌声鼓励。呃，首先自我介绍一下啊，我是腾讯云的呃，专家架构师，然后呃，杨振权，然后今天我主要的演讲题目是less small so时代的研发相通管理，其实提起so这个东西并不是一个陌生的概念，对，然后尤其是这几年大家其实可以看到各个云厂商其实都在sola方向去发力，对吧，我们能够看到越来越多以sola形态，呃的产。

品，然后再层出不穷对吧，然后比如说最典型的其实就是说函数，呃以比如说函数及实例，然后类似于这种fast形态的啊，比如说我们说云函数也好，然后AWSLA，还有阿里FCA的吧，其实都是属于fast形态的这种solo产品，那除此之外呢，其实还有更多的类似于solo数据库，So中间件，Solo存储等等，对，所以说我们能够看到，呃，除了这个产品之外呢，然后其实我们也看到在落地，还有说各个厂商以及说呃在对外宣传，然后很多落地案例，然后也逐渐的丰富，所以说。

我们一直认为说S应该是下一代的这种通用计算，然后呃，但是在实际的这个落地过程中呢，我们会发现S应用开发其实并不是一件，呃，那么看上去虽然说有很多并不是一件容易的事情啊，然后其实我觉得在整体的这个开发过程中，其实还是需要有一定的这种，呃，它是一种新的编程编程方式，然后同时也需要有一定的这种思维转变，对所以说我觉得在今天的分享过程中呢，也会给大家分享一下吧，然后传统的这种应用开发和serve的开发方式之间的区别是什么，以及说当今正在大型提到这种微服务啊，微服务架构风格和sor这种架构风格到底有什么区别，我们再去设计一个sor应用的时候，然后跟微服务之间是要怎么样把一个微服务架构迁移到一个solo架构，其实我觉得这里是有很多非常有意思的问题啊啊，所以呃，那我们那我们继续开始啊。

OK。这是我今天的演讲提纲，然后首先我会介绍一下solo的概念和价值，然后其次会去呃分享一下我们在solo应用开发过程中的一些挑战，以及说对应的一些对策，然后其次我会分享一下相关的一些这种案例啊，然后最后我会展望一下关于servicer的一些这种发展趋势，然后分享一下我自己个人的一些见解，好，我们看第一部分，然后呃，我们可以从这个从基础设施演进的过程来分析啊，然后呃，为什么会出现sola这样的产品形态啊，所以呃，大家能够看到在这个。在这里有两个维度，首先第一个维度呢，是abstraction，也就是说抽象层次，然后另外一个维度呢，是呃，团队需要去负责的基础设施管理的职责大小啊，然后，所以我们可以看到，随着抽象层次的提高，然后对于开发者也好，对于运营人员也好，他的关注点其实是在降低的，因为它本质上其实做的是一个关注点分离的事情。举个例子，比如说我们从这个物理机到虚拟机。

那对于。团队来说，对于企业来说，你不再需要去管理，比如说硬件啊，以及说一些这种网络啊，各种各样硬件基础设施，那从这个虚拟机，然后再到容器化时代，或者说K8S集群的调度，然后更是屏蔽了比如操作系统的差异，把所有应用级别的一些依赖环境，然后全都把它放到容器里面，ISO呢，其实是在这个之上去做了近一层抽象，它所谓的抽象形态呢，叫fast，对吧，然后是属于呃，So形态之一，我们叫做function as service。嗯，它为什么说它是更进一步的抽象呢？它除了说基本的这种，比如容器化啊，或者说关注点隔离之外，对吧，它做的更更近的一步，也就是说我们把整个基础设施的可用性，以及说它的弹性伸缩的能力全都交给这个呃，云厂商来处理。

其实我觉得举一个更具体的例子，其实对于比如说K8S集群来说，对吧，然后往往其实在自动扩容的时候，其实会有一些这种。限制啊，比如每分钟最多可以去创建多少个pod啊，大家可能对于熟悉KPS应该会知道，那对于函数来说呢，它是一个非常显著的特点，就是自动扩容，对于开发者来说，对于企业来说，你不用关注说当我的流量出现了瓶颈的时候，我要怎么去扩容我的基础设施，所有这一切都是由呃平台自动完成，现在至少这应该是一个底线，至少一分钟之内需要去扩容500个函数实例啊，这是一个bottom line，当然呃，由于你的这个资源池，以及说的这种扩容技术的这种提升，然后也可以做到1000甚至更多啊，然后这是一个solo性的特点，然后除此之外呢，然后他还他还托管了，比如说可用性啊，然后还有一些容灾备份啊等等相关的功能。

好，我们在提so勒价值的时候，经常会用这张图来看，大家可以看到，呃，红色的线其实是人工计划容量啊，然后呃，黑色的这条线，然后是实际流量。我们可以看到其实。对于呃，对于对于这个左边这张图对吧，然后我们可以看到一个这个，呃，看的不是很清楚啊，就是在这个位置啊，其实这里代表的就是流量溢出，也就是说我们自己准备的这个计划容量，然后无法处理它的实际流量，这里我们也管它叫做流量溢出，那我们再看另外一个点，也是最右边，最右边出现了一个波谷是吧，它代表的就是说我们人工计划容量呢，然后其实呃没有人工计划容量远远超过了实际流量下，它带来的问题就是说企业的一个成本上升，我准备了大量的虚拟机，可能只实际你的资源利用率才有50%，甚至更低，对吧，然后很多虚拟机都属于这种呃低负载的状态，其实它就会带来这种资源的浪费。

好，下面再看另外一个问题。So和传统的pass平台到底有什么区别啊，然后我们知道，比如说像KS也好啊，Open stack呀，各种各样主流的这种，呃，主流的这种pass平台，对吧？那比如说对于LA，或者说以so概念的这种fast平台也好，或者说so容器也好，它和这种传统平平台到底有什么区别呢？我认为有这个四个重要特征，然后首先第一点呢，就是scale to zero，我的函数，我的应用实力是不是可以真正缩减到零？啊，因为对于很多平台来说，它是至少还有一个实例啊，所以我觉得这是一个重要的判断依据，然后另外一个呢，就是fast provision啊，你你的整个基础设施是不是可以快速创建啊，创建一台虚拟机需要多长时间，可能大家应该都会比较清楚，只要说在云上买过虚拟机是吧，至少可能要等几十秒啊，或者说一分钟左右吧，啊，那可能容器的速度会更快一些，但除了容器之外，其实即使是容器化应用，你还要考虑说容器镜像拉取，那我对于1G甚至2G更大的一个容器镜像我要去拉取，初次能启动的时候我要去拉取是吧，然后一定会有这种，呃，下载时长，然后除此之外还有一个快速扩展能力，这个刚刚已经提过，然后另外一个是快速回收，为什么我在这里强调快速回收呢？因为本质上sola产品它仍然是一个业务，一个需要去盈利的生意，是吧？如果说我把所有的资源拉起之后，没有办法快速回收，更加有效的去利用这些资源，它带来的一定是整个产品成本的上升，对吧？那整个。

说solo的产品它的利润率从什么来，对吧，那一定是资源利用率，那如果说我们可以去快速回收的话，那意味着说我可以更合理的去增加这个整整体的资源利用，资源利用率对吧？然后从来说实现一个比如说你的这个利用率更高，对，所以我觉得我认为最后一点，呃，同样也很重要，快速回收，然后至少现在应该是在比如说十分钟之内，你需要去把现有的函数实例去回收，回收很回收很容易，但是回收如果说你回收的太过频繁，往往带来的问题是你会导致大量的这种应用能启动，可能会带来这个客户体验的下降。

好，然后根据呃，这是最新的一个调查，对吧，关于sor整个应用的一个普及度，然后我们可以看到在受访的这个整个it的一些这种开发者来说，已经有大概75%的企业和个人已经采用了sola技术，大家在谈到sola的时候呢，更多的其实是看这几个特性，大家可以重点关注前三个吧，首先第一点就是快速伸缩啊，我认为这个也是快速伸缩能力，也是云原生，呃给给这给给企业也说呃公有用户，然后提供的最大价值吧，然后第二点呢，是研发效率，然后其次是呃降低运营成本啊刚其实呃我们上一位讲师其实也提到吧，然后尤其是这种service形态的应用，它的免运为一个特性，然后真正能够让企业你的，因为在任何时候，企业的这种投资是固定的，那我们要考虑的问题一定是如何去最大化我的这个投资产出比，那我就通俗的说就是我的钱要花在什么地方，你是要把钱花在你的这个运维。

呃，运维，呃，整个集群的运维呢，还是说是花在这个整体的这个基础设施，呃，比如说你去购买几百台虚拟机，然后而且它的资源利润高，这些其实都是你的这种成本浪费，对，所以我认为，我认为企业真正要去考虑一个这个投资组合的时候，他一定要考虑的是说我要把我的投资真正放在可以给我带来核心竞争力的地方。那对于这种。研发，对，对于这种比如说虚拟运维，或者说你去部署一些这种，呃，或者说去管理一个这个CBM集群，我我觉得它并不是能够给你带来这个差异化竞争力的点，对。好呃，我们再来再来快速分享一下，然后我们在一个serve应用开发比，然后有哪些这个常见的挑战和对应的对策啊，首先看第一点，然后这是一个例子，然后我们可以看到它这是一个那个智能家居的落地案例，然后我们可以看到它这里的的这个请求数其实非常多的，然后每分钟大概要处理近400个视频，400万的视频拼接请求，然后如果说我们转换成QPS的话，大概比如说10万左右，在正常情况下，然后平均处理时间只需要六毫秒，那如果说是六毫秒，那意味说我要去支撑10万KPS，我只需要600个函数实例就可以了，但是我们有一次在线上遇到一个很严重的告警啊，当然这个并不是平台的能力的问题啊，啊，然后同样的QPS。

然后他在我们发现说他他有大量报错，他他再去。触发了整个应用的一个自动扩容，它需要更多的函数实例啊，我们最终发现它平均处理时间由六毫秒增加到了70毫秒啊，也就是说如果说我们再去支撑10万KPL再去计算的话，大概需要7000个函数指令啊，这个账号呀，最多也只能去建1000个，当然这是一个软性配置，是可以通过后台去修改啊，也可以去申请的，对，所以这里其实我觉得可以体现一个问题，我们在做serve应用设计的时候，由于它的弹性是非常极致啊，可以快速去创建成百上千个函数实例，对，所以说很容易把你的底层的数据库，或者说你的底层的这种依赖系统击穿，然后这个问题就是，其实就是因为客户的底层依赖系统，然后变慢了，结果导致了整体的这个呃，应用的不稳定，所以。

大家可以记住这句话，就是雪崩时没有一个函数是无辜的，因为对于fast形态的应用时来说，我们可以很容的容易的去把这个呃函数拉起来，但是对于一个应用视角，我们要考虑很多，比如数据库啊，文件存储啊，或者说中间件啊，各种各样的问题，然后任何一个产品都有可能会出现，都可能都可能成为这个整体的一个瓶颈，如果说我们参考这个，当然这个其实也不是一个新鲜的概念啊，对吧？然后我们知道在做分布式系统设计的时候，这个其实是一个还是非常常见的模式啊，比如说以这个船舱设计设计为例啊，我们知道在设计一个，尤其是很多游轮的时候，然后它其实一个非常普遍的一个设计，我们叫做舱壁，对吧，然后也就是说你的船舱跟船舱之间是相互隔离的，对，那对于我们硬，就即使说一个呃，船舱漏水，它也不会去影响其他的床舱，那这个对于我们一个分布式系统设计有什么启发呢？其实。

在一个，尤其是云上的这种，不管说你是云，呃微服务也好，还是说sola也好，它本身仍然是一个这种分布式系统，对吧，那我们我们还是要去引入类似于比如说超时、重试、回退、熔断等等这样的机制，来保证各个系统之间的隔离和稳定性，比如说刚刚那个case，对吧，然后我如何去确保我的执行时间对吧，可以控制在一个合理的范围，不会说从六七毫秒到60毫秒，因为它带来的这种呃问带对对于后端数据库的压力，以及说其他周边弧的压力可能会很大啊，所以其实解决这个问题其实也很简单，我只要把超时时间，比如说设置到十秒，十毫秒，或者说15毫秒就可以解决这个问题啊，或者一定程度的去缓解这个问题。

OK，然后我们再来看另外一个挑战，这个挑战呢，其实更多的是跟我们应用设计方法相关，然后大家其实刚刚今天有很多关于微服务的话题，那大家如果说熟悉微服务的话，应该也会听过这个概念，我们叫做分布式单体，叫distributed mon，也就是说虽然和单体相比，虽然说我采用了微服务架构，但是我并没有真正的获得分布式系统的便利。你的应用，如果说你需要把你的某一个服务跑起来，然后你需要去把所有的应用部署一遍，然后才能测试这个API，然后服务跟服务之间有很长的链路调用，甚至出现这种双向循环依赖的问题啊。然后就会增加你整体这个分布式系统的复杂度，对，所以对于这种这种分布式单体是我们要去极力避免的啊，有可能你如果说采用这种分布式系统，它真的还不如你去用一个单体应用啊。

好，那回到比如说service应用设计同样有类似问题，然后早在其实我们可以看到在2019年的时候，然后soworks的技术雷达上其实提到这个概念叫做拉姆塔拼爆啊，其实它表示的这个问题其实和这个呃我们刚提的分布式单体其实是同样的问题，就是我在对整体的这个应用去进行一个更加细力度的切分时，我可能不是微服务级别或能是函数级别，那一旦说你的这个函数切割的细度细力力度更细，那有可能会导致更难更多的集成和这种集成，呃，函数和函函数之间的复杂，复杂度可能会可能会很高，所以这个也是我们要在这个so应用设计里面去极力避免呢？那如何才能去找到一个合适的力度呢？比如说对于一个应用，我要去建多少函数。每一个函数，它的边界我要怎么去考虑，背后是需要一整套这个方法论的啊。当然肯定是跟你的业务关联的，但很多时候我觉得应用设计，尤其是模块设计，模块边界的定义肯定是不能靠拍脑袋的，所以怎么去解决这样的问题呢？

啊，然后我觉得这里可以看一个具体的例子啊，然后因为同样比如说同样是音视频处理，然后不同场景呢，然后其实对于这种这个呃并发能力的要求是不一样，对吧，比如说像呃拼接对吧，我需要这个呃。我需要六六七十毫秒处理完成，对吧，比如说登录视频处理，我需要十分钟处理完成，然后多录视频，我可能需要这个更更长的时间啊，它每一种这个场景对于函数的内存消耗是不一样的，是吧？那我们在做service应用设计的时候，一定需要去找到一个合适的力度，如果说你把所有的这个逻辑全都放到一个函数里面去处理，那你至少需要有两GB内存才可以支撑这个应用正常运行。但是如果说你通过一个更加合理的系统的拆分吧，有可能你可以把它拆分成三个函数，每个函数可以去使用自己更加适合的一些这个内存设计，我们可以看一下这个具体的一个成本。

呃，大家不确定大家能不能看到啊啊，然后左边这张图是2048兆，然后右边这张图是512兆，然后这是非常典型的这个service的，就是云函数的这个计费方式，我们可以看到价格的差异是多少啊，大概将近四五倍左右啊。好，那怎么去找到一个合适的这个fast应用的一个边界呢？我觉得主要主要有几个考虑因素，首先第一点就是触发弹性伸缩的因素，然后其次呢，我们要考虑比如说所占用的内存，然后能启动，以及说单个请求的平均处理时间，需要综合去，呃，综合各个因素去看。好，除此之外呢，然后我们知道在做微弧设计的时候，有一个非常典型的一个方法论，我们叫做领域驱动设计啊，大家应该或多或少都听过或者实践过，比如说我们在做领域推动设计的时候，一个非常呃还是比较奏效的一种方式呢，比如说我们去做事件风暴，叫even storm，通过事件风暴这种形式去梳理你的应用，然后它最终能够去，它其实是一个指导你去做微服务设计的方法论。但回到说so应用设计，其实同样适合我认为说我们在因为本质上来说，它其实是做一个基于业务视角的一个粗力度的划分啊，所以说我们在做这个so的信用设计的时候，仍然可以去沿用领域设计，领域驱动设计的流程，首先从业务视角，然后根据你的业务，不同的业务上下文去进行一次粗力度的切割。

然后除此之外呢，当然这个其实是属于oop的流派，就是说面向对象编程的流派，我们知道在这个除了oop之外之外呢，还有另外一种套路，就是FP是吧，也就是说函数式编程，那对于函数式编程呢，其实在这里我个人比较推推荐的一种方式，我们叫做类型流啊，当然这个是我是可以为前同事一起去实践过，呃，在真正项目上去实践过这种这个领域建模方法，对于这种方法，我觉得它跟S应用S应用设计其实非常契合的啊，因为本身它有一个非常重要的概念，就是说我基于一个业务流程，然后我首先我把业务流程梳理出来之后，然后我会去做一个这个有状态和无状态应用的切分，那熟悉函数编程应该都听过，就如果说一个函数它没有输副作用，也就是说它的输入和输出，不管说在什么条件下，然后执行多少多长时间，固定的输入一定会产生一个，呃，固定的输出啊，然后我们管它叫做传函数，那这样的传函数其实可以非常完美的去映射到一个fast应用里面去。

那一个传函数有可能就对应云上的一个云函数。然后另外呢，然后我觉得它更重要的一点呢，其实就是说在研发效能方面，它可以去促进这个研发效能的提升，为什么这么说，因为在一个大型的团队里面，对吧，一定要考虑一个问题，就是说我要去怎么去做团队分工，那比如说微服务这种形式，我可能会要基于微服务，对吧，然后你负责服务A，或者你负责服务B，这是组建组建方式的划分，然后另外一种形式呢，可能是基于业务活动，对所有所有人负责所有活动，然后呃，然后根据从业务视角去切分，然后我我认为说这种这种这个设计方法提供一个新的思路，然后我们可以从这个函数级别去去去去去区分，对，然后比如说我们在拆分之后，有不同类型的函数，如果有些函数比较复杂，它涉及到一些这种有状态的应用，比如数据库连接，我们其实可以去，比如说交给一些更加资深的同学去处理，对于新人来说，我可以去处理一些比如说更纯函数，相对来说简呃，复杂度比较低的一些这种函数。

好，然后我们再快速看一下落地案例分享对吧，然后这是我们一个教育行业客户，然后我觉得可以主要关注一下它的一个效果，然后再采用这个so的方案，之前呢，然后他去做音视频处理，然后所有六七千个视频继续进行一个转码，大概需要这个一个小时左右，然后我们通过迁移到云函数，可以在这个十分钟之内，可以在十分钟之内拉起6000到7000个函数实例并行去进行一个音视频转码，可以把整体的时间缩短到十分钟，那对于客户来说，这个其实本质上是一个产品竞争力以及以及用户体验的提升。

好，我们再看另外一个是全景录制，然后除了说音视频处理之外，然后函数里面还可以运行一个Chrome浏览器去直接进行一个录制，然后这也是这目前也是目前我们最近推出这个解决方案之后，然后也是受到各种各样教育行业，或者说有直播产品行业的一些这种呃客户的欢迎。然后另外一个场景呢，其实就是搜斯见证，因为对于很多前端同队来说，并不是很了解一些基础设施设施的一些知识，比如说你让一个前端同队去学习这种云云服务，然后还要去搞一个高可用架构，弹性伸缩，其实是有很高的学习成本了，对，所以我们目前就是service方向，就云函数，其实有很多建站的场景，比如说我可以用SSR，我可以把传统的这种外部应用啊，或者说ne JS express JS，或者说API啊，或者说是一个站点直接迁移到这个云函数之上，然后从而直接可以获得，比如说第一按量计费，对吧，然后成本，成本综合的这种性价比更高，然后第二呢，就是弹性伸缩，你不用去考虑它一个容量计划的问题，对，所以在这个场景，我们有很多客户去做这种广告营销类的，然后在这在这个方向其实也比较欢迎，比较受欢迎，因为你在推推出一个这个广告营销活动的时候，其实很难去预测我这个营销活动到底它能够带来多少流量啊，有可能它就是一个爆点，但真正爆点来临的时候，你再去准备你的计算，计算层的资源。

其实往往是呃，还不够你的，你的效率是跟不上的。好，我们快速看一下相关的系种趋势展望，我觉得首先第一点呢，就是service plus X，然后这个我觉得在一开始其实已经提到了啊，就是未来我我相信说未来更多，越来会有越来越多的对吧，然后以so形态呃出现的这种，比如说产品啊，数据库也好啊，或者说中间件也好啊，首先就判断它是不是一个solo产品呢，我觉得肯定有两个非常重要的特征，就是第一是不是按量计费，那第二是不是弹性伸缩啊，它是否可以具备，然后弹性生缩的能力，可以去比如说从一个物理集群扩，扩充到更多的物理集群，然后另外呢是service有可能对于开发者来说。

对于用户来说，你并不用去关注什么叫sola，这就好像说我们再去使用一个SS服务的时候，我不用关注它是布在KS上还是布在虚拟机上，但是底层它有可能是用service或者云函数来执行的，所以这里我们叫做service engine，也是因为service本身它这种特征可以带来整个产品的这种呃性能，以及说它的这种综合的这种竞争力的提升。好，然后另外是DX，这里DX指的是开发者体验，因为相对来说在开发者体验方面，其实呃相对来说工具还不够成熟，在这方面比如说我要去考虑我的代码怎么样快速同步到云上，然后在本地如何去做调试测试，然后在这方面其实还有很多这个工具可以可以看到相关的这种领域的工具会呃越来越多，然后最后一个是方法论方面，然后我们刚才提到了，比如说一些领域驱动设计这些方法论在未来能够看到在方法论实践以及说一些方法论周边的工具啊，会呃会越来越多，嗯，好，这是我今天呃主要分享的内容，好，谢谢大家，好，掌声送给我们杨老师，那么接下来就是向我们杨老师进行提问的环节了，现场的小伙伴们赶快举手进行提问。

说他很频，一会要求扩容，一会要求容，该怎么办呢？呃，这个这问这个问题非常好，这不就是场景，但是可能。可能他的要求可能是有问题的，就是可能是有异常的，你应该怎么处理这种问题呢？啊，你是说弹性伸缩过程中会有异常是吗？对啊，就是我觉得这是一个很，就我觉得主要看它的一些异常类型啊，就首先我觉得其实在做弹性伸缩的时候，最关键的它其实是触发能启动，能启动对吧？我觉得很多时候这种问题是由于我们在做应用设计的时候，然后你的冷启动时间太长，当冷启动这件事情呢，不仅仅是平台的能力，从平台侧我们可以去做很多优化，对吧？比如说代码缓存啊，或者说VPC一些策略去加速，对吧？这些都是可以去做的，但是我认为还有一部分职责是需要开发者去考虑的，比如说你一定要在你这个函数里面启动之前去初始化一个庞大的这个数据库连接，对吧，然后去做很多IAPP访问，或者说去做一个大量的这个数据库缓存，这些其实都是降低，你提就是也会导致你的能启动，能启动性能非常差啊对，所以因为冷启动本身从平台。

一定是有一个这个时间限制啊，所以我觉得这是一点嘛，然后其次就是可能还是要考虑一些，呃，除了说应用应用级别的优化之外，对吧，然后其实还要控制一些我们的一些这种输入的一些这种QPS，比如说你如果说直接是HP调用的话，它因为都是同步调用，它一定会去触发，它触发能启动这种几率会更大，对吧？但是如果说你在前面加一个消息队列，通过消息队列这种消峰填补的方式，可以比较大的去缓解你感提到这个异常的问题，嗯嗯，好，还有一个问题，就比如说那个流量突然嗯暴涨，然后谭先生说来不及怎么办呢？就刚刚说如果加下去更加可能会有延迟的，对，这个也是一个比较普遍的问题啊，就是虽然说我们刚才提到平台级别的一些扩容能力的，比如最低是每分钟500，但很多时候如果说你的这个瞬间并发比较高的话，这是没有办法满足的啊，所以我们很多呃，So平台的产品都会提供一个叫做预制并发啊，预制并发的一个功能，也就是说它甚至支持一些这种定。

时定时器啊，比如说我可以在这个高峰期来临的前十分钟或者前20分钟，提前把我这个几千个函数实力拉起来啊，然后在这个呃，业务高峰期过后之后，然后我再去把这个资源回收啊，然后因为尤其是对于很多业务，其实都是有比较典型的这种波波谷的，那比如说在线教育的一些客户对吧，那一定就是说小朋友这个呃，放学之后，对吧，比如说七点到晚上九点或者这个时间段，对其实还是比较容易去判断的波峰波谷，那可能预预料不到，比如说你当时预料是5000个实力嘛，但是可能5000个实力也满足不了。

呃，就是预知并发是平台级别可以去提供的，就是你要去可能还是要根据你的这个实际的运算效果去预估一个值，对吧？但是它并不代表说你最多就可以用这么多，用用这么多的函数，它其实如果说超出这个上限，然后函数还是可以自动扩容的，但有可能会触及到刚刚那个平台级别的限制啊，然后我觉得，呃，对，这是一点吧，就是我觉得另外一点呢，其实你即使说用虚拟机或者其他的这种方式去作为你的这个计算负载，我就要考虑另外一个问题是说扩容效率的问题吧，你可以说我可以用虚拟机，对吧，也会遇到类似，就是你看比如说我用函数，我也需要去做容量计划，对吧，那如果说你用虚拟机的时候，你出现了这个性能瓶颈，你要去扩容的话，它的时间单位可能是小时甚至更长的时间，对吧，但是对于函数来说只是改一个配置的问题，我们可以在后台很轻松的就把你的这个呃上线，然后提上去，然后可以从来可以去支持更多的函数实例，对，嗯，好，谢谢老师，诶，好的。

还有现场的朋友们想要提问吗？啊，杨老师你好，呃，就是我有一个问题，就是如果从传统的BS或者CS的那种架构转向那个，呃，大致上有几个步骤，呃，以及这些步骤当中有什么要重点关注的技术点呢？呃，如果是从我们先看一下，比如说对于一些这种典型的这种CS架构，对吧，其实对于很多CS架构来说，如果说是典型的这种，呃，典型的这种比如API调用，其实比较简单的，无非是说你服务端换了一个运营环境而已，但你客户端和服务之间的交付，其实还是采用类似于这种标准的IP协议对吧？这个其实整个迁移过程其实比较平滑的，但是对于这种形态的应用呢，然后我觉得尤其是一些这种，呃，CS价格里面会涉及到一些长链接问题，比如说你有一些这种web socket对吧，但是这种web socket常链接的形式呢，它其实是跟fast这种形态是相违背的，因为对于fast形态来说，你没有办法去做这个。

呃，Assumption就是假设对吧，然后它并不会一直运行在这里，那如果说你的容器实力被回收的时候，那一定会导致你的长链接被断开，对，所以说我觉得这是一个需要去考虑的问题，可能需要去考虑一些其他的解决方案来解决你的这个长连接问题，或者说你在前面加一个网关，从网关到客户端是一个长连接，从网关到函数这边是一个短连接啊对，我觉得这是需要特别注意一个问题，然后另外一个是我们刚才提到的这种BS架构吧，因为呃在呃BS架构，然后对于BS架构的话，其实我觉得solo应用还是比较典型的，刚刚我们其实提到了一些这种，呃前端团队吧，然后在采用这种呃很多呃类似这样的解决方案吧，然后尤其是他们用的比较多的，其实还是一些，因为其实我觉得更多是一个组织分工的问题吧，然后你在真正去考虑说我要用so的时候，并不应该仅仅是说我换一个运行时，还需要考虑说我如何能够去最大化它的一个的这种潜力，我觉得一定是跟研发效能相关的，那对于之前的这种分工。

方式，我我的后端API可能需要说一些，比如go啊，Not GI go啊，或者说或者说什么呃，Go或者Java对吧，这种掌握相关语言的人才能提供API，那我如果说切到这个so之后，一个前端团队我可以直接去写API对吧，然后比如底层，比如团队里面可以提供大量的这种重复可复用的这种API，然后我可以基于note JS或者express，我直接去对于后台API去组装，那这样的事情其实以前是由后端团队状盘去做的，那这个事情我们现在可以由前端团队来做，对这个意味着说我不再需要等后端的研发排期对吧，从而实现整个应用的开发，可以在一个团队里面自闭狂，对，所以我觉得这是可能不是一个纯技术的问题，对，好，谢谢老师，诶好，现场还有小伙伴吗？

好，那就感谢我们杨老师的专业解答和精彩的分享，掌声送给我们杨老师，谢谢。接下来有请我们腾讯云托管高级工程师邓南京老师给我们带来云原生时代前后端分分离开发新思路的主题分享，大家掌声欢迎一下，下面时间交给我们邓南京老师，各位开发者大家下午好啊，我是来自于腾讯云开发团队的郑南京，反正我今天演讲的一个主题是云原生时代前后端分离开发的一个新思路，呃，刚才那个杨老师呢，他是讲了很多的一个service的概念，同时他是从那个bus形态去讲的一个产品，按照现在我着重是从那个bus形态去去讲这个，呃，我们的这个方案。呃，这个是我今天演讲的一个大纲，首先我会先介绍一下我这个方案啊，之后，呃，后面会讲一下使用的一个方法跟一个案例。

呃我们我今天演讲的这个呃方案呢，同时也是呃小程序呃官方的一个后台托管的一个解决方案，就呃我们呃云开发团队呢，一直以来都是跟那个微信小程序团队都都是在进行一个深度的一个合作。呃，这个是我们那个微信云托管的一个产品的一个架构，呃我们这个新一代的云原生的应用引擎serviceless on呃，K，呃提到那个service on k，如果大家有了解过形态的可能会听过那个connect，呃connect的话，它是那个Google呃发布的一款那个service呃的一个架构的一个产品，呃它的一个最大的一个特点就是呃它的实力可以缩容到零啊，就我们这款产品的话，呃事先容那个connect生态的支持，那个实力缩容到零，这这这一个功能，呃我们从那个呃上面最上这层可以看到我们的一个呃用户端的话，可以是小程序或公众号，Web或者是一个APP，然之往下的话就是说我们的一个呃，呃应用业务代码它是一个呃。

呃，语言无关，框架无关的一个呃，一个设计，你可以是Java，也可以是spring cloud或double，也可以是PHP或node JS，也可以go，只要你的代码doer化了之后，就可以使用我们的语音托管进行一个呃运作，反正我们的一个底层的话是基于那个呃K8S的，呃往下的一个计算就是一些计算存储网络，一些资源池，呃同时我们这边提供了一些通用的一个能力，就是将开发者再开发一款那个应用的时候，他从开发到上线再到运维，整一个生命周期，一个闭环，这个功能我们可以看到，我们这边有个安全防刷的一个功能，还有个域名备案，呃，我相信大家在，呃就是说在开发一款应用的时候，肯定会遇到一个问题，就是说我去申请一个域名，呃，申请完域名之后，我可能需要等大概呃那么一两。

两天的一个时间，但如果使用这个云托管的话，只要这个服务部署起来，我们就会自动的为用户产生一个域名，并且会备案啊，就还有一个是那个呃监控告警的一个模块，呃，同时我们这边也支持一个呃日志管理，如果说你自建的一个一个应用的话，你可能需要搭一套呃EK这个去采集一个日志，但呃我使用云托管的话，我们会自带这个能力，同时我们也会提供一个持续集成的一个能力，还有个多环境的一个网络隔离的一个管理啊，同时呢，我们这边最近接入了一款就是一个service形态的一个MYSQL，呃。

在就是说在你的程序没有没有用量的情况下，这个service形态MYSQL它它会缩容到零，然就当你有流量的时候，我们会自动的呃把这个MYSQL给拉起。呃，然后还有一个是灰度，灰度发布的一个能力，然后这个灰度发布的一个能力，主要是说我们现在呃针对一些中小的一些呃开发团队，可能就是说在他的一个发布上线的一个规范，可能会没有那么规范，所以我们就有一个呃发布管理，同时提供一个灰度发布，就是呃灰度发布其实就是那个呃K8S概念里面的一个金丝雀发布的这样一个概念啊，同时我们也可以提供一个单独的一个公网访问，单独的一个公网访问的话，就是针对于公众号，Web或者说APP这种呃多端的一个一个提供的一个能力。

呃，同时呢，我们跟那个小程序那边是深度合作的，就提供了免健全加速调用那个微信open API的一个能力。呃，这是一个传统的一个开发模式，跟我们这个云托管的一个模式的一个对比啊，我相信大家就是说开发一款新的一款应用的时候，呃肯定是呃经历过这样一个流程的，首先我肯定是，比如说在腾讯上面我会先申请一个VPC，呃这个VPC就是一个用户级别的一个CN的一个网络完之后我再去购买一个呃服务器，或者说购买呃比如说呃，呃t ke1或EKS这种这种一个容器的一个集群啊，就在将我们的服务部署到这个服务器啊，同时呃，一般说我们的一个程序都会有一个数据型呃关系型数据库的一个依赖，呃，同时我们还会去购买一个负载均衡呃。

腾讯云的话就是一个CRB啊，就把这一套东西啊，就申请完之后呢，我估计大概大家可能都需要大概一天左右的一个时间。呃，然后这个是传统的一个开发模式，就是呃，我们的一个比如说我们的一个微信小程序，它是通过一个公网，直接走公网去访问到我们的一个负载均衡，再到我们实际的一个业务后台啊，就使用一个微信云托管的话是这样的，我们直接把用户的一个代码直接托管到我们的这个云托管的这个集群里面，就说你的你开发完代码之后，你只需要加上一个do file直接容器化之后，完之后我们会呃把你的代码啊，就自动构构建成镜像，要部署在我们的云托管的一个K8S集群上面去啊同时的话，我们这边现在呃是提供了一个呃，Service形态的一个关系型数据库，呃后面的话我们也会有计划接入一个service形态的一个no circle的呃，像red这种这种呃数据库。

然之回到我们这个前端调用的话，嗯，我们这种新的模式走的是一个微信的一个私有链路，呃私有链路的话，再到一个微信在呃全国的一个就近接入的一个点，然后就就近接入之后呢，然后之后就会走一个腾讯的一个内网的一个专线调用，这里可以避免到一个公网的一个呃波动影响到我们的一个请求的一个时延。然之后呃，使用这这个新的一个开发模式，它有一些什么样的一个优势呢？呃，首先第一个它能够大幅的去降低我们的一个成本，呃。首先从那个传统模式下，我们开发完呃一个接口的时候，肯定会经历到一个这样的过程，我们肯定会先对我们的接口进行一个性能的一个一个呃压测，比如说我们这个接口，呃比如说我们的一个平均的一个耗时，比如说是200毫秒反这我们呃比如说一台一核的一个一个服务器，那它一秒钟的一个QPS，比如说能砍五然之后我们会根据我们的这一样一个接口性能去先预先的去申请呃一批的一个，比如说CBN的一个机器，那这样子的话就是说呃同时呢，我们可能作为开发者可能会经常遇到这样一个问题，比如说我呃那个产品说我几天之后我要做一个活动，那你我提前就是说通通知开发者帮我，呃，就是说先帮我买一批那个呃服务器，然后支持我们几天之后的一个活动。

啊，就我们申请完那个服务器之后，相当于说有几天的时间可能是一个呃呃浪费，就是说那个CBM机器可能是一个浪费的一个一个情况，但使用这个云托管的话，就是说我们没有没有必要就说提前的去采购这个资源，我们可以根据那个业务的一个流量进行一个动态的一个扩缩容，呃，像我们之前对接的一些客户的话，就是说使用到我们的这个云托管的一个产品，它的一个呃，平均的一个那个。

呃，那个呃资源可能就是说那个成本，呃优优化了大概有将近30%左右。按照呃，优势二的话，就是我们的一个链路是非常安全的，按照传统的模式下，你可能就是说呃，走那个address，或者说HTP，按照呃。访问到我们的一个后台服务，同时我们的后台服务呢，肯定是会申请一个一个域名，反之后你申请完域名之后，呃，可能就会被一些就是说有心的一些一些攻击者去扫描你的一个一个一个接口扫描，扫描到你的接口之后，可能就是说去对你的这个接口进行一个呃刷你的接口，或者说DDOS攻击你这个这个接口，那这样的话就是说一般的话，这种应对方式，我们肯定是说在我们的域名之后，然就挂一个高防的一个IP，但实际上就是说防DDOS这种高防的IP，它的费用其实也是挺昂贵的。

反之，如果说走我们的这个微信云托管的这个方案的话，我们是没有没有必要在那个公网去开辟一个入口的啊，直接走的就是一个微信的一个私有链路，然之走微信私有链路的话，你用户你通过那个控制台包这种方式，你是抓不到我的一个接口的，因为我们走是微信的一个私有链路，微信的私有链路这个是非常安全的，如果说微信的你能破解这个微信的私有链路，那整个微信那那它的安全也也就没有了，所以说这个是非常非常难以破解的。

啊，这时候我们的这个，呃。内，呃，微信的一个链路，再走腾讯的内网的话，就是说你的一个DDOS的费用就可以减免了，然就另外一个你接口被刷，这个现在的话就是说走这个基本上就是说你这个攻击者他是没办法感知到你的一个接口的，所以说这个也基本就是零了。啊，那下下面的话，我们再看一下优势三的话，就是一个请求的一个加速，你走那个呃，公网访问，比如说你的你的应用你可能部署到比如说呃。呃，广州反正你实际的一个开发者可能是比如说在北京或者说在上海，我们都知道的话，就是说，呃，比如说你从广州到到上海，它的一个TCP的一个RTT链路就要30毫秒，如果说你到北京的话，那可能就是一个翻倍，如果说走我们的一个腾讯云的一个就近接入点的话，这个。

这个链路的话，那就可以享受到我们微信的一个网络的一个基础建设，呃，它是一个更稳定的，就是说呃，微信的话，在全国各地一般都会有会有一个就近接入的一个点，接入到这个点之后，走一个腾讯云的一个一个大的一个骨干的一个内网专线的话，这个速度是可以得到保证的啊，这个同时的话，走这个微信云托管的话，就是说它可以做到一个免健全，我们在那个。调呃就是呃，前端调用的时候，我们那个微信测会把那个健全跟在那个HTP的一个head里面，把那个微信小程序相关的1OPEN ID，然后就会会种到这个head里面去，然就到我们的后台服务呢，就可以直接的从我们的一个HTP的一个包头里面去取到这个open ID，那我们需要一个用户的信息的话，就可以免去的一个O的一个多次交互的一个一这这样一个耗时的一个减免。

反正我们看一下一个迁移的一个成本，呃，前端的话就是说，如果大家之前用过那个小程序一个开发的话，只需要把它的这一个调用改成这个Co container那就OK了，然这对于一个后后端的一个改造成本的话，就是说已经容器化，这个是没有没有必要再再改造了，之后如果说为容器化的话，可以增加一个do file即可，按之后我们云托管呢，现在也提供了Java PHP go等这样一种模板，呃，同时呢，我们现在也在去调研一个如何做到让用户能够更加快的牵引到我们云托管的一个方案，就是免多可化，呃，如果说大家有关注过那个M总的那个APP to container的话，他他有个功能就是说你用户。比如说呃，它那个虽然说目前只是支持一个Java的语言，他就说你你的一个Java的语言，你不需要去写一个do file，我使用那个工具的话，就可以自动检测到你的一个代码，然后就自动为你生成一个docker file的一个。

呃，自动就免do file，自动帮你生成一个镜像，同时呃，比如说Google的一个cloud的话，它有一个工具叫那个build pack，它也是实现这种免do file的这样子一种功能，就是说对用户可能对开发者可能会更加的一个，呃，就是说不需要太深的一个dog file的一个知识。这个这个也是我们，呃，目前最近在探索的一个方向。完之后，呃，我们再看一下微信云托管的一个更多的一个功能，我们可以实现一个环境级别的一个隔离，比如说你一个后端服务，你可能有一个开发环境，或者说有一个线上环境啊，就我们可以实现一个你。呃，两个环境之间它的一个网络隔离，不会说因为你在开发测试的时候，误掉了一个线网的一个负一个服务，造成一个线网的一个故障完之后还有一个是一个免运维，免运维的话，基本上只要是service形态都会有的一个就是免，免去了你扩缩容的一些运维操作之后，还有一个灰度发布的一个能力，就是说呃，我发布新版本的时候，我可以灰度你的一个open ID，或者说我呃灰度多少用量到我的一个新版本啊，那同时我们支持一个镜像构建，就你的源代码，然后就。

构建成为一个镜像。反这微信云托管，呃当然也也有一些技术优势，就是说我们可以支持一个比较呃细力度的一个资源控制，如果大家买过CDM的话，应该会知道它的一个最小的一个规格应该是一盒，反之我们云托管提供的是0.25核的一个规格，反之后还有个突发场景的一个快速扩容，呃我们的一个容器扩容的一个时长，从你去呃去装向一个虚拟机，再到拉镜像，再到你的一个呃那个HT不呃那个K8S的那个呃，Readines跟life那个探针探探活成功大概是需要一个20秒左右，呃呃，刚才应该那个杨老师那边应该有回答过，就是说应对于一些，呃就是一些突发的一个流量，呃，其实那个开源的K8用的就是一个hpa啊，这种hpa的话，对于比如说呃，它的一个扩容的两两个因素里面有一个是一个10%的一个波动因子。

还有它的一个扩缩容的一个冷静期，比如说你的一个应用，你调的一个CPU，它的一个。扩售用的阈值，比如说是80%然就当你当你的实际的一个呃，CPU的一个容量呃之后扩大了大于了10%这个波动因子之后，它就会开始进入一个扩容的一个统计期，就它有个三分钟的一个一个一个冷静期，就是说如果说你的这个呃应用，比如说你在第一分钟可能我90%然就然就比如说一分零五秒的时候，它又变成20%，这个时候实际上是不会扩容，因为它有个一个冷静期在那边，那就应对于那个突突发场景的话，其实呃有有个那个定时那个扩容那个，呃刚才那个杨老师也说也说过这种这种场景。

然后第三个是我们支持那个缩容到零，就是说当你的呃服务没有数据流，没有流量的情况下，我们我们会把你的这个破啊就缩容到零，缩容到零之后就是说我们是按需按需收费的，没有流量的情况下，我们是不会收费的，按就。说到零的情况下，当你下次有那个请求过来的时候，我们会有一个零到一的一个过程，这个零到一的一个快速，呃，能能启动的一个时间，我们大概是能做到五到30秒左右。

按照这个是微信云托云托管跟一个服务器的一个一个对比，呃大家可以看到从那个安全性方面，然就呃公网呃服务器它是公网暴露接口的，我们是微信的一个私有链路啊，部署方式的话，我们可以支持镜像部署，按就健全的话，就是说你自建的服务器需要自己后台服务做一个健全，反正我们这边是免健全的，反之还有一些环境隔离灰度版，呃版本灰度这些服务器的话都是基本上这一整套的话都是服务器需要呃需要自己去建的，反正种使用的我们微信云托管的话，我们会，呃，当你版本创建起来之后，我们会自动的打通从用户到我们后台服务这一条完整的一个数据流。然后还有一些监控告警，我们会支持一些CPU啊，内存呢，还有一些调用次数，你配的一个告警的阈值的一个告警。

反正那怎么样去使用我们的一个微信云托管呢？呃，我们这边的话就，呃，首先是我们会创建一个云环境啊，如果说大家使用过那个小程序开发IDE的话，可能会觉得这个好像长得不太一样啊，没错，这是我们在今年上半年就是说新推出来的一款产品，之前的那那个那个主要是放在那个小程序ID上面，它可能的一个受众的一个群里，可能是前端啊之现在的话，我们是针对于那个后后台的一个解决方案，就新剥离出了这样一个入口，同时我们会支持一个my circle这样一个service形态的一个数据库存储。呃，网络类型的话可以就选，呃，我们自动帮你创建一个VPC也可以，如果说你之前有绑定过一个云上的一个一个账号，有自己私人的VPC的话，也可以复用自己的。按之后，呃。我们的一键部署就创建一个新的版本，我们呃支持就是三种镜像，呃拉取，就是自己在本地打那个镜像啊，就推到那个CCR镜像仓库，我们可以拉取啊，之后另外一个是那个呃get代码仓库，或者说你本地的代码直接上传。

反正呃，我这个流水线是我们最近新推出的一个功能，就是提供一个持续集成的这样一个能力。完之后还有个灰度发布的一个能力，呃，就我们在一些就是一些中小的一个创业团队的话，可能就是说发布的流程可能会经常有遇到不规范的，比如说呃，我A同学有个版本，按照B同学有个版本，如果说没有这样一个严格的一个发版的一个流程控制的话，可能会造成一个相互的一个覆盖。反正我们再讲一下一个案例实践，呃这是一个云开发，就是呃云托管跟一个呃呃创造营的一个活动吧，这个活动刚上线的时候就说呃发现呃，就是说那个暴露在公网的那个接口，会有用户刷那个票的一个行为，反之后面就是说呃他们找到我们之后，然之后我们就把那个。

把他们的一个开发人就接管过来，呃，然后就呃，因为有个微信私有链路的一个安全保证的话，这就解决了他们一个被被刷单的一个问题。呃，这个是一个微信支付的一个案例，就是说呃他们之前有搞一个扫码领红包的这样一个一个活动啊，就这个活动的话，在那个弱网的环境下，它打开是比较慢的，呃第一步单只影响他的一个体验，可能会造成一个客户的一个流失啊之就是呃经过他们的一个分析之后，呃就会发现呃第一个他们的一个DM，呃DMS在弱网环境下，这个解析会比较慢一点，因为它要呃就是一个递归的一个去解析啊，之后另外一个的话是那个他的他们的一个呃健全就是说。

呃，用户扫完码之后，要进行一次O2O协议的一个认证，这个流程也是比较长的，反正我们途中是拿一个国外的一些环境来进行一个模拟，弱网的一个环境下得出来的一个解析，解析时间的一个一个对比图。然后就是后面他们切换成为我们一个，呃，云托管的一个一个域名，就是走他们的一个私有协议的话，就是呃，还有个走我们的一个。呃，微信私有链路的话，那个微信他们那边的一个MS，他们有做一个优化，他会缓存一些解析的一个结果，所以这个的话就是呃，给他们的一个DMS解析一个提速了，反正另外一个是那个我们走那个云托管这边进来的话会呃天然的一个免健全自带票据，所以也就不需要进行一个o2.0的一个协议的一个登录，然后就最终的话就实现了他们的一个秒开。

这个是最终他们呃，图上那个红色的那个箭头，就是他们切换到我们，呃，就是一个云开发的那个云托管的一个域名之后，他们的一个请求的一个耗时，直接从一秒变变成了560秒完之后实现了一个秒开。好，呃，我今天的一个分享就到这，谢谢大家好，谢谢我们邓老师的精彩分享，现场是否有我们的朋友们想要向我们邓老师进行现场提问，请各位可以举手进行提问。啊，你好，我问一下，就是我们这个刚才讲的那个方案里面的那个MYSQ的实例的数据有没有好的方有有没有什么方式能够我落到本地的库或者其他的地方啊，落到本地的库是吧？啊是这样子，那个我们腾讯云上面有个工具叫那个DTS啊，DS的话可以允许你把呃，它可以支持一个双向的，你可以把你的比如说自己的一个一个MY自建的MYSQ，或说一些有箱的一个MYSQL数据源都迁移过去，同时也也支持就是反向的，这个可以到那个腾讯云的那个DTS那边去了解一下啊好的，那他那个回头，比如说他的流量啊，这些是按照内部来算还是怎么样啊，你说那个迁移的一个成本是吧？哦，迁移成本，因为这是另外一个产品，所以说那个计费这块我们是没有没有工具是有的，对工具是有的，另外就是其他的，就是说比如说因为像MY嘛，那剩下的可能像啊这一类的，我们可能都需要，那这个后续有计划没有对。

其实我们在推出这款产品的时候，就是有一些呃开发者也提到过，我们现在有一个呃关系型的一个service形态my circlel，其实在我们一个一般的一个开发过程当中，肯定需要有一些no呃的，比如说像作为一个缓存嘛，对吧，反正这个也是在我们的一个规规划的一个范围内的。

好好好行好，谢谢好，这边这边有一个小伙伴。你好，你好，就刚刚说的那个灰度发布，我想问一下那个云原生的那个。服务端的那个灰度发布，它是。用的那个兼容变更还是不兼容变更呢？呃，兼容啊，不好意思，没没太理解你的意思啊，就是那个服务端的那个。那个灰度发布的话，你们是用的那个。金容变更还是不金容变更呢？啊，我我们这边是一个金容变更，就是呃，比如说你现在有版本001啊，之后你新的版本它是002的啊，就请求过程当中，我们我们会有一个呃，比如说如果你是小程序开发者，我们会把那个你要灰度发布的一个open的ID，然之后记录到我们的一个流量控制那个模块里面去啊之如果说你是那种相那种呃，公网访问，我们只是一个把一个流量，然后之后切换这样子，比如说你的呃呃零零二两周调30%，那001就是剩下70%，这个这个过程是对于你们的接口是无感知的。

就说你的接口不需要任何变更。哦。好的，下一位朋友，嗯，你好，我我们是做那个传统的那个桌面应用程序的，然后我想问一下，比如说嗯，你刚才说的那个海外用户访问的时候，他有那个网络延迟，嗯，它那个给用户的体验会很差，那就是说他这个怎么会嗯改进呢。

哦，改进是这样的，就呃如果如果说你的一个客户群体是在海外的话，走这一套的话，因为那个呃微信它的一个基础的一个网络建设，它是比较完善，在海外它也有一些呃就近接入的一个点，比如说像CDN这种啊，就接入了CDM之后的话，我们呃呃那个腾讯云的一个内网的话，会有一些国内到国外的一些骨干的一些专线网络，去保证这样一个质量的一个问题，如果说你的走公网的话，可能会说呃，你你到比如说到美国那边，可能中间你要比如说先跳到香港，或者先跳到上海，上海再跳到另外一个地方，这样这样可能会多有会会有多几跳，但是说走腾讯的内网是直通的哦哦哦嗯，还有一个就是比如说嗯嗯。就说比如说他国外的用户，他可能要是我我我们知道我们国内的用户登录的话，可能有微信的这个APP是吧，用手机上或者说扫一扫，那国外的用户可能没有这个微信的APP，就是说咱们这边呃，有没有一种很快的方式能够让他登录上去呢？登录上去是吧？呃嗯，这里的话我可以提供一下我们腾讯云上面的一款产品叫云联网，云联网的话就是说把你的一个呃，云联网的它的一个实现的一个原理，就是说把我们的海外，比如说，比如说全球各地的，呃一些就是说腾讯的一些接入点啊，就通过一个腾讯的一个内网的一些专线都连接在一起。

好好，谢谢你啊，两好，现场还是否有我们的朋友向我们邓老师进行提问，请举手。好，没有提问，感谢邓老师的精彩分享和精彩的解答，大家掌声鼓励一下，到此我们所有的演讲环节就到此告一段落了，接下来是我们本次活动的又一个特色环节，就是我们的TT的开发者说，在此呢，听了诸位专家的演讲之后呢，让我们听一听我们开发者朋友们是怎么来说的，接下来让我们有请我们智领云科技有限公司大数据开发工程师黄如烟为我们进行一个发言，大家掌声欢迎一下，呃，智云科技有限公司大数据开发工程师的郝如烟啊，很高兴参加此活动，与大家一起分享交流。

嗯，我们公司主要专注于大数据领域技术的前沿开发，然后为企业级客户提供数据中台解决方案，然后帮助客户搭建AI和数据中台，嗯。嗯嗯，实现系统资产，然后在系统中统一管理，嗯，搭建。

建立数字化运营体系，而我在日常生活中充分享受到了云计算带来的便利。首先从开发方面说啊，云服务主要提供了完备的开发工具，嗯，提供代码脚手架，使我们开发者能够，嗯。聚焦嗯编写业务逻辑，然后快速完成本地开发测试，然后从开发发布角度来说，通过云原生的模式可以业务无需嗯申请机器，然后发布回收都是秒级别的响应，然后利用平台的嗯天然能力，配合事件网关实现切流，完成机数序测试等。然后从日常运维来看，我们无需关注机器故障嗯资源不足啊机房容灾等传统模式该考虑的问题，然后当业务进程异常时，能够自动完成异常实力的隔离，快速拉起新实力进行替换。

降低业务影响，然后云服务产品，嗯比较嗯，有特点的是它支持按需付费，然后极大程度的提高了资源的利用率，同时降低了成本。当然我们在云延生中也遇到了一些问题，主要是基于云延伸的加速系统如何快速的，嗯，支持弹性缩绒。嗯，有三个方面，一个是渗透实际，嗯，因为传统的服务组件可以是通过统计流量来看他是否达到预值，然后来提高来，呃实现生活嘛，然后调数据，主要是要算统计当前执行的计算算力是否达到了阈值。然后第二个方面是伸出的算法，比如说传统的传统的服务组件主要是算它的，根据它的当前的请求量，然后除以它每个实例可以支持的流量，然后除以它的阈值，然后可以删除它的，嗯，应该应该可以启动的实例数码，然后大数据相应的就是通过统计它执行的算力，然后也是相应的就说呃嗯，计算，然后还有一个是伸缩速度。

嗯，前面那个杨老师也说了，比如说嗯，他有一些可能是频繁频繁伸缩或者是伸缩不足嘛，然后他也是通过啊优化我们啊容器呃镜像的压缩算法，或者是通过预处理呃对镜行进镜像进行压缩，被呃镜像对镜像进行啊预处理或者是缓存。然后。嗯，分享完毕，谢谢大家。好，感谢我们黄如烟朋友的精彩分享，那么接下来让我们掌声有请我们武汉联动时代公司的开发工程师陈佳文先生给我们带来的精彩分享，大家掌声欢迎一下，大家好，非常开心今天参加本次峰会，我叫陈佳文，来自武汉的一名后端开发程序员，目前是在武汉联动公司啊，听这个名字大概。

大家也都知道。我们公司跟。区块链息息相关。我们公司其实主要服务于。工业互联网它主要是通过数据上面来保证数据的安全性，但是我个人主要是开发非Java方面的。呃，工作，嗯，另外也会参加部分容器化方面的运维工作。目前我们公司主要向。市场提供两款产品，面向员工的提供的一个是。欧码系统和我们和我们常用的微信企业微信非常相似，第二款就是一个低代码平台，它主要是面向工业互联网，对常规的底层硬件设备做数据的采集、整合和上报的功能。首先讲一下欧码，其实欧马就是一个。

OA系统的运行框架，所有的应用以小程序的方式注入，这个和我们的微信小程序很相似，也是自己打包HTML上传服务器，然后后端以微服务的方式进行。呃，启动，然后对接自己的小程序包。而欧码也会提供相应的服务，比如说优质服务、权限服务、小程序管理平台等。等服务，然后对对外对内提供对应的API接口，当然这只是一个框架，对内还提供了一些默认的类似服务，就比如说实时通讯服务日历小呃。

任务服务、应用市场服务等等。如果遇到非常重要的数据，我们就可以选择数据上面把它进行安全进行保证。呃，而这一整套的服务。而这一整套的系统。在运维层面上面的压力是非常大的，我们就使用了咱们家腾讯云的产品来对它进行保证。在数据库的层面，My circle p circle mango等等都是采用对应的云产品保证数据的安全，然后定期的对它进行备份，然后类似于静态资源即时通讯里面的upload服务，我们就要使用对象存储来保证提供稳定的静态资源服务。云网关服务，那就是提供一个API流量代理的功能。

当然，最重要的云产品还是容器服务，我们会使用对应的计价服务提供。整个产品的版本控制的功能，然后以及K8S提供测试预发。和生产环境。当然堡垒机是肯定要的，这是对整个系统的安全进行保证。从上面可以看到，其实大大小小的微服务还是特别多，关键的服务我们尽可能的使用云产品。来保证其服务的运行稳定性。接下来就是看一下我们的低代码平台C。主要是使用note GS的框架进行编写，因为我们主要是面向于工业互联网。所以需要使用一个高IO的系统，所以说当时我们就要选型的note GS这门语言。

而二框架是1MUST1N多work的多进程框架，而且消息可以在进程之间非常简单的转发，这使得在更改的时候，对应的model进行update的时候时就非常的快，而前端就对应的使用vuee进行构建和渲染。目前这整套系统单应用的搭建，SS级别的应用搭建已经完成，并且服务于一家海外的物流公司。并且在全国各个。地点已经搭建起子仓库，网点目前也运行的非常良好，下一下一步的打算就是接入fast，整个低代码的目前只是业务层面已经呃完成。接下来。

就是说主要是跟咱们的云产品完全的对接，保证它的运行的效率更高，而且它的性能最佳。当然目前用到的很多的云产品就跟我刚才讲的欧码很相似，在这里就不再一一做出展开。当然低代码的最大的难点其实在整个产品设计和编码上，每一次的迭代影响都是非常大的，对于单元测试、行为测试是非常大的，也要考验，这里涉及太多东西。本次就不展开了，如果说有兴趣的同学可以私底下跟我。私底下一起交流互动，我的内容就以上的，谢谢大家好，感谢陈佳文讲师的这样一个精彩发言。好，你入席就坐。

到此我们今天的活动呢，就到此结束了。