转载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

【转载华为云社区】1.什么是云原生？    容器技术是云原生的基石，云原生应用最典型的特点就是使用容器作为应用的运行环境。为发挥容器了最大优势，往往会使用微服来架构应用，同时结合CI/CD工具和DevOps交付理念，实现应用的高效开发、发布、部署和运维。2.云原生技术为企业带来的价值？【降低基础设施成本】：容器化轻量化及资源的细粒度管理，可以大幅提升资源利用率，减少基础设施成本【缩短应用上线周期】：统一应用打包标准，使应用快速在研发/测试/生产环境间分发、部署，缩短上线周期【快速构建跨云业务】：标准的运行环境和API，使得应用可以在不同厂商的容器平台上无缝迁移、统一管理【提升应用运维效率】：完善的应用生命周期管理能力，灵活、高效的自动扩缩容机制，提升运维效率30%+点击观看视频：https://bbs-video.huaweicloud.com/video/media/20200211/20200211161715_10324/Untitled.mp4https://bbs-video.huaweicloud.com/video/media/20200211/20200211161715_10324/Untitled.mp4点击观看视频：更多产品信息请点击：https://www.huaweicloud.com/product/cce.html0元起体验云原生之旅：https://activity.huaweicloud.com/cloudnative.html?ggw_hd更多产品免费体验申请：https://activity.huaweicloud.com/cloudnative_userinformation.html

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

云原生计算基金会CNCF正式引入技术雷达，这是CNCF社区的一项新计划，有140多家企业参与，定期开会讨论云原生技术的挑战和优秀实践。CNCF表示，引入技术雷达的目标是共享最终用户正在积极使用的工具，推荐的工具和使用方式。据了解，CNCF技术雷达借鉴了Thoughtworks的格式，但与Thoughtworks不同，CNCF技术雷达着眼于评估、试用和采用三个环节，节奏上为每季度一次，每次聚焦在特定用例上的10-20个项目。第一次技术雷达专注在了持续交付(CD)的解决方案。结果显示，Flux和Helm成为被广泛采用的CD工具。在试用上，CircleCI，Kustomize和GitLab获得了多家企业的推荐。在评估上，詹金斯(Jenkins)和Spinnaker等9款工具被企业所熟知，但仅仅是评估，而未被推荐或广泛采用。在持续交付的技术雷达雷达上也表现出一些有趣的特点，比如许多企业会将公开可用的解决方案与企业内部的工具结合在一起，尝试10几种解决方案，并决定采用2-4种。CNCF表示，Helm不仅仅是Kubernetes软件包管理器，而且它已经被广泛使用为不同CD场景的组件。CNCF也指出，虽然Jenkins名声在外，而且被广泛部署，但一些最终用户表示Jenkins主要用于现有部署，而面向未来现代化的应用程序时，会选择如Flux、GitOps等新的CD工具来一起评估Jenkins。下一期的技术雷达将于2020年9月公布，主题可能是安全性或存储，这将由社区对主题进行投票决定。

