摘要：华为云提出“云原生 IN 基础设施”的融合架构，通过三大创新升级，将云原生推进到了2.0时代。面对数字时代复杂系统的不确定性，传统的IT应用架构研发交付周期长、维护成本高、创新升级难，烟囱式架构，开放性差、组件复用度低，这些都成为了企业新业务快速发展的瓶颈，而云原生以其敏捷、开放、标准化的特点迅速成为企业构建面向未来的应用架构的首选。Gartner 在报告中预测，到 2020 年将有 50%的传统老旧应用被以云原生化的方式改造，到 2022年将有 75%的全球化企业将在生产中使用云原生的容器化应用。经过多年的发展，云原生已从最初的默默无闻到 “小众”流行，再到今天成为企业数字化转型的首选。华为云作为云原生产业的领导者和积极实践者，伴随着云原生的发展一路走来，在每一个阶段，华为云为云原生产业繁荣作出了持续的核心贡献。持续技术贡献，加速社区项目能力完善：云原生计算基金会成立初期，社区发展的重点是补齐云原生项目在存储、网络等方面能力的不足、对接主流硬件厂商、云厂商的基础设施资源等，华为云积极投入，为社区贡献130+核心特性和4万+PR，成为亚洲排名第一的贡献者；丰富行业实践，推动云原生产业成熟：随着云原生在以互联网、金融、政府为代表的各行业的广泛应用，以Kubernetes为核心的云原生产业生态逐步形成。在此期间，华为云通过内外部持续不断的创新与实践，打造了丰富的云原生解决方案，为10多个行业近万客户提供优质的云原生服务。在IDC发布的2019年中国容器软件市场份额排名中，华为云已位居中国厂商第一。同时，基于丰富的实践积累，华为云向CNCF捐献了首个云原生边缘计算项目KubeEdge和首个云原生批量计算项目Volcano，加速了云原生向其它产业的渗透和融合，推动了云原生产业的成熟。三大创新升级，开启云原生2.0时代：然而，当前云原生技术与云基础设施只是简单叠加的“云原生ON基础设施”架构，在这种架构下，计算、网络、存储等基础设施无法感知应用在高可用、高性能、自动弹性等方面的诉求，也无法满足跨集群、跨区域、跨云的全局化业务场景，因此企业业务与应用无法实现真正的“云原生化”， 针对以上问题，华为云开创性地提出“云原生 IN 基础设施”的融合架构，整合架构通过三大创新升级，将云原生推进到了2.0时代：重定义基础设施：基于擎天架构实现了以应用为中心的资源调度，并且结合软硬协同技术，为企业提供极致性能、极优成本、极佳体验的云原生基础设施。新赋能泛在应用：基于云原生集群联邦、边云协同等技术打造了多云与边云协同管理平台，能够帮助企业构建高效、可靠、跨云的统一业务平台，提供多云一致的管理体验。再升级应用架构：云原生基础设施针对企业各类业务的诉求，打造完善的云原生应用生态，统一企业应用架构和全流程生命周期管理，支持130+云原生应用。同时，华为云在云原生产业方面的投入进一步加码，通过举办"创原会·云原生技术精英沙龙"，汇聚各行业云原生技术精英，并与云原生产业及标准化组织一起，共同推进云原生技术和产业的成熟与标准化建设。云原生2.0时代，华为云将持续努力让云原生技术结合各行业场景进行交叉创新，通过"技术+产业"的双轮驱动，加速云原生全面落地，帮助更多的企业完成数字化转型与业务创新升级。

        Gartner 在数据库市场分析报告中预测到2022 年75%的数据库将被部署或迁移至云平台，只有5%的数据库会考虑部署在本地。在国外，以AWS 为主的云厂商已实现云技术与数据库的融合，在逐步挑战与吞噬传统数据库厂商市场份额。在国内，云+数据库的发展也已到了下半场，数据库正在不断深度融合云计算的特性，为用户提供高弹性、分布式、低成本的极致使用体验。数据库的部署形态正在发生改变，传统数据库的发展已遭遇瓶颈：        基于物理服务器部署的传统数据库存在着高成本，低效率，稳定性差等诸多问题。业务部门采购时需为未来业务增量预留资源，存在着显著的资源浪费。当业务快速增长时，资源的采购周期又无法满足业务快速扩张的需求。此外传统IT 架构下服务器故障恢复时间较长，对数据库影响明显。搬迁上云的云数据库，架构层面没有质变无法充分复用云平台的强大能力，云数据库基于云平台的弹性调度和虚机迁移等能力在一定程度上提高了弹性和稳定性，但受限于传统数据库技术能力限制，这一架构同样存在问题，如较难实现TB 级数据的存储扩展、指数级增长的并发访问导致数据同步延时严重，可用性降低等。当前解决这些问题的方式主要有业务拆分及采用分库分表的分布式数据库架构两种方式，但以上两种方法同时会带来系统复杂度提高、扩展操作难度大的问题。        云原生数据库的出现能够有效解决云数据库的现有问题，成为重要的发展趋势。云原生数据库采用计算存储分离的架构，遵循“日志即数据”的原则，计算层能够自动实现读写分离，扩缩容过程对上层透明，存储层采用多租户分布式高可用存储系统，单集群具备TB 级的扩展能力。相对于传统数据库云原生数据库主要有以下几方面优势：        数据库部署高度标准化，云原生数据库本身使用Kubernetes 等云原生平台进行部署，以PaaS 的形式对外提供服务，提供近似对象存储的使用体验。这使得数据库无论是在资源使用，还是应用部署，亦或是业务调用上都实现了标准化；大幅降低使用成本，与现有数据库架构不同，用户无需提前预留资源，仅需为使用的资源进行付费。受益于计算存储分离架构，增加从库时不会增加存储成本，仅需为计算资源付费；多数据库版本兼容，云原生数据库一般兼容现有数据协议，如MySQL、PostgreSQL 的多种主流版本及部分商业数据库版本，业务无需修改即可进行迁移。同时数据库提供的TB 级的空间可满足绝大部分应用需求，免去了分库分表所带来的数据一致性问题，研发仅需要关注业务逻辑即可；秒级的故障恢复提升稳定性，传统数据库稳定性严重依赖底层资源，当资源故障时需进行数据迁移，导致故障恢复时间过长。在云原生架构下，计算节点故障时无需拷贝数据，仅需创建新的资源承载流量即可，可做到秒级别的故障恢复。而存储节点一搬采用分布式多副本的架构，其故障更是对业务无感。来源：云原生产业联盟

        随着云原生技术的普及，越来越多的应用开始进行云原生化架构升级和应用迁移，负载类型和集群规模的不断扩大，要求云原生调度系统提升资源的使用效率，并能够对不同类型应用（如AI、大数据、HPC）、异构硬件资源（如GPU、TPU）和多个云环境进行统一智能化调度：            离、在线应用的统一调度，越来越多的批量计算任务迁移至云原生环境中执行，从HPC 到大数据再到人工智能，早期每种场景中的分布式系统多为专有系统。在批量计算任务向云原生环境迁移的过程中，需要云原生调度系统能够支持各种场景的批量计算任务，并能够与微服务应用共享云原生环境和资源，这就需要云原生调度系统要能够同时支持微服务类应用(在线)和批量计算任务(离线)共享资源，以达到多种应用统一调度的要求；异构硬件的统一调度，为了应对多种应用对资源适用场景的多元需求，需要云原生调度系统能够对异构硬件资源进行统一的管理与调度，使用各种应用达到最优的资源配比；多云负载的统一调度，为降低厂商绑定的风险，同时也为了最大限度的兼顾不同云厂商的优势，多云的环境下的负载高效分发逐渐成为趋势；智能化的统一调度，云原生环境的多样化使得资源和作业调度更加困难，人工智能等新技术的发展为其提供了解决方法。借助作业画像等AI 技术预判资源的使用量，并以此为依据对资源进行动态扩缩容、动态超分，以优化复杂环境下的资源和作业调度方案。        针对上述这些新的要求和挑战，云原生的相关项目提供了不同的解决方案：一是通过改进现有的Kubernetes 组件实现。目前云原生环境中大量的微服务都使用Kubernetes 进行调度管理，随时着批量计算任务向云原生环境迁移，Kubernetes 社区不同的兴趣组也对各个组件做出相应的改进,调度兴趣组开始通过调度框架，让用户通过自研插件来支持批量计算任务Kubernetes 社区通过调度框架，希望用户通过自研插件来支持批量计算任务。二是基于Kubernetes 的扩展机制实现。通过CRD、Operator、multi-scheduler 等扩展机制提供批量计算解决方案，能够有效的支持批量计算任务与微服务应用统一调度，代表性的项目如Volcano。Volcano 是CNCF 首个面向批量计算场景下的云原生调度系统项目，作为基于容器组的调度框架，Volcano 支持批量计算的各种场景，并通过引用Kubernetes 现有的调度策略支持微服务场景并兼容Kubernetes 的调度策略，同时还支持GPU 共享的异构硬件功能。来源：云原生产业联盟

