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)云原生数据库技术演进之路》材料下载，欢迎大家来交流！

学习一门新知识或者一项新技术，需要经过哪些阶段？ 一般来说，我们会将整个学习路径分解为“了解-学习-掌握”3个阶段，也可以对应称之为“认知-还原-创造”。围绕云原生的主题，遵循“认知-还原-创造”的规律，我们整理了50+位技术大咖的课程视频，形成《华为云技术开放视频合集》，并限时免费开放给大家观看学习。（领取方式见文末） 认知篇：站在巨人的肩膀上快速成长 如果你对某项新技术是陌生的，那么通过读书来理解它的理念和思路是最快速有效的方式。华为云组织的“云享读书会”每期分享都会精选一本畅销的技术书籍，邀请作者进行解读。《华为云技术开放视频合集》收录了云享读书会的分享视频，包括王立杰、许舟平、姚冬、徐磊4位老师共同解读《敏捷无敌之DevOps时代》、刘华老师解读《猎豹行动-硝烟中的敏捷之旅》、王明兰老师解读《敏捷转型-打造VUCA时代的高效能组织》。 还原篇：抓住核心技术理念快速落地 对新技术有了初步了解后，还需要进一步探求其背后的核心技术理念，云原生包括DevOps、持续交付、持续运维、持续测试、微服务架构等，核心是持续交付，而持续交付的落地，需要从工程价值链、微服务架构、团队管理等方面进行深入学习。 《华为云技术开放视频合集》包括王小刚老师讲解的《重视产品“价值旅程”提升产品“运营质量”》、孙玄老师讲解的《见微知著-微服务总体架构设计思路》、姚冬老师讲解的《如何构建高效的持续交付能力》、朱少民老师分享的《软件质量的深奥与简洁》、唐志辰老师讲解的《京东数科DevOps中的质量管控》、林伟丹老师讲解的《ICE-CReam：成为敏捷回顾的引导高手》、杨瑞老师分享的《OKR与敏捷绩效管理》等多门课程，从工程实践、架构设计、质量管控、团队管理等多个方面掌握持续交付的方法。 创造篇：云时代的研发与交付创新 掌握了一项新的技术后，你可以站在技术发展趋势、行业发展趋势、业务发展趋势的角度去尝试创新。云原生理念是对工程实践的指导，想要实现随时随地的持续交付，云化发展显然更有优势。 《视频合集》还收录了“中国DevOpsDays华为专场”的分享视频，包括谈宗玮老师分享《软件DevOps云化发展趋势》、赵彦老师分享《交付在云端-全云DevOps研发实践》等。  —— 分割线 —— 《华为云技术开放视频合集》共收录50+视频课程，分别来自于华为云技术开放日、云享读书会、中国DevOpsDays华为专场、DevOps meetup等活动，华为云邀请技术大咖，从不同角度分享、解读云原生实践经验，让持续交付理念能够在更多软件研发团队中落地。 福利：《华为云技术开放视频合集》限时免费开放，识别下图二维码即可观看全部课程视频。 

【转载华为云社区】近日，全球权威咨询机构IDC发布《PRC SDC Software Market Overview, 2019H2/2019》报告。报告显示，华为云容器软件市场份额排名位居国内厂商第一、全球厂商第二。目前，华为云容器已构建起包括八大基础服务、四大解决方案在内的全栈容器产品，广泛服务于泛互联网、金融、政府、制造、生物等行业客户。华为云容器八大基础服务包括云容器引擎（CCE）、云容器实例（CCI）、CCE@华为云Stack、智能边缘平台（IEF）以及配套的应用管理、运维等服务，提供高性能、高可靠、易运维的容器基础能力。同时，针对行业客户云原生转型过程中的差异化诉求，华为云推出了裸金属容器解决方案、混合云容器解决方案、容器批量计算解决方案和边缘容器解决方案，帮助客户实现降本增效，推动业务创新。华为云是最早一批投身云原生技术的厂商，并于2015年参与了云原生计算基金会（CNCF）的组建，是CNCF国内唯一的初创成员。5年来，华为云在云原生领域持续深耕，社区代码贡献和Maintainer席位数均位居国内第一，并贡献了首个云原生边缘计算项目KubeEdge和批量计算项目Volcano，持续引领云原生技术发展方向。同时，华为云还是云原生产品的开创者，自2016年以来首发了一系列业界领先的容器产品与解决方案。目前，华为云业务发展已驶入快车道，营收规模、付费用户数、基础设施规模等迅速增长。截至2020年6月，华为云已经上线210多个云服务，200多个行业和通用解决方案，300万企业和开发者基于华为云进行云端开发。根据Garnter市场研究报告，2019年华为云全球IaaS市场排名上升至第六，增速高达222.2%，全球增速最快。在新基建时代下，算力成为新的生产力，数据成为新的生产要素，云、AI、5G则是新的生产工具，新型数字基础设施正在为政企数字化转型注入新动能。华为云创新发展，持续提供稳定可靠、可持续发展的云服务，致力于成为政企数字化转型和智能化升级的首选。更多精彩内容，尽在“华为云”公众号~

