好 各位大家好我们准时开始 就是1点40我们开始今天其实讲的一个主题可能跟OpenStack的峰会稍微有一些不同会介绍一下跟偏应用方面的事情而不是整个基础架构这一块的但是其实后面我也会介绍一下从腾讯的角度来说我们来看整个这样一个生态体系不光是底层的OpenStack以及KBS 微服 应用等等的整个这样一个生态体系我们腾讯这边是怎么样去看的以及说从一个生态圈的角度来说我们怎么样来理解这样一套完整的一套给客户的一套完整的方案先从故事从一开始来讲就是无论说是怎么样类型的客户我们最后交付给客户的真正需要的是把客户的业务或者应用能够非常顺利地好的跑起来无论我们是做云平台我们是做容器平台还是最后我们去做什么微服等等的最核心的理念还是说我们希望客户的业务 客户的应用能够很好的这样做一个运行而在现实过程中会遇到一些什么问题呢总的来说我们总结下来会有这三方面的问题需要去解决第一个是一个僵化的IT架构在做的同学其实如果仔细去想一想的话我们目前在生产环境中所用到的IT架构其实往往是十年甚至二十年之前的一套IT架构整个叫IT架构是没有做这样一个更新迭代的第二方面是一个单一的供应商的问题这个其实从很多用户角度来说其实经常会遇到这样一个问题换句话说我们先期采购了某某厂商的整套IT系统今后我们想做一个转换或去更新升级或去天下新的模块用其他厂商的会变得非常的难第三个是一个增长海量增长的这样一个运为压力运为这个东西十年前的时候并不是非常受到重视因为十年前的IT系统相对都非常简单但十年过去以后我们逐步认为当我们从简单的应用转向了所谓的服务化互联网架构等等运为成为了一个真正的一个平静而目前大量的IT系统是非常难的去支持这样一个海量的运为这样一个问题基于这三个问题的话就需要一个考虑就思考一个问题说怎么样去解决这样一个问题目前有一个词很火叫云原生应用很多地方都在用这边的话今天我会大致介绍一下说从我们的角度来说真正从应用的角度来说怎么样通过这样一种云去解决应用所遇到的这些问题说得更清楚一点的话我希望今后的应用会朝哪个方向去发展我们总结下来就是所谓互联网应用啊等等有这四大第一个是产品的快速迭代以前也许我们去做一个应用可能说我们会花三个月的时间做一个需求分析我们会花一段时间去做这样一个设计然后开发测试等等而目前我们遇到的大量的新兴的应用会有这样一个问题我们是希望在最快的迭代周期内能够出现产生它的价值整个市场变化得非常快的情况下我们需要保证说整个应用以及它整个一开发流程能按这种模式去做这也是以前所不能达到的第二个就是所谓服务化的七成二十四小时不间断也许以前的服务的话你间断间断了几分钟或甚至半天不是太大的问题但现在我们生活或包括我们工作的方方面面都和应用紧密的联合大家可以想象一下如果说微信出了一个什么问题的话我们会中断我们所有的通信所以七成二十四小时这样一个不间断的服务也是一个当代的应用需要去考虑的问题第三方面是业务的复杂组合的这种复杂程度以前我们说的话是一个单一的应用或一个简单的应用提供一个端口等等就可以去实现它所谓的功能而目前的话其实说整个应用会变得非常的复杂复杂到甚至不是一个团队或几个团队能独立开发需要去协作去联合不同团队去做这样一个组合的工作最后提供这样一个应用在这样一个组合的过程中怎么样能从数据层面或设设业务逻辑层面上去实现这样一个组合也是应用需要考虑的问题最后一点就是海量的用户用户变得越来越多我们日常生活中已经离不开任何一个服务啊应用在这个过程中我们怎么样能使一个简单的应用来支撑海量的用户需要去考虑的一个问题基于这点的话其实我们有做这样一个思考和这样一个统计我们其实认为所谓的云计算从07年08年开始云计算它会分成两个阶段第一个阶段我们把它命名为叫资源上云说得直白一点合为资源上云就是传统意义上我们把一个服务全部安装在一个物理服务器上而随着云计算和虚拟机的推广我们逐步把这些服务安装到一个虚拟机上去在这个过程中应用本身没有做任何改动所做的改动其实是底层的架构对应用来说是无感知的这就是所谓资源上云其实资源上云是这个步骤其实我认为到16年17年的时候基本上已经完成了大部分已经从传统的那种服务器物理服务器迁移到了这样一个虚拟机的过程接下来就第二步叫所谓的业务上云或应用上云合为业务上云或应用上云它是另外一个概念就是说前期我们对应用没有做任何的改造该怎么跑的应用无非是从一个物理服务器上跑到一个虚拟机中去了而在后期需要考虑的是应用怎么可以通过利用云计算这些底层基础架构的这样一个优势逐步来提升应用本身的质量说得更直白一点就说前面我列了四个应用需要解决的问题而我们怎么样通过底层的这样一个云计算的基础架构去解决这些问题这就是第二步而应用上云目前遇到的一个困难就是说它和核心利益出发点在于需要应用本身去做这样一个改造而这个应用改造已经不是底层基础设施的问题了是需要和客户使用者等等各方面一起协作去做这样一个应用的改造而这个是目前的一个一大痛点和难点总的来说如果说我们展望一下将来应用和云会是一个什么样的关系大家可以看一下这张图应用更关注于整个业务逻辑的实现而云计算作为一个底层的支撑能力可以提供各种资源的支撑调度 编排等等的工作这边的话我得说明一点这边的所谓的云其实是一个更广易上的云而不只是纠结于这个Ice层面这边的云其实包括比如说OpenStack基础云以及说包括容器包括微服整个这一套我们都认为是一个广易上的这样一个云而底层的这样一个云会给上层的应用提供一个很强的支撑功能使今后所有应用的开发厂商只需要去关注他们自己的业务逻辑而不需要去考虑非业务的比如说怎么样做附带均衡比如说怎么样做高病发怎么样支撑海量用户等等这方面的事情应该是底层云给它去完成的而基于这样一种模式的应用我们认为就是所谓的云原生应用在谈云原生应用之前的话就大致说一下就所谓的整个应用架构占一个眼睛的体系这张图其实互联网上到头都可以看到就说所谓一个单体应用传统意义上我们大部分目前的应用都是所谓的单体应用只有一个挖包或一个假包里面有所有的业务代码包括数据库等等都在这样一个这样一个单体应用中好处是什么呢好处很简单它非常的简便使用起来也很方便但它有坏处当业务变得越来越复杂复杂到我们已经无法独立去维护这样一个应用的时候整个应用已经无法持续发展下去了这个时候就需要去考虑一个问题我们怎么样能怎么样能在这样一个环境下当整个业务变得非常复杂的时候转换这种单体应用的架构于是就是非常火的一个叫微幅架构这张图也是到处都可以看见微幅架构的一个核心很简单就是我一个应用可能说随着它的业务变得越来越复杂它的功能变得越来越多可能有几十甚至上百项功能而微幅架构它希望做的一件事就是说我们如何把这个应用进行分拆以服务化的形式实现和提供每个功能这样的话每一个服务其实是可以变认为是一个简单的单体应用无论从前期的开发维护 部署持续的眼镜都是可以集中在一个最小的单元中去而这些单体这样下微幅通过协作去实现和交付一个真正应用我们所需的这样一个复杂和庞大的功能就是所谓微幅的架构然后接下来看一下这张图如果说是基于一个微幅的架构去实现一个应用本质上它在底层做了哪些工作呢大家可以看一下其实在这个过程中的话我们开发比如说我这边举个例子是一个East Hill就是服务网格去做这样一个工作它虽然说从业务层面来说我只开发两个业务但整个微幅框架在底层其实给它做了很多相关的工作通过类似于Sidecar的机制和控制平面的机制可以在控制平面上实现比如说服务发现断融附带均衡线流等等各种各样的功能都是在底层云给它做了这样一个支撑什么是好处呢好处就是在于在这个过程中从上层的业务来看它是无感知的大家如果看对比一下这张图会发现这其实是一样东西只是从不同的视角前面一个视角是所谓的开发者的视角后面一个视角是所谓的就应用的视角从应用的视角来说大家会发现我应用只需要去开发我自己的业务逻辑也就是这两个service而剩下的那些工作都是有底层的微幅框架去实现的而整个微幅框架的实现过程是自动化的和无感知的对应用来说它是没有任何这样一个需要去额外做的工作这个就是在业界说的说的很多的一种叫那种无入侵蚀的微幅架构的一个好处无入侵蚀换句话说我开发一个业务我就是开发这样一个业务我不用去添加额外的一些代码使它去对接某某微幅框架而整个微幅框架的对接是通过Sidecut这样一种无感知识的模式给直接对接进去的而这样一个过程就大大会简化了今后所谓的我们开发应用过程中应用本身的管理换句话说回回到我前面一直说的一句话我们是希望今后从应用开发角度来说它只关注于业务自己的逻辑而不需要去考虑非业务的那些底层云怎么来给它提供这种支撑性的功能所有的这些支撑性的功能都是由云底层自动的无感知的给上层提供的这样能保证大家的第一方面是提高了开发的效率第二方面是保证的开发的质量因为大家可以想像一个问题你让一个做财务软件开发的团队去做一套高并发海量用户的应用他是不知道怎么开发的他那么多年的经验只是怎么样去做好一个财务软件对高并发海量这种特性其实他是并不知晓的而云所能带给的就是说作为一个财务软件的开发团队你只要去关注你的业务而整个底层的云可以给你提供这样一套高并发的机制帮你实现这样一个高并发海量用户而这才是真正云原生应用可以给今后应用带来的一个改变再总结一下就说我们的理解下面什么样的一个应用才叫一个云原生应用首先云原生应用第一个字是云这个云是怎么来理解的就是第一个特性说云聚算管理物理设备这边其实说所谓物理设备是所有的物理资源以及虚拟化资源换句话说我们不需要云不是说有了K8S这种编排器机制以后我们不需要云我们其实是相反有了K8S之后我们更需要云因为我们需要云去管理底层所有的那些物理资源以一种统一的方式向上提供这样一个支撑性的能力第二点就是容器化封装和编排从应用的角度来说我们希望简化整个应用的生命周期的管理那怎么样能来简化这样一个应用的生命周期管理呢我们要通过容器和编排器就K8S来实现这样一个东西我们可以通过容器把应用的每个微服进行一个打包的工作然后通过编排器做一个整的生命周期的管理去解决这些问题第三点就讲到一个面向微服的这样一个架构换句话说单体应用我刚刚也提了越来越庞大庞大到我们无法去管理和支撑那怎么来做呢我们做这样一个微服的分拆分拆之后的话所有的应用的功能都是以一种微服的形态提供给整个应用去使用第四点叫业务的权欲见磨这个问题就会不能复杂我们希望做一件什么事或者说目前业界会遇到一个什么问题呢大家可能会听到这样一个词叫所谓的烟葱效应或烟葱应用换句话说传统应用开发的过程中每个应用是独立去开发的造成一个什么结果呢每个应用所用到的数据是无法打通和共享的我举一个实际的例子可能在应用A中你有一个字段叫用户名而在应用B中又有一个字段叫User ID这两个应用是给同一个用户同一个企业使用的其实是一回事只是说在不同的应用中他们会不一样这样的话有一天如果客户有这样的需求他希望把所有的账号集体给打通怎么样去做这个事这就是一个问题为了解决这个问题所以说另外一个需要考虑的是怎么样做一个业务的权欲见磨换句话说所谓的权欲制止一个客户所有的业务数据能怎么样保证在前期就做一个打通保证后期可以实现这样一个数据共享这是另外一个需要考虑的问题最后一点是自动化的运营或者运为的工作换句话说当一个应用被分拆之后一个应用变成10个甚至100个应用运为不能再像前期那种所谓的手动地去运为做这样的工作在这个前期下能怎么做呢就需要通过自动化的机制去实现这样一个自动化的运为和运营保证说整个平台应用以及底层的技术设施是以自动的模式去实现这样一个运为工作而满足了这几天的运用我们才认为至少腾讯内部来认为才是一个真正的合格的运源生运用接下来就有一个话题很好其实是这张PPT其实是昨天刚刚加的因为昨天其实在媒体见面会上有一位记者就提过这样一个问题所谓这样运源生运用或者什么跟国内说的比较火的一个词中台之间是一个什么样的关系因为其实中台这个在国外其实并不太能知道昨天我还特地给蒋达森解释了一下什么叫中台英语叫Middle Platform是什么呢首先一点讲一下这个故事这个故事可能在座有同学已经听过了就是所谓的马云在去某某去的一个公司叫Supercell这个公司然后发现这个Supercell这个公司其实效率特别高他们是开发软件的有一块软件就是什么Clash的Clan我也不知道是什么游戏我不管游戏然后有这样一款游戏他们才好处是这个公司开发游戏的效率特别高往往一个游戏从前期的需求分析直到后面的上限会在两至三个月内完成就很好奇说是怎么样一种公司的体制机制能支撑这样一个非常灵活的业务这样一个过程最后发现是这个公司他们把游戏引起所用到的一些公共的引擎和组建全部下沉到了一个平台而所有的游戏开发团队规模只保持在五到十人他们只会去开发他们的业务逻辑而所用到那些公共组建都已经是下沉到了这样一个平台去实现的这也就是所谓的就是某某有伤说的比较多的是什么小前台大中台的概念就是说公共性的功能其实都已经下沉到了平台层面每次我需要去开发一个业务逻辑的时候我只需要去开发那一段非公共性的定制化的业务逻辑而那些公共的我通过调用中台去实现这样一些功能这样可以大大的简化整个业务的开发的时间节约了人手实现了这样一个非常灵活的机制但是呢这边就聚起来说一下这个问题了但是呢怎么样去实现这样一点工作这个也是一个属于是业界比较通用和流行的说法所谓的中台可能会有三块中台组成数据中台技术中台和业务中台再说中台之前先说一下和语音计算什么关系大家可以看到有个叫作为的资源后台这个所谓的资源后台核心就是我们的OpenStack换句话说整个资源后台就是通过类似于OpenStack这样的艾斯层面的这样一个平台给中台提供足够中台所需要的资源但是呢我想说的更多一点其实我们认为整个资源后台不仅仅是OpenStack可能是OpenStack可能会有其他一些比如说存储网络等等的这一整套方案提供这样一个后台有了后台之后的话我们会讲到三个中台数据中台技术中台和业务中台首先数据中台其实提供的是一个数据共享所谓的数据猖窟或数据胡执的概念它的核心就是我前面讲的和全域建模是一回事希望说在这样一个平台中所有的数据都是打通的换句话说在电商的场景下所有用户画像是共享的在游戏场景中所有用户的资料也是共享的而数据中台的话提供这样一个数据共享以及大数据分析的能力接下来讲到技术中台业务中台也许同学们这边在座的同学们不是怎么理解它的区别曾经也有好几个问过我这样一个问题我可以非常简单地去解释这样一个问题假设你有一个银行客户还有你有一个零售的客户技术中台和业务中台区别在哪当你提供了这些共享模块银行客户和你的零售客户都可以使用的时候这些模块就是一个技术中台的模块当你有一些模块只能给银行客户使用而不能给零售客户使用的时候那是和它业务强相关的那就是它的业务中台可以用这种方式区分业务中台和数据中台和那个技术中台区别说得更直白一点从我们的角度来说当我们提供整到技术中台的时候我们提供的是什么呢那些公共的技术组件比如说集情模式的数据库比如说缓存机制Redis 卡夫卡消息堆裂啊等等这些所有大家都可以去使用的这样一些技术模块我们认为是技术中台而比如说是和业务强相关的某些领域的比如说银行领域的某些金融流程啊等等这些其他领域用不到的就是业务中台这样一个事而基于整个一个中台上面就可以去开发你所谓的业务通过最轻变最灵活的方式去开发你这样一个业务那就是这样一个问题就是说这个中台和这个云原生运用之间的关系或者是什么呢大家去想一下这样一个问题我们中台的目的是有更多的功能下沉到平台层面区可以共享那在共享之前需要把这个应用进行分拆以微服架构的模式进行分拆成了一个个根据它的功能去装一个分拆然后通过中台去给它提供那些共性功能而不需要它自己去开发换句话说我们一直认为中台和云原生运用或微服架构是一个相符相承的这样一个关系只有当我这个应用可以进行的分拆分拆了之后那我底层那些共享的功能才能用来支撑整个应用在这边大致就说了一下就是我们总结了一下说整个应用当它符合这六个条件的时候它可以通过中台去做这样一个支撑性的工作包括标准化无状态化敏捷基建实际眼镜面向切片以及去中心化等等这样的情况下这个应用才能做这样一个分拆而用中台去支撑这样一个应用那基本上听到一个非常好的东西云原生运用等等大家都想去用其实这也不是说推荐所有的应用都去做这样一个改造我们总结下来只有在这四种场景下应用能去做改造其实对应用会带来真正切切的帮助哪四种场景首先一个是大型复杂系统就像我刚说的一个单体应用当它复杂到一定的程度直到我们已经无法去管理的时候我们必须做这样一个分拆的工作才能去支撑这样一个去支撑这样一个业务第二个是业务频繁升级换句话说我们业务需要在很短时间比如说一个星期内就要升级一个版本跟经纪功能等等这种前提下我们就无法说是通过原先那种模式去做只能通过这样一个原原生应用方式去实现第三个是叫功能持续扩展其实这三点其实在互联网公司中用的特别多当我一个服务或一个上线的时候其实很多时候我们只完成了整个最终业务的30%虽然可以使用但有些扩展功能都没有实现而我们也认识到说这些扩展功能会持续地进行扩展在这样一个模式下我们就必须说有这样一种持续扩展的能力而互联生应用这种模式是非常好的第四种就是稳定高可用回到我前面举的那个例子怎么回事呢我一个财务软件我要支持高并发但是我财务软件的开发能源我自己根本就不懂什么叫高并发而这个时候通过把这个财务软件以互联生应用的方式进行一个改造这样的话底层的云可以支撑它去实现这个高并发而不需要财务软件自己去做也解决了这样一个财务软件的问题只有在这四种场景下我们是认为做这样一个云云生应用的改造是有必要的并且会对业务带来真真切切的帮助然后整个改造的过程其实这个是一个我们内部自己的一个总统阶其实换句话说不是说我要改或怎么样就能改嫌而是有这样一个我们有这样一个规范和步骤去实现的包括说是一个分拆的模式怎么样进行一个分拆以及说在这个微服分拆过程中它需要有哪些规范和标准接口应该怎么去做应该分几个层面每个层面去实现什么样的功能等等第三个方面是一个集成的模式换句话说我拆成了微服我通过哪种集成的模式可以把那些微服进行一个整合去交付一个整体的功能第四个就是所谓的应用的状态分离应用的状态分离的话说得更直白一点就是说尤其在容器场景下我们是要希望说整个应用是无状态的这样的话只有在无状态的应用过程中才能去实现所谓的弹性的这样一个扩展的功能而无状态的话就势必就是大家可以看做过应用的其实是我应用内部有四大类的不同信息包括配置信息包括冷数据是放数据库里面的冷数据包括在缓存中的热数据以及包括那些对象存储的那些固定的那些什么照片logo之类的东西当我开发这个应用改造的时候我们就需要想这个问题我们怎么样把这四类数据进行归导然后用不同的机制去做这样一个状态性的分离后面一个就是应用容器化当我已经分拆完了已经是一个独立的服务的时候我们要进行容器打包上线调试等等做编排最后的话最后一点其实不是非必要但是是强烈推荐的一旦整个改造过程做完的话希望要接近所谓的CICD的流水线保证它整个过程是自动的我拆一个两个微服是可以做的当我如果拆到100个甚至上千个微服的时候没有这个CICD的流水线会很繁琐而且必然会出错所以最后一点就是流水线的建设只有我们内部在做整个一个改造的过程中我们会用整个一套这样的流水线分为这样六步去实现好那最后来介绍一下腾讯内部我们是怎么样来面对这样一个应用的这样一个上云的业务上云的气机以及说在这个气机过程中我们是提供了什么样一些产品以及服务以及能力首先的话我们今年推出了TSTEC这个腾讯的IS自由云已经做了好几年了也是OpenSTEC白金会员以及说是做了一个很好的这样一个底层自身的能力前几年都有介绍过所以今年我就不介绍这一块了然后重点介绍一下上面两块属于今年俄罗亚做的一个就是所谓的TCM Platform腾讯云原生中台它的理念就是说能提供这样一套完整的平台来支撑上层的应用而整个中台的话包括容器包括微服包括中间键以及大数区和AI套件整个这样一个四块保证说是无论哪种类型的应用它在改造过程中它所需要的那些技术组件都可以在这个平台中给来实现为什么会有容器平台很简单的一个原因就是我刚刚说过了我们是希望改造后的应用都是以容器的形式在K8S上进行跑的这样的话对整个应用的生命周期管理会是一个非常便利的为什么要是微服治理平台它是一套基于ServiceMesh实现的一套微服治理平台它的核心理念就是说我们就刚刚说的希望开发人员去更专注于他自己业务的开发而不需要去过多地考虑那些非业务性的你治理的工作第三块就是说基于腾讯内部大量的应用我们改造过程中包括我本人已经做了全百上千个应用的改造我们积累和沉淀了大量那些应用所需要用到的公共组件包括技术层面的包括业务层面的等等而我们会有这样一个叫所谓的组建库是应用要用的时候直接去组建库里面可以去使用而不需要自己独立再去开发最后一块的话就是说当更好一些的应用这种大规模的应用它希望介入大数据通过人工智能去做那种什么什么AI Ops之类的人工智能的运为等等的工作时候我们会帮着客户接近我们的人个大数据和AI的这样一个私有化产品中去这是中间这一部分叫TCM Platform腾讯营员生中台去做什么事以及基于这个中台上面的话我们又做了另外一套平台叫做应用改造平台换句话说以前的应用改造是全是手动去完成的我们需要做什么呢我们需要自己去做分拆去改造去调试等等手动去做要搭建一个环境是相当复杂的我们就是一直在想当你改了一个两个的时候你还能接受当你改了十个的时候你会抱怨当你改了一百个时候你就会崩溃所以能做的事情是说怎么样能把整个改造的过程做一个自动化而怎么来做这样的自动化呢就继续我们这样一个改造经验我们就做了一个自动化的改造平台叫TCM Platform这样一个这样一个应用改造平台在这个改造平台上的话是我们是第一家能实现首先是打通了容器和虚拟机用一套微服之类的框架同时去治理容器中和虚拟机中的那些微服大家可以我这边要着重说一这样一点比如说服网格Service MatchEastel等等它是只能用在虚拟机中只能用在容器中的它只能去治理容器中的这样一些这些微服因为它用的是那种塞德卡的这种机制用了一个Invoid套件去实现的而我们这边去能做了一个什么事呢我们这边把自己自行研制开发了另外一个塞德卡的是可以跑在虚拟机中的这样保证说是我一个原先的单体应用当它在虚拟机中安装和部署之后可以通过整个微服的治理平台也去进行纳管和治理从微服的治理平台来说它对它不会去区分是在虚拟机中还是在物理机中跑的虚拟机中还是在容器中跑的这样一个应用这就带来了一个便利的治理的方式大家可以想象这样一个场景我一个传统的应用原先是装在虚拟机中的在虚拟机中进行这样一个部署和连连调但我想逐步的用类似于比如说业界说的什么角杀者模式进行分拆在这个过程中我们可以说逐步把它这个应用中的功能一个一个玻璃出来一个一个在旁边的容器平台上给起了而通过整个微服治理同时进行一个路由服务发现附载均衡 挥度的工作而对整个应用来说是一个无感知的这个也是业界第一款能做成这样的一个超融合方案的产品这边我觉得大致介绍一下首先的话就底层的那个是T-Stack是一个基于OpenStack的这样一个大型的平台腾讯内部的话直到目前还是运营和运维着全球最大的一个私有化的OpenStack这样一个集群第二点的话就是我们讲到腾讯运运生中台这个中台的话是由容器平台由微服物治理平台以及由运维平台组成的这样一个完整的可以对上层提供这样一个支撑性功能的这样一个一个原生中台最后讲到了一个TCM Pub腾讯运用改造平台它是核心是一个操作平台在这个操作平台上可以更便利地自动化的把原先的单体运用和那种传统式的运用逐步迁移到运原生运用的这种架构上去包括做微服的分拆容器化的打包自动化的流水线的建设等等这些工作都会通过这样一个操作平台通过这样一个操作平台去实现最后再来说一下就是这张PPT其实是我们老板昨天在Keynote上也讲了一点为什么会重复这张PPT呢就是说当大家看到整个这样一个产品体系的时候会有这样一个误解就是认为腾讯运会把所有的东西都给做了这是一个误解为什么呢就是说自从3Q下单之后其实我们这边有一个教授我的腾讯希望去建立这样一个生态体系的这样一个过程具体来说就是说我们这边有一个要求是说我们所做的任何2B的产品下不喷硬件上不喷业务怎么来解释这样一个问题呢下不喷硬件腾讯不会做硬件大家可以想象QQ和微信做得那么好但是我们从来不会去做手机因为我们说得很明白我们不会去喷硬件这块留给合作伙伴的蛋糕上不喷业务这是什么说法的就是说我们不会去做真正的客户的那些业务应用的开发我们只做中间连接的这样一层所谓的中间连接的一层包括说是云平台容其平台 微服以及这样一个中台而在中台中刚刚我也说了其实分为技术中台业务中台腾讯能做的其实基本上只是这样一个技术中台我们提供公共的技术出现而在不同的领域我们希望去找到领域的合作伙伴基于我们这样一个平台去实现它的业务中台而通过这个业务中台也是希望我们的合作伙伴帮着给最终的客户去交付他们的业务这就是为什么我最后会放这样一张PPC的原因我们提供的是这样一个技术的身台同时的话我们把整个业务的身台留给了合作伙伴就像我们老板一直说一句话腾讯是希望把说我们的半条命交在合作伙伴手里我们提供底层这样一个中台的基石这样一个基座以及一套标准的流程和规范而希望我们的合作伙伴是基于这样一套规范去实现他们的业务中台去实现他们最后真正交付给客户的业务今天我这边讲的就是这些如果大家对整个产品会感兴趣的话可以散发这个二维码是我们的公众号然后有什么问题也可以在这个公众号上提我看时间大概还有五分钟如果大家有什么问题的话可以说一下我问一个中台的这个感觉就是我听说阿里的话它通过这二十多年的发展说是积累了它自己的很多业务说有十几万和几十万个这种application运行我估计腾讯也有很大规模就是自己业务发展的这种application已经跑了可能好多因为一开始没有中台的概念可能都是烟虫式的因为随着业务的发展需要快速地上应用那么现在有这个中台的概念那是不是腾讯也面临的自己支撑这些application的要再把好多东西下沉下去做成中台因为你不可能说一开始application起来的时候就有中台那么这种下沉的过程是不是很复杂或者是否真的能可行性怎么样关于这个问题其实我有两个答案一个是腾讯内部是怎么去做的第二个答案是我们是怎么样帮我们的客户去实现的首先腾讯内部的话其实大家可以看一下我所在的部门在腾讯叫企业IT它是给腾讯建的原先是给腾讯建设整个它自己的IT系统的一个非常庞大的占个IT系统其实在这个过程中尤其近三五年来我们已经接触到了大量的说原先的业务的这样一个改造在改造过程中的话其实这是个显而易见的你改第一个应用和改第二个应用之后逐步你会发现我们每次改的应用中总有那么几个功能是差不多的这时候就是从一个马龙的角度来说我们肯定会想怎么样去可以简化用库的形式用服务的形式把它沉淀下来这个过程中其实我们自己有改就是改了好多应用之后就有沉淀这样一个对 自身的这是第一点第二个的话我可以举一个是某某可能中国牌我们有个客户是一个中国牌前50的一个非常大的集团我们也给他建立了整个这样一套体系从底层的IS层面以及中台的建设以及上台应用的改造等等帮到他们去改造这样的过程我们也是去做了这样一个给我们的客户去建立一套完整的后台中台前台的这样一套体系在这个过程中我们也是帮了他去沉淀了他所需要的那些组建这个沉淀的过程是分两类一类的话是属于比如说那种标准的什么数据库啊缓存之类的大家都会用到这些细先就可以准备好还有一类业务中台的沉淀是有一套标准的流程我们是伴随的客户在这个流程过程中逐步去分析以后才把他那些公共组建给往下下沉的就有这样一过程其实中台和PASS的关系这个问题其实非常重要中台和原先我们说的PASS的关系是怎么样一个区别我给这样一个我讲了很多今天你们讲的一点什么就是容器和微服然后的话其实中台和PASS的一个最大区别我个人认为中台只是一种理念怎么样来共享这样一些服务你可以是以这种PASS多租户的形式提供这样一个共享你也可以是以容器进向的形式提供这样一个共享两个的核心区别在哪如果是以PASS多租户形式的话我只起了一个服务给所有的应用同时使用而我以容器微服的形式的话我是给每个应用起了一个单实力它有自己的实力这个实义是不共享的因为在很多场景下我们不希望用那种多租户的PASS模式有安全的因素考虑有平台稳定性的因素考虑和便捷性的因素去考虑以及迭代速度的因素去考虑这些因素的话我们不希望用PASS多租户的模式去实现而因为容器和这种K8S技术的成熟把这种服务打包为一个容器进向我随时可以起随时可以用这样会用起来更便捷隔离性也会更好我的一个问题就关于GottentEast2的微服框架提到SpringCloud在腾讯的这个平台里面你们怎么样看SpringCloud跟East2它的一个是互补的关系还是一个竞争的关系好的谢谢我来回答一下这个问题其实我个人认为是做了一套非常完整的也成熟的一套不只是微服框架因为SpringBoot是一套非常好的开发框架而基于这个开发框架的话我们有SpringCloud这样的治理但是最核心的两个缺点第一个缺点只能加碼如果我要作为GottentEast2我用不了SpringCloud而其实在互联网行业中我们用GottentEast2用得越来越多这是一个问题第二个问题就是说SpringCloud对容器的支持肯定没有East2做得好包括那种入侵式的那种代码的加进去等等的这些事情都得去做而从East2来说就没有这个问题所以说我们认为是有整个微服框架的一个演变有三代第一代是HardCoded第二代是SDK-based就是所谓SpringCloud就是SDK-based的第三代就是所谓的服网格ServiceMesh而我们认为将来的方向肯定是第三代的服网格以及说是但是不是说服网格的技术就相对比较成熟在这过程中其实我们遇到一个问题就是说一个是像East2这样的在生产环境中的大规模情况下的问题还是有的我们做了很多优化去优化了这些遇到的问题第二个就是服网格中它可能会遇到的可能会遇到一个问题就是我刚刚说的你怎么样来保证说服网格现在只能用在容器中我怎么样能保证说服网格可以同时治理容器和虚拟机这一块这个我们也做了大家的工作去实现通了一个超融合的方案对对 它有什么抗扫就是那种我看时间也差不多了谢谢大家