云原⽣消息队列        消息队列是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。传统应用架构设计中系统组件与应用紧耦合，消费者出现任何问题（升级停服、宕机、不可用等），都会影响生产者的业务；系统可用性和效率低，突发的海量消息压力，消费者无法实时高效的处理消息时，容易产生雪崩效应；缺少持久化机制，系统发生故障会丢失消息；消息本地存储难扩展，单机的处理能力和内存容量都是有限的，不具备可扩展性，同时系统组件高度耦合，扩展难度大。        为解决传统架构中的种种问题，云原生消息队列服务应运而生，它为微服务和事件驱动架构提供核心的解耦、异步和削峰的能力。通过消息队列能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。        程序组件与应用解耦分离独立运行，同时还可以简化组件间的消息管理。分布式应用程序的任何组件均可将消息存储在队列中， 云云消息服务 确保每条消息至少传送一次，并且支持多次读取和写入。单个队列可由多个分布式应用程序组件同时使 用而无需这些组件之间的互相协作。所有组件均可使用云消息服务API 以编程方式检索和操作消息。        可靠的基于消息的异步通信机制，能够将分布式部署的不同应用（或同一应用的不同组件）之间的收发消息，存储在可靠有效的 消息队列中，防止消息丢失。云原生消息队列支持多进程同时读写，收发互不干扰，无需各应用或组件始终处于运行状态。        消息同步多副本落盘保障消息高可靠，通过分布式 Raft 等算法保证消息强一致，提供消息队列、发布订阅、消息回溯、延时消息、顺序消息、消息轨迹等服务。具有高可靠、高可用、高性能、动态伸缩等优势。        云消息服务不仅具备处理系统解耦，异步通信等传统消息队列所必备的能力，而且在数据的可靠传递，性能，快速部署等方面提供有力的支持，满足使用者针对特定场景下的消息的高可靠堆积，动态扩缩容，系统监控，消息轨迹查询等方面的需求。来源：云原生产业联盟