近日，全球权威咨询机构IDC发布《PRC SDC Software Market Overview, 2019H2/2019》报告。报告显示，华为云容器软件市场份额排名位居国内厂商第一、全球厂商第二。数据来源：IDC《PRC SDC Software Market Overview, 2019H2/2019》目前，华为云容器已构建起包括八大基础服务、四大解决方案在内的全栈容器产品，广泛服务于泛互联网、金融、政府、制造、生物等行业客户。华为云容器八大基础服务包括云容器引擎（CCE）、云容器实例（CCI）、CCE@华为云Stack、智能边缘平台（IEF）以及配套的应用管理、运维等服务，提供高性能、高可靠、易运维的容器基础能力。同时，针对行业客户云原生转型过程中的差异化诉求，华为云推出了裸金属容器解决方案、混合云容器解决方案、容器批量计算解决方案和边缘容器解决方案，帮助客户实现降本增效，推动业务创新。华为云是最早一批投身云原生技术的厂商，并于2015年参与了云原生计算基金会（CNCF）的组建，是CNCF国内唯一的初创成员。5年来，华为云在云原生领域持续深耕，社区代码贡献和Maintainer席位数均位居国内第一，并贡献了首个云原生边缘计算项目KubeEdge和批量计算项目Volcano，持续引领云原生技术发展方向。同时，华为云还是云原生产品的开创者，自2016年以来首发了一系列业界领先的容器产品与解决方案。目前，华为云业务发展已驶入快车道，营收规模、付费用户数、基础设施规模等迅速增长。截至2020年6月，华为云已经上线210多个云服务，200多个行业和通用解决方案，300万企业和开发者基于华为云进行云端开发。根据Garnter市场研究报告，2019年华为云全球IaaS市场排名上升至第六，增速高达222.2%，全球增速最快。在新基建时代下，算力成为新的生产力，数据成为新的生产要素，云、AI、5G则是新的生产工具，新型数字基础设施正在为政企数字化转型注入新动能。华为云创新发展，持续提供稳定可靠、可持续发展的云服务，致力于成为政企数字化转型和智能化升级的首选。

转载自华为云微信公众号原文链接：https://mp.weixin.qq.com/s/VEw8VyeG_5eoGdMSktR4CQ近日，全球权威咨询机构IDC发布《PRC SDC Software Market Overview, 2019H2/2019》报告。报告显示，华为云容器软件市场份额排名位居国内厂商第一、全球厂商第二。数据来源：IDC《PRC SDC Software Market Overview, 2019H2/2019》目前，华为云容器已构建起包括八大基础服务、四大解决方案在内的全栈容器产品，广泛服务于泛互联网、金融、政府、制造、生物等行业客户。华为云容器八大基础服务包括云容器引擎（CCE）、云容器实例（CCI）、CCE@华为云Stack、智能边缘平台（IEF）以及配套的应用管理、运维等服务，提供高性能、高可靠、易运维的容器基础能力。同时，针对行业客户云原生转型过程中的差异化诉求，华为云推出了裸金属容器解决方案、混合云容器解决方案、容器批量计算解决方案和边缘容器解决方案，帮助客户实现降本增效，推动业务创新。华为云是最早一批投身云原生技术的厂商，并于2015年参与了云原生计算基金会（CNCF）的组建，是CNCF国内唯一的初创成员。5年来，华为云在云原生领域持续深耕，社区代码贡献和Maintainer席位数均位居国内第一，并贡献了首个云原生边缘计算项目KubeEdge和批量计算项目Volcano，持续引领云原生技术发展方向。同时，华为云还是云原生产品的开创者，自2016年以来首发了一系列业界领先的容器产品与解决方案。目前，华为云业务发展已驶入快车道，营收规模、付费用户数、基础设施规模等迅速增长。截至2020年6月，华为云已经上线210多个云服务，200多个行业和通用解决方案，300万企业和开发者基于华为云进行云端开发。根据Garnter市场研究报告，2019年华为云全球IaaS市场排名上升至第六，增速高达222.2%，全球增速最快。在新基建时代下，算力成为新的生产力，数据成为新的生产要素，云、AI、5G则是新的生产工具，新型数字基础设施正在为政企数字化转型注入新动能。华为云创新发展，持续提供稳定可靠、可持续发展的云服务，致力于成为政企数字化转型和智能化升级的首选。欢迎扫码关注！