发文的版块名：云原生发文的标题名：以业务为核心的云原生体系建设帖子内容链接：https://bbs.huaweicloud.com/blogs/172275

         转载自：https://bbs.huaweicloud.com/blogs/170483        博文作者：无微不至            “未来的软件一定是生长于云上的”1. 云原生时代的应用云原生时代，随着容器技术、微服务架构思想、产品研发运营模式不断地推陈出新和迅速发展，应用的设计和开发落地门槛已经降低到了历史低点。根据国际知名数据咨询公司IDC（国际数据公司）的调查研究表明，从2018年到2023年将有超过500,000,000个应用被创建，这个数字是过去40年所有创建应用的总和。另外，在IDC于2020年2月发布的《IDC FutureScape: 全球云计算2020 年预测——中国启示》中显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。下面是几条与云原生应用强相关的预测内容：分布式云：到2021年，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。API生态：到2023年，90%的新数字服务将使用公有云和内部API提供的服务构建复合型应用程序；其中一半将利用人工智能（AI）和机器学习（ML）。多云管理：到2022年，50%的企业将部署统一的VMs、Kubernetes和多云管理流程和工具，以支持跨本地和公有云部署的多云管理和治理。云堆栈扩展：到2024年，10%的企业内部工作负载将由公有云服务商数据中心以外的、位于客户数据中心和边缘位置的公有云堆栈提供支持。超敏捷APP：到2023年，50%的中国企业应用将部署在容器化的混合云/多云环境中，以提供敏捷的、无缝的部署和管理体验。在这场应用的变革中，越来越多的应用所有方会将应用基础设施交由更加专业的公有云/混合云服务商进行管理，通过API的方式对基础设施进行管理，由服务商提供更加敏捷和无缝的部署管理功能。如此，应用所有方可以将更多的投资及人力投入聚焦到应用本身的业务逻辑设计、开发、运维和体验优化，大大减少了产品上市的时间并得到了更高的可伸缩性，使应用开发的ROI（投资回报率）最大化。2. 使用微服务架构构建云原生应用云原生应用的定义有多种版本，最早为2015年pivital提出了云原生应用的定义，随后CNCF在2015年也对云原生应用进行了定义，2018年进行了重定义，具体定义可以参考kubernetes-handbook。可以发现自从云原生的概念出现，微服务架构就是云原生应用中浓墨重彩的一部分。这一节里会讲到微服务架构使用场景，微服务应用在整个应用技术栈中的位置，和开发一个微服务你需要做的事情。2.1. 使用微服务的场景构建云原生应用，首先一定是企业或者个人想要最大程度将自己的时间和精力从复杂的底层依赖开发维护中解放出来，集中在业务场景的设计和实现上，并且能够独立解耦的自动化完成应用各个模块的开发落地。这意味着独立开发的某一模块或负责某一单独业务的开发者，会最大程度的利用云厂商提供地DevOps工具链完成整个应用开发运维的共同目标，这样大家可以轻松地将应用作为一个松耦合的服务集合快速发布和更新，降低成本的同时也更容易避免单点故障。2.2. 微服务应用在技术栈中的位置假设应用所有者已经做好了微服务的业务设计，我们来看看在落地阶段，微服务应用在产品研发和运行中的位置： 红色部分为微服务应用的核心模块，是由应用所有者开发和维护地运行时微服务应用。随着业务的增长，受系统能力影响，为了提高微服务的高可用、可靠性以及韧性，需要对微服务进行治理。常见的治理手段有：负载均衡、熔断、限流、降级、容错和隔离等，篇幅有限这里不加赘述。黄色部分从左到右代表从Dev到Ops的技术栈。首先，应用开发者需要根据应用类型，选择依赖的微服务开发框架（chassis），使用框架时可以通过添加注解的方式，处理微服务运行时面临的横切面问题（crosscutting concern），比如：日志框架（log4j/logback）、健康检查、metrics、分布式追踪等。其次，编码完成后，可使用云服务厂商提供的DevOps工具链能力实现代码的归档、编译构建、发布部署等能力，将微服务部署在运行环境中。最后，还可以利用云服务厂商提供的运维能力对微服务进行运维监控。一般来说，云服务厂商提供的应用平台能力也是独立而解耦的，应用所有者可根据自己的需求和预算来自定义选择自己需要的服务。紫色部分是运行时技术栈，蓝色箭头代表流量的流向。当微服务部署运行起来后，流量会从各种客户端首先连接到入口（比如服务网关/ELB），同时，流量在这里会根据请求特征分发到各个对应的业务处理微服务，随后对请求进行一系列的处理，返回结果。微服务的运行还依赖了很多中间件，比如：缓存、消息等；还有一些微服务的功能特性，比如：服务网格、服务注册发现等，这些中间件或特性也都由框架或者云服务厂商提供。微服务和中间件等其实都是上层服务部署在基础设施上，比如：虚机、容器或CCI实例。 综上所述，一个应用的落地其实涉及到很多技术和场景，使用微服务架构开发应用可以最大程度的简化应用所有者对底层设施和中间件的管理运维，通过自定义使用云服务厂商提供地全场景、端到端的应用平台能力，将资源聚焦在业务创新和落地上（红框部分）。3. 实践 - 一元体验all above最后打个小广告：华为云CSE微服务平台提供了以ServiceComb开源框架拖底的配置中心和服务中心，提供动态配置和可靠的服务中心服务。ServiceComb服务中心在华为内部的大规模生产实践（支撑华为商城运行），支撑起数十万级别的tps的服务集群，可靠性得到了充分的验证。开发者可以在云上享受开箱即用的微服务中间件，通过CSE微服务平台既可以学习实践又能作为生产实践，学习微服务可以跟进当下最新技术潮流。华为云回馈活动指路↓一元体验原价500元包周期引擎（100实例），快来体验吧！https://activity.huaweicloud.com/paas_devcloud0.html铛铛铛~新用户体验，还有码豆回馈，豪礼多多喔！CSE还提供了免费试用产品（20实例）回馈广大开发者，快来试用吧https://console.huaweicloud.com/servicestage/?region=cn-east-2&package=basic&new=true#/appdev/engine/list 