3月27日,华为开发者大会2020(Cloud)开幕,吸引全球众多开发者关注和参与。华为云DevCloud研发总监王亚伟在主题演讲中重磅介绍了华为云CloudIDE,引起开发者关注。作为一个面向云原生的轻量级WebIDE,华为云CloudIDE是华为云DevCloud在开发阶段的核心服务,可以为开发者提供轻量极速的在线编程体验,帮助开发者快速可靠交付代码,并打通整个开发、测试和运行时。同时,CloudIDE支持鲲鹏原生的开发环境,10分钟快速开发部署鲲鹏云原生应用,解决当前鲲鹏开发者的最大痛点。华为云DevCloud研发总监王亚伟介绍,因软件产业形态等发展变化,开发者研发效能提升是当前开发者和企业研发组织愈发关注的重点。而提升研发效能的本质是提升持续快速交付代码的能力,包括持续交付效率、交付质量和交付能力等。华为云CloudIDE也是在这种背景下应运而生。华为云CloudIDE面向云原生,AI和移动领域的开发者,致力于打通应用开发态到运行态,将帮助开发者快速可靠的交付价值,提升开发者持续交付的能力。一站式作业,让云原生应用开发更方便华为云CloudIDE不仅有代码编辑器的轻量极速,又有IDE的代码理解调试能力,同时还支持在线开发,开发者可以在浏览器中编码调试。同时,它还打通了跟华为强大的云原生平台的连接,让云原生应用开发更方便。以开源技术为基础,CloudIDE的自研IDE内核对开源技术进行了全方位增强和优化,包括数据的编码解码、调试、语言解析、代码自动补全等。CloudIDE对于主流的云上开发场景的开发者体验进行质的提升。以云原生开发为例,开发者可以在IDE实例中一站式完成项目创建、编码、调试、测试、微服务容器化、华为云容器服务管理、容器实例部署等一整套云原生开发作业流。开发者不需要在多个环境、页面、工具等来回切换。欢迎大家在HDC.Cloud官网的CodeLabs环节(基于CloudIDE的云原生应用开发)体验华为云上云原生开发的流程。10分钟,快速开发部署鲲鹏云原生应用当前,鲲鹏开发者的最大痛点是开发环境的不易获取和开发者作业流的割裂。开发者要么选择本地编译工具链,这意味着在X86做编码,在鲲鹏环境做编译构建,整个作业流割裂,效率低下;开发者要么选择交叉编译工具链,这意味着在X86环境使用ARM交叉编译工具链,这有可能引入ToolChain Leak的问题,难诊断。而华为云CloudIDE服务支持鲲鹏原生的开发环境,解决鲲鹏开发者的最大痛点。借助华为云容器平台和CloudIDE分布式任务调度引擎,可在几十秒时间内创建一个鲲鹏原生的云端开发环境,开发者使用手机、平板电脑或者普通PC的浏览器连接到云端实例,即可马上进行编码、调试、测试等开发者作业活动,10分钟快速开发部署鲲鹏云原生应用。此外,2020年 CloudIDE还将对所有鲲鹏实例全年免费。华为云CloudIDE服务的目标是“做最好用的云端IDE服务”,“最好用”除了作为开发者工具本身的核心功能强大之外,更重要的是优秀的开发者体验和贴心的开发作业流设计,让开发者可以无障碍上手,流畅作业和持续高效交付价值。华为云CloudIDE研发团队正向着这个目标持续挺进。转自http://www.situedu.com/news/uid/3597.html