关于码豆发放的特别通知！关于码豆发放的特别通知！为保证您顺利领取码豆，请您至少登录一次DevCloud会员中心https://devcloud.huaweicloud.com/bonususer/home。如您修改过用户名还请一并提供修改前的以及最新的用户名。详情请咨询版主或添加小助手微信（Huawei-HDZ）备注“补发码豆”，反馈时间截至2020年8月1日，如您在此之前没有反馈，视为自动放弃获奖资格。直播时间2020年 7月3日  14:00-15 :00观看回放 请戳我>>传送门 本次直播讲解通过介绍Docker容器技术引出Kubernetes为代表的编排工具，逐步剖析企业应用通过容器化改造去达到云原生应用，并实现快速的根据业务要求进行高性能的伸缩，实现真正的降本增效维稳。专家介绍叶康铭ProtonTech 技术总监华为云云享专家云原生社区联合创始人 现任外企VP技术总监，经历过从原始物理机时代发展到云时代的变迁，熟悉国内外各大云产商服务，擅长使用云技术提供大流量、大并发的架构设计和在云上采用敏捷方式进行快速交付迭代，以及对大数据场景下企业应用落地设计提供解决方案观看直播幸运抽大奖小助手会在直播公屏中随机抽取优质互动观众赠送 数据线、HDZ笔记本~参与微话题讨论赢HUAWEI 平板讨论话题：您所在的企业有在运用云原生或者正在考研阶段吗，对于云原生的期待或者要解决的问题有哪些？当发帖盖楼人数>10人时由专家评选出5名优秀开发者，分别抽取 一等奖*1 华为平板 M6 10.8英寸 4GB+128GB 全网通（银钻灰）二等奖 *1 HUAWEI WATCH GT 2 运动款 曜石黑三等奖*3 智能体脂秤2pro（本话题回复时间截止 7月10日 24时）》更多彩蛋活动请戳我《注意事项 1、活动的中奖名单和码豆奖励名单将于话题结束后3天完成公示，7月10日后统一发放，请提前登录DevCloud会员中心了解码豆；2、本次< HDZ summit 2020 >活动发放的码豆奖励将在2020年9月1日0点失效；3、本活动最终解释权归华云所有。4、预约直播获500码豆活动时间截至7月2日24时大会更多议程活动时间：2020年7月3日时间安排活动类型主题主讲人传送门9:00-10:00技术分享新基建下的金融科技   马超点击前往10:00-11:00技术分享华为云助力开放平台生态建设   姚冬点击前往11:00-12:00圆桌座谈学技能交朋友，大咖教你如何挖宝社区    大妈   ：中国Python社区核心贡献者    Miya ：freeCodeCamp 中文社区大使    赵旭东：HDZ社区发起人    潘永斌：MDG社区 重庆核心组、华为云 云享专家    王新：HDZ社区 武汉核心组点击前往14:00-15:00技术分享云原生实践指南    叶康铭点击前往15:00-16:00技术分享知识图谱技术及其在自动驾驶网络中的应用    刘瑞宏点击前往16:00-17:00圆桌座谈大咖分享，社区如何助力个人职业发展    红薯   ：开源中国创始人    马全一 ：华为开源运营专家，openEuler社区核心    熊保松 ：小熊派开源社区创始    庄表伟：开源社理事长    任政：HDZ 深圳核心组点击前往17:00-17:30颁奖2019年度HDZ优秀核心组织者等奖项  更多精彩活动                                【活动说明】**实物奖品将于7月15日后统一发放。请添加HDZ小助手微信（Huawei-HDZ），备注“奖品邮寄”，留下获得的奖项截图和您的奖品邮寄信息呦~**超过2020年8月1日仍未提供奖品邮寄信息的同学，视为放弃获奖资格~获奖名单：用户名称获取奖项jiajia635一等奖 华为平板 M6 10.8英寸 4GB+128GB 全网通（银钻灰）kaliarch二等奖  HUAWEI WATCH GT 2 运动款 曜石黑真爱无敌三等奖  智能体脂秤2proHW小龙三等奖  智能体脂秤2prohw84820715三等奖  智能体脂秤2pro