转载自：CSDN博主「华为云」的原创文章原文链接：https://blog.csdn.net/devcloud/article/details/106492124【摘要】 云原生应用时代，如何集中团队力量在业务场景设计和实现，从而最大化软件研发ROI？如何利用云服务厂商，高效率低成本的开发高性能高可靠的微服务应用？                   “未来的软件一定是生长于云上的”1. 云原生时代的应用云原生时代，随着容器技术、微服务架构思想、产品研发运营模式不断地推陈出新和迅速发展，应用的设计和开发落地门槛已经降低到了历史低点。根据国际知名数据咨询公司IDC（国际数据公司）的调查研究表明，从2018年到2023年将有超过500,000,000个应用被创建，这个数字是过去40年所有创建应用的总和。另外，在IDC于2020年2月发布的《IDC FutureScape: 全球云计算2020 年预测——中国启示》中显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。下面是几条与云原生应用强相关的预测内容：分布式云：到2021年，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。API生态：到2023年，90%的新数字服务将使用公有云和内部API提供的服务构建复合型应用程序；其中一半将利用人工智能（AI）和机器学习（ML）。多云管理：到2022年，50%的企业将部署统一的VMs、Kubernetes和多云管理流程和工具，以支持跨本地和公有云部署的多云管理和治理。云堆栈扩展：到2024年，10%的企业内部工作负载将由公有云服务商数据中心以外的、位于客户数据中心和边缘位置的公有云堆栈提供支持。超敏捷APP：到2023年，50%的中国企业应用将部署在容器化的混合云/多云环境中，以提供敏捷的、无缝的部署和管理体验。在这场应用的变革中，越来越多的应用所有方会将应用基础设施交由更加专业的公有云/混合云服务商进行管理，通过API的方式对基础设施进行管理，由服务商提供更加敏捷和无缝的部署管理功能。如此，应用所有方可以将更多的投资及人力投入聚焦到应用本身的业务逻辑设计、开发、运维和体验优化，大大减少了产品上市的时间并得到了更高的可伸缩性，使应用开发的ROI（投资回报率）最大化。2. 使用微服务架构构建云原生应用云原生应用的定义有多种版本，最早为2015年pivital提出了云原生应用的定义，随后CNCF在2015年也对云原生应用进行了定义，2018年进行了重定义，具体定义可以参考kubernetes-handbook。可以发现自从云原生的概念出现，微服务架构就是云原生应用中浓墨重彩的一部分。这一节里会讲到微服务架构使用场景，微服务应用在整个应用技术栈中的位置，和开发一个微服务你需要做的事情。2.1. 使用微服务的场景构建云原生应用，首先一定是企业或者个人想要最大程度将自己的时间和精力从复杂的底层依赖开发维护中解放出来，集中在业务场景的设计和实现上，并且能够独立解耦的自动化完成应用各个模块的开发落地。这意味着独立开发的某一模块或负责某一单独业务的开发者，会最大程度的利用云厂商提供地DevOps工具链完成整个应用开发运维的共同目标，这样大家可以轻松地将应用作为一个松耦合的服务集合快速发布和更新，降低成本的同时也更容易避免单点故障。2.2. 微服务应用在技术栈中的位置假设应用所有者已经做好了微服务的业务设计，我们来看看在落地阶段，微服务应用在产品研发和运行中的位置：红色部分为微服务应用的核心模块，是由应用所有者开发和维护地运行时微服务应用。随着业务的增长，受系统能力影响，为了提高微服务的高可用、可靠性以及韧性，需要对微服务进行治理。常见的治理手段有：负载均衡、熔断、限流、降级、容错和隔离等，篇幅有限这里不加赘述。黄色部分从左到右代表从Dev到Ops的技术栈。首先，应用开发者需要根据应用类型，选择依赖的微服务开发框架（chassis），使用框架时可以通过添加注解的方式，处理微服务运行时面临的横切面问题（crosscutting concern），比如：日志框架（log4j/logback）、健康检查、metrics、分布式追踪等。其次，编码完成后，可使用云服务厂商提供的DevOps工具链能力实现代码的归档、编译构建、发布部署等能力，将微服务部署在运行环境中。最后，还可以利用云服务厂商提供的运维能力对微服务进行运维监控。一般来说，云服务厂商提供的应用平台能力也是独立而解耦的，应用所有者可根据自己的需求和预算来自定义选择自己需要的服务。紫色部分是运行时技术栈，蓝色箭头代表流量的流向。当微服务部署运行起来后，流量会从各种客户端首先连接到入口（比如服务网关/ELB），同时，流量在这里会根据请求特征分发到各个对应的业务处理微服务，随后对请求进行一系列的处理，返回结果。微服务的运行还依赖了很多中间件，比如：缓存、消息等；还有一些微服务的功能特性，比如：服务网格、服务注册发现等，这些中间件或特性也都由框架或者云服务厂商提供。微服务和中间件等其实都是上层服务部署在基础设施上，比如：虚机、容器或CCI实例。 综上所述，一个应用的落地其实涉及到很多技术和场景，使用微服务架构开发应用可以最大程度的简化应用所有者对底层设施和中间件的管理运维，通过自定义使用云服务厂商提供地全场景、端到端的应用平台能力，将资源聚焦在业务创新和落地上（红框部分）。3. 实践 - 一元体验all above最后，华为云CSE微服务平台提供了以ServiceComb开源框架拖底的配置中心和服务中心，提供动态配置和可靠的服务中心服务。ServiceComb服务中心在华为内部的大规模生产实践（支撑华为商城运行），支撑起数十万级别的tps的服务集群，可靠性得到了充分的验证。