10月23日（周五）早上9点到下午5点15分，进行全天线上直播，汇聚多位华为重量级专家手把手教学，不仅有经验、技术分享，还有在线互动答疑，带你揭晓大厂最深层代码技术直播地址》》观看回放《《专家介绍四重福利，助力1024程序员节盛典直播启幕！！！福利一：成功报名本次直播盛典，必得200码豆福利二：参与1024程序员节集卡活动，手机、平板、手表四种礼包等你来拿，还有码神锦鲤礼包！ 点此参与福利三：10月23日参与直播盛典互动，直播间内抽取码神锦鲤礼包、手表、耳机等数十件奖励！福利四：邀友报名直播盛典，Ta得码神锦鲤礼包，你也同样获得！- 如何邀请好友？1.点击本页面上方“立即报名”按钮 > 2.登录/注册华为云账号 > 3.填写信息完成活动报名 > 4.报名成功弹窗中点击分享有礼(或进入我的直播中点击分享有礼按钮) > 5.按照引导将活动分享至你的好友，并引导ta完成本活动报名参与专家坐堂互动在本帖下方任意回复以下一项内容，即有机会获得FreeBuds 悦享版 无线耳机和无线鼠标。有效参与必得500码豆。1）  观看直播后发表您的个人观点2）  观看直播后向专家提出问题3）  参与微话题互动（任选其一）：讨论话题：你觉得云原生未来的发展趋势是什么？注：发布的内容必须与本次直播话题或微话题相关，且必须包含个人思考的内容。抄袭内容一经发现将取消评选资格。回复时间截至10月30日。活动规则1、如本帖的有效回复人数大于等于20人，则由专家和华为云工作人员共同评选出3个优质回复，发布者可获得无线鼠标一个。如有效回复人数大于等于30人，则额外评选出一个最优回复，发布者可获得华为freebuds 悦享版 无线耳机一个。如有效回复人数小于20人，则只发放500码豆参与奖励。获奖用户将于11月2日公布，并公示至11月5日截止。2、参加专家坐堂互动的有效参与者均可获得500码豆，请您提前登录DevCloud会员中心（https://devcloud.huaweicloud.com/bonususer/home），以免无法接收码豆。3、以上实物奖励将于11月30日前完成发放，码豆奖励将于11月25日前完成发放，请您耐心等待。4、如您参与1024相关活动，为保证您顺利领取活动奖品，请您提前填写下方奖品收货信息链接，如您没有填写，视为放弃奖励填写地址请戳我>>5、本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/），奖项评比将由专家和华为云工作人员共同完成。如您对评奖方式有异议，请勿参加本次活动。6、活动结束后三个工作日内将公布本活动获奖名单，获奖用户需在公示后的三天内填写获奖信息。

10月23日（周五）早上9点到下午5点15分，进行全天线上直播，汇聚多位华为重量级专家手把手教学，不仅有经验、技术分享，还有在线互动答疑，带你揭晓大厂最深层代码技术直播地址》》观看回放《《专家介绍四重福利，助力1024程序员节盛典直播启幕！！！福利一：成功报名本次直播盛典，必得200码豆福利二：参与1024程序员节集卡活动，手机、平板、手表四种礼包等你来拿，还有码神锦鲤礼包！ 点此参与福利三：10月23日参与直播盛典互动，直播间内抽取码神锦鲤礼包、手表、耳机等数十件奖励！福利四：邀友报名直播盛典，Ta得码神锦鲤礼包，你也同样获得！- 如何邀请好友？1.点击本页面上方“立即报名”按钮 > 2.登录/注册华为云账号 > 3.填写信息完成活动报名 > 4.报名成功弹窗中点击分享有礼(或进入我的直播中点击分享有礼按钮) > 5.按照引导将活动分享至你的好友，并引导ta完成本活动报名参与专家坐堂互动在本帖下方任意回复以下一项内容，即有机会获得FreeBuds 悦享版 无线耳机和无线鼠标。有效参与必得500码豆。1）  观看直播后发表您的个人观点2）  观看直播后向专家提出问题3）  参与微话题互动（任选其一）：讨论话题：你觉得微服务的未来发展如何？注：发布的内容必须与本次直播话题或微话题相关，且必须包含个人思考的内容。抄袭内容一经发现将取消评选资格。回复时间截至10月30日。活动规则1、如本帖的有效回复人数大于等于20人，则由专家和华为云工作人员共同评选出3个优质回复，发布者可获得无线鼠标一个。如有效回复人数大于等于30人，则额外评选出一个最优回复，发布者可获得华为freebuds 悦享版 无线耳机一个。如有效回复人数小于20人，则只发放500码豆参与奖励。获奖用户将于11月2日公布，并公示至11月5日截止。2、参加专家坐堂互动的有效参与者均可获得500码豆，请您提前登录DevCloud会员中心（https://devcloud.huaweicloud.com/bonususer/home），以免无法接收码豆。3、以上实物奖励将于11月30日前完成发放，码豆奖励将于11月25日前完成发放，请您耐心等待。4、如您参与1024相关活动，为保证您顺利领取活动奖品，请您提前填写下方奖品收货信息链接，如您没有填写，视为放弃奖励填写地址请戳我>>5、本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/），奖项评比将由专家和华为云工作人员共同完成。如您对评奖方式有异议，请勿参加本次活动。6、活动结束后三个工作日内将公布本活动获奖名单，获奖用户需在公示后的三天内填写获奖信息。