文作者：乔雷  原华为PaaS架构师/系统和软件工程师，现Cloud BU中国业务技术支持部解决方案架构师摘要：华为云迄今为止已经有14大类超过100种服务了，并且更多的新服务还在不断上线中。众多的服务不仅让客户眼花缭乱，要理解这些服务并根据客户的需求做出合理的解决方案，即使是专业的技术人员也有时候力不从心。本文试图以华为云如何使能云原生应用（Cloud-Native）这一场景，以一张图的方式梳理一下对华为云服务的理解。1. 关于云原生应用云原生应用（Cloud-Native）这两年很热门，例如拥有火爆的Kubernetes项目的CNCF的全称就是Cloud Native Computing Foundation。不同的人对云原生应用有着不同的理解，我个人比较倾向Pivotal公司一个比较狭义的定义：Cloud-Native=DevOps+continuous delivery+ microservices+containers。详情请见：https://pivotal.io/cloud-native2. 华为云如何使能云原生应用以下这张图，来自我画的一张Huawei Cloud Enables Cloud-Native Applications的PPT，重点讲解华为云如何使能云原生应用。我引用在这里供大家参考和探讨。概要解释如下：服务开发者使用华为云的软件开发云(DevCloud）完成DevOps中的Dev部分。一般用户会有几个环境，例如：开发（Develop），测试（Test），预生产（Pre-Live），生产(Live）。名称和阶段可能不同，但大致如此。DevCloud支持灵活定义各个阶段和每个阶段的动作。软件以微服务的方式开发，用华为云的微服务引擎(CSE)管理。部署应用时可以通过应用编排服务(AOS）编排应用，资源模板服务(RTS）编排资源。AOS是华为自研的遵循TOSCA规范的应用编排服务，RTS是华为云兼容OpenStack Heat标准的资源编排服务。微服务运行在容器服务（CCE）或者虚拟机（ECS）或者其它计算实例中。这些计算实例会挂载存储资源，例如块存储（EVS），文件系统服务（SFS）；同时，这些微服务可能会用到一些中间件服务，例如关系型数据库（RDS），分布式缓存（DCS），分布式消息服务（DMS），文档数据库（DDS）等。微服务提供的能力通过API网关和弹性负载均衡（ELB）向外暴露，供第三方应用开发者调用，形成API经济。对外的IP地址可以通过安全服务，例如Anti-DDoS，WAF等保护起来。微服务本身会调用部署在用户私有云的其它后端服务，这部分服务的生命周期不由华为云管理，可以通过云目录服务（CCS）接入。身份认证（IAM）、基础设施监控（CES）、日志服务（LTS）、云审计服务（CTS）、应用性能监控（APM）、应用运维服务（AOM）等构成了通用的管理服务。其中CES和华为云20+云服务集成，提供数百个监控项。AOM和APM一起可以提供比较完整的应用运维。微服务云应用平台（ServiceStage）是一个一站式的提供云原生应用端到端生命周期管理的平台。微服务产生的日志和记录等，可以作为大数据/AI（EI）的数据源。如下：历史数据/批处理/离线处理：MRS(HDFS->HBase->Spark)或者OBS->UQuery（小型场景）流数据/实时/在线处理：MRS(Flume->Kafka->Storm)或者DIS->CloudStream深度学习：OBS的离线数据（定时/批量训练），或者Cloud Stream的流数据（增量训练）进入深度学习服务（DLS）进行模型训练，然后进行模型发布，进行预测。预测能力通过REST APIs的方式发布，和服务进行集成。当然以上只是典型场景的描述，也并没有涵盖所有的华为云服务。但是把华为云如何使能云原生应用基本说清楚了。3. 一张更详细的图PPT一页太小了，很多东西画不下。因此我用visio画了一张更详细一点的，供参考。如下： 原文地址：https://bbs.huaweicloud.com/forum/thread-8355-1-1.html