大家应该都看过某些明星导致社交媒体平台宕机的新闻吧？明星事件带来的突发流量触发业务扩容，以前是扩容虚机，速度慢还情有可原，现在大部分互联网平台都使用容器了，为什么扩容速度有些时候还是跟不上流量增长的节奏呢？这里主要有两个问题。01一是网口发放速度匹配容器扩容速度的问题。如果是即时按需创建容器，比如10秒内启动5000个容器实例，这要求10秒内完成端到端的网口创建、挂接和网络打通。处理流程上，容器网络控制器需要调用VPC网络API批量创建5000个网口，VPC控制面生成相应的配置，下发到各个主机节点，主机按配置创建好全部网口再挂接到节点上，进而挂接到容器上，与此同时，分布在各个主机和各类网关的数据面转发表也要同步完成刷新。传统的I层网络架构，无论是管控面还是数据面都存在瓶颈点，全流程网络打通的速度，无法匹配容器扩容速度。02再一个就是网口规模的问题，由于ENI原本是针对I层虚机或裸机的网卡扩展机制，数量受节点规格的限制，有的厂商是按照主机的flavor限定ENI的规格数量，某些厂商提供了固定的最大数量，比如8个，这些规格约束有商业成本的考虑，但根本原因还是规模目标不同。容器为了榨干节点资源，支持0.1核甚至更小的容器，单节点理论上可部署近千容器实例，也就需要近千网口，这与现有VPC网络的管控面和数据面规模有数量级差距。网络资源预热让秒级扩容成为可能如何应对发放速度不匹配问题？计算机系统结构的经典答案：加“Cache”层, 就是按预定策略在节点建立预分配ENI的warm pool，集群纳管节点时，自动创建并配置好若干个ENI放入pool中，在批量启动容器的时候只需要把已经ready的ENI从warm pool中取出挂接到容器即可。网络资源预热能够有效弥补VPC 网络资源分配性能不能匹配容器生命周期的现状。加‘Cache’的机制能够支撑容器大批量创建删除场景。Warm pool机制主要解决端到端网络打通时间长的问题。目前VPC网络单节点网卡是串行处理的，而且单个网络设备绑定时间也达到了30s-60s，不做预热的情况下容器网络端到端打通时间在一分钟以上。分钟级容器启动时间是不可接受的。Warm pool机制在裸金属节点上预挂载一定数量ENI（用户可根据服务部署并发量自定义配置），容器随时调度到预热节点上都有即时可用的ENI网卡。经过warm pool的优化，容器网络端到端打通时间缩短为1s-2s。华为云容器网络Yangtse的warm pool其实早在裸金属容器之前就已经在云容器实例CCI中得到了实践，是CCI能以30秒扩容1000容器的绝对优势领先业界的技术手段之一。突破ENI数量限制支持大规模容器扩容上文中讲到了，单服务器ENI的规格上限，限制了容器的高密度部署和大规模快速扩容，在第二代裸金属容器中，我们把容器网络组件全部卸载到了华为云擎天卡上，突破了传统架构的约束，最大ENI数量提升数十倍，单服务器可部署的容器数量也相应提升。同时，得益于擎天架构资源共池优势，裸金属容器还可以向虚拟机容器扩容，而在虚拟机容器上，容器网络Yangtse使用了Trunkport技术，结合ENI的优势，在保障性能的前提下，单台服务器理论上可为千容器同时提供直通网络能力。ELB直通容器应对海量冲击更平稳解决了速度和规模的问题后，其实还存在一个隐藏的杀手，处理不好，可能使我们新扩容出来的容器全部命丧于此。在传统的容器网络对接外部ELB方案中，外部流量会从ELB先到Kubernetes的Node Port（工作节点所在主机的端口），然后再转发给后端容器，增加的这一跳不仅带来了时延和故障几率，也影响了ELB使用时的灵活性。当应用业务流量增长触发扩容时，如果ELB直接全量发放分摊的流量请求，海量请求会迅速压垮（overload）新扩的容器，造成扩容失败。发生这种情况跟业务的处理逻辑或运行时行为相关：新扩容的后端实例需要一边处理请求一边加载热点数据到本地Cache，或者需要根据接收到的请求即时编译（JIT）和加载相应的代码模块，这都需要“慢启动”（slow-start)过程，即根据业务模型，自定义初始流量比例和阶梯递增速率，比如：15%的初始流量，每5秒增加10%。但是，当ELB挂接宿主服务器（节点）的网络端口（Node Port）时，特别是一个节点上部署多个容器时，由于存在节点二次分发，ELB无法感知到最终的后端容器，进而无法做到容器级别的流控，也难以保证稳态后的负载均衡。容器网络Yangtse实现了与华为云ELB v3独享型负载均衡实例的直通，独享型ELB v3资源独立，实例的性能不受其它实例的影响，而且流量从ELB直通至后端容器，保证转发性能和稳定性。 关于裸金属容器网络的揭秘，就到这里了。后续我们将围绕华为云云原生技术平台Vessel，逐一为您解读华为云容器的黑科技。

在刚刚结束的CLOUD NATIVE+ OPEN SOURCE Virtual Summit China 2020上，由华为云云原生团队主导的容器批量计算项目Volcano正式发布1.0版本，标志着Volcano项目已经开始走向成熟与稳定。Volcano项目介绍Volcano是基于Kubernetes的云原生批量计算引擎，基于华为云在AI、大数据领域的深厚业务积累，补齐了Kubernetes在面向AI、大数据、高性能计算等批量计算任务调度、编排等场景下的短板，向下支持鲲鹏、昇腾、X86等多元算力，向上使能TensorFlow、Spark、华为MindSpore等主流行业计算框架，让数据科学家和算法工程师充分享受到云原生技术所带来的高效计算与极致体验。Volcano架构示意图随着Kubernetes作为AI、大数据和高性能批量计算的下一代基础设施的趋势逐渐清晰，越来越多的企业对Kubernetes在深度学习、科学计算、高性能渲染等方面提出了更高的要求。然而Kubernetes作为普适的容器化解决方案，仍与业务诉求存在一定差距，主要体现在：K8s的原生调度功能无法满足计算要求K8s作业管理能力无法满足AI训练的复杂诉求数据管理方面，缺少计算侧数据缓存能力，数据位置感知等功能资源管理方面缺少分时共享，利用率低硬件异构能力弱Volcano的诞生正是基于这些痛点，在调度、作业管理、数据管理、资源管理四个方面进行了重点优化。增强了任务调度能力，如公平的调度（fair-share）、组调度（gang-scheduling）  进一步优化了作业管理能力,如multiple pod template能力、更灵活的error handling机制  增加计算侧数据缓存，提升数据的传输与读取效率引入多维度的综合评分机制，实现资源更高效的管理和分配多元算力支持：支持x86、鲲鹏和昇腾等算力Volcano项目进展时间轴Volcano v1.0新特性介绍Volcano v1.0的核心概念和关键特性，主要包含以下要点：Queue、PodGroup、Volcano Job等核心概念均已实现支持Binpack、Conformance、DRF、Gang、Preempt、Reclaim、Priority、Proportion等多种调度策略支持Rest API、CLI等多种交互方式完成与Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore等主流高性能计算框架的无缝对接支持Job的全生命周期管理和动态扩缩容支持GPU异构与共享完备的golangCI-lint check、e2e以建立增强代码质量和稳定性除以上特性外，Volcano始终保持与Kubernetes社区、Golang最新版本保持一致。Volcano社区和生态建设进展经过一年多的发展，Volcano的社区和生态建设已经步入快车道。截至目前，社区和生态建设取得了以下成绩：社区贡献者80+社区贡献参与组织15+，包括华为、百度、腾讯、AWS、IBM、 Oracle等获得Star 1100+，Fork 220+代码库7个，Release 6个Issue 320+，PR 590+已完成对Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore、Cromwell等10+主流计算框架的支持华为云CCE（云容器引擎）、CCI（云容器实例）、ModelArts等多个云服务已将Volcano集成为基础设施底座并商用，服务领域已涵盖AI、大数据应用、基因计算、批处理等场景，并实现与华为鲲鹏、昇腾处理器深度融合，最快每秒1000个容器的调度发放，成为高性能、极致性价比的批量计算解决方案。深入了解Volcano如果想更加深入了解Volcano，可以参考以下资源：Volcano官网：https://volcano.sh/Github：https://github.com/volcano-shVolcano简介：https://github.com/volcano-sh/volcanoVolcano设计：https://github.com/volcano-sh/volcano/tree/master/docs/designVolcano路线图：https://github.com/volcano-sh/volcano/blob/master/docs/community/roadmap.mdVolcano社区交流微信群：Volcano CN未来可期随着Volcano v1.0的发布，Volcano社区建设与上下游生态的融合必将更加紧密，基于Volcano的商业应用也将极大地促进AI、大数据、科学计算、渲染等领域充分享受到云计算带来的极大便利和极致体验，助力企业数字化转型进入新的高度。展望未来，华为云也将在云原生领域持续耕耘，持续引领创新、繁荣生态，助力各行业走向快速智能发展之路。

在刚刚结束的CLOUD NATIVE+ OPEN SOURCE Virtual Summit China 2020上，由华为云云原生团队主导的容器批量计算项目Volcano正式发布1.0版本，标志着Volcano项目已经开始走向成熟与稳定。Volcano项目介绍Volcano是基于Kubernetes的云原生批量计算引擎，基于华为云在AI、大数据领域的深厚业务积累，补齐了Kubernetes在面向AI、大数据、高性能计算等批量计算任务调度、编排等场景下的短板，向下支持鲲鹏、昇腾、X86等多元算力，向上使能TensorFlow、Spark、华为MindSpore等主流行业计算框架，让数据科学家和算法工程师充分享受到云原生技术所带来的高效计算与极致体验。Volcano架构示意图随着Kubernetes作为AI、大数据和高性能批量计算的下一代基础设施的趋势逐渐清晰，越来越多的企业对Kubernetes在深度学习、科学计算、高性能渲染等方面提出了更高的要求。然而Kubernetes作为普适的容器化解决方案，仍与业务诉求存在一定差距，主要体现在：K8s的原生调度功能无法满足计算要求K8s作业管理能力无法满足AI训练的复杂诉求数据管理方面，缺少计算侧数据缓存能力，数据位置感知等功能资源管理方面缺少分时共享，利用率低硬件异构能力弱Volcano的诞生正是基于这些痛点，在调度、作业管理、数据管理、资源管理四个方面进行了重点优化。增强了任务调度能力，如公平的调度（fair-share）、组调度（gang-scheduling）  进一步优化了作业管理能力,如multiple pod template能力、更灵活的error handling机制  增加计算侧数据缓存，提升数据的传输与读取效率引入多维度的综合评分机制，实现资源更高效的管理和分配多元算力支持：支持x86、鲲鹏和昇腾等算力   Volcano项目进展时间轴Volcano v1.0新特性介绍Volcano v1.0的核心概念和关键特性，主要包含以下要点：Queue、PodGroup、Volcano Job等核心概念均已实现支持Binpack、Conformance、DRF、Gang、Preempt、Reclaim、Priority、Proportion等多种调度策略支持Rest API、CLI等多种交互方式完成与Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore等主流高性能计算框架的无缝对接支持Job的全生命周期管理和动态扩缩容支持GPU异构与共享完备的golangCI-lint check、e2e以建立增强代码质量和稳定性除以上特性外，Volcano始终保持与Kubernetes社区、Golang最新版本保持一致。Volcano社区和生态建设进展经过一年多的发展，Volcano的社区和生态建设已经步入快车道。截至目前，社区和生态建设取得了以下成绩：社区贡献者80+社区贡献参与组织15+，包括华为、百度、腾讯、AWS、IBM、 Oracle等获得Star 1100+，Fork 220+代码库7个，Release 6个Issue 320+，PR 590+已完成对Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore、Cromwell等10+主流计算框架的支持华为云CCE（云容器引擎）、CCI（云容器实例）、ModelArts等多个云服务已将Volcano集成为基础设施底座并商用，服务领域已涵盖AI、大数据应用、基因计算、批处理等场景，并实现与华为鲲鹏、昇腾处理器深度融合，最快每秒1000个容器的调度发放，成为高性能、极致性价比的批量计算解决方案。深入了解Volcano如果想更加深入了解Volcano，可以参考以下资源：Volcano官网：https://volcano.sh/Github：https://github.com/volcano-shVolcano简介：https://github.com/volcano-sh/volcanoVolcano设计：https://github.com/volcano-sh/volcano/tree/master/docs/designVolcano路线图：https://github.com/volcano-sh/volcano/blob/master/docs/community/roadmap.mdVolcano社区交流微信群：Volcano CN未来可期随着Volcano v1.0的发布，Volcano社区建设与上下游生态的融合必将更加紧密，基于Volcano的商业应用也将极大地促进AI、大数据、科学计算、渲染等领域充分享受到云计算带来的极大便利和极致体验，助力企业数字化转型进入新的高度。展望未来，华为云也将在云原生领域持续耕耘，持续引领创新、繁荣生态，助力各行业走向快速智能发展之路。

转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作，但说他“首次提出云原生（CloudNative）的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生，详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务，但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步，各方面都不成熟，Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能，最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起，共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的，它的“Netflix OOS”系列工具至今仍被广泛使用，特别是Java社区，并被移植到其他语言。在这个过程中，也同时开创了云计算的先河，它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算（Cloud）和云原生（Cloud Native）还是有很大区别的。Netflix是云计算的开拓者，但并不是云原生的创造者。云原生的基石是k8s，没有k8s就没有云原生， 而k8s的1.0版诞生于2015年。云原生计算基金会（CNCF）也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行，因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会（CNCF）的定义：下面就让我们看一下CNCF给出的云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”摘要来源：CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，**圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。云技术的三大基石：基础设施即代码 (Infrastructure As Code）基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施（immutable infrastructure）说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API（declarative APIs）声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣，请参见把应用程序迁移到k8s需要修改什么？云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具，请继续阅读下一篇“ 云原生开发环境初探"。索引：Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么？云原生开发环境初探不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考

转载https://blog.csdn.net/enweitech/article/details/90178181?utm_medium=distribute.pc_relevant_bbs_down.none-task-blog-baidujs-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task-blog-baidujs-1.nonecase伴随云计算的滚滚浪潮，云原生（Cloud Native）的概念应运而生，云原生很火，火得一塌糊涂，都2019年了，如果你还不懂云原生，那真的Out了。大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。技术的变革，一定是思想先行，无产阶级革命事业兴旺发达也是因为有战无不胜的马指导。 何谓云原生？云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受媒体采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格（Service Mesh）和声明式API给加了进来。可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微；秒杀传统Web框架，吊打祖传IT模式，实在是保命装逼、评优晋级不可多得的终极绝密武器。 云元素的四要素微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞，不过鄙人对DDD知之甚少。容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。 如何云原生？首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。本地部署的传统应用往往采用C/C++、企业级Java编写，而云原生应用则需要用以网络为中心的Go、Node.js等新兴语言编写。本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。本地部署的传统应用对网络资源，比如IP、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。本地部署的传统应用有些是单体（巨石）应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。可见，要转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：基础架构服务、虚拟化、容器化、容器编排、微服务。幸运的是，开源社区在云原生应用方面做出了大量卓有成效的工作，很多开源的框架和设施可以通过拿来主义直接用，2013年Docker推出并很快成为容器事实标准，随后围绕容器编排的混战中，2017年诞生的k8s很快脱颖而出，而这些技术极大的降低了开发云原生应用的技术门槛。虽说云原生的推介文档有引导之嫌，但面对它列举的优点，作为杠精的我亦是无可辩驳。这么说的话，云原生也忒好了吧，应用是不是要立刻马上切换到云原生架构？我的观点是：理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来。 技术的趋势和影响软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么？又有什么高端玩法？

转载https://blog.csdn.net/enweitech/article/details/90178181?utm_medium=distribute.pc_relevant_bbs_down.none-task-blog-baidujs-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task-blog-baidujs-1.nonecase伴随云计算的滚滚浪潮，云原生（Cloud Native）的概念应运而生，云原生很火，火得一塌糊涂，都2019年了，如果你还不懂云原生，那真的Out了。大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。技术的变革，一定是思想先行，无产阶级革命事业兴旺发达也是因为有战无不胜的马指导。 何谓云原生？云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受媒体采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格（Service Mesh）和声明式API给加了进来。可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微；秒杀传统Web框架，吊打祖传IT模式，实在是保命装逼、评优晋级不可多得的终极绝密武器。 云元素的四要素微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞，不过鄙人对DDD知之甚少。容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。 如何云原生？首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。本地部署的传统应用往往采用C/C++、企业级Java编写，而云原生应用则需要用以网络为中心的Go、Node.js等新兴语言编写。本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。本地部署的传统应用对网络资源，比如IP、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。本地部署的传统应用有些是单体（巨石）应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。可见，要转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：基础架构服务、虚拟化、容器化、容器编排、微服务。幸运的是，开源社区在云原生应用方面做出了大量卓有成效的工作，很多开源的框架和设施可以通过拿来主义直接用，2013年Docker推出并很快成为容器事实标准，随后围绕容器编排的混战中，2017年诞生的k8s很快脱颖而出，而这些技术极大的降低了开发云原生应用的技术门槛。虽说云原生的推介文档有引导之嫌，但面对它列举的优点，作为杠精的我亦是无可辩驳。这么说的话，云原生也忒好了吧，应用是不是要立刻马上切换到云原生架构？我的观点是：理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来。 技术的趋势和影响软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么？又有什么高端玩法？

转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作，但说他“首次提出云原生（CloudNative）的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生，详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务，但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步，各方面都不成熟，Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能，最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起，共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的，它的“Netflix OOS”系列工具至今仍被广泛使用，特别是Java社区，并被移植到其他语言。在这个过程中，也同时开创了云计算的先河，它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算（Cloud）和云原生（Cloud Native）还是有很大区别的。Netflix是云计算的开拓者，但并不是云原生的创造者。云原生的基石是k8s，没有k8s就没有云原生， 而k8s的1.0版诞生于2015年。云原生计算基金会（CNCF）也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行，因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会（CNCF）的定义：下面就让我们看一下CNCF给出的云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”摘要来源：CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，**圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。云技术的三大基石：基础设施即代码 (Infrastructure As Code）基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施（immutable infrastructure）说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API（declarative APIs）声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣，请参见把应用程序迁移到k8s需要修改什么？云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具，请继续阅读下一篇“ 云原生开发环境初探"。索引：Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么？云原生开发环境初探不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考

DevRun线下沙龙西安站-《GaussDB(for MySQL)云原生数据库技术演进之路》材料下载，欢迎大家来交流！