学习一门新知识或者一项新技术，需要经过哪些阶段？ 一般来说，我们会将整个学习路径分解为“了解-学习-掌握”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

前言：这篇文章介绍阿里云部署计算型存储节点的过程中所做的一些工作，目的是为了使云原生关系数据库能够经济高效地支持分析型工作负载。借助其计算存储分离架构，云原生关系数据库必须将前端数据库节点（计算节点）中的某些数据密集型任务（例如表扫描）下推到后端存储节点以便高效支持分析工作负载。然而，设计人员认为保持存储节点的成本效益是一个挑战（这个也是本文从始至终需要克服的一个问题）。他们利用新兴的计算型存储来解决这个问题：通过以计算型存储替代传统的固态硬盘存储驱动器，存储节点可以利用存储节点内嵌的计算能力，更高效地服务于表扫描（本文要解决的一个问题）。这个简单的想法实现起来并不容易，需要整个软件栈（即数据库，文件系统和I/O）和硬件（即计算存储驱动器）层的协同创新。这篇文章介绍阿里云原生关系数据库POLARDB使用计算型存储高效支持分析型工作负载的部署及其在阿里云中的整体设计，讨论实施面临的主要挑战，并提出为解决这些问题而设计的算法流程。下面的文章的观点和技术解读。前言       云原生关系数据库能够为分析工作量提供足够的支持是令人感到相当满意的一个特性。鉴于云原生关系数据库已经将计算和数据存储，网络解耦。因此数据库节点（计算节点）和存储节点之间的带宽变为稀缺资源。但是，这个体系架构对于经常涉及大量数据访问的分析型工作负载不太友好。特别是，为了更好地服务于OLTP工作负载，云原生关系型数据库通常使用便捷的行存储数据模型（或行列混存[5]）。这可能会进一步加剧网络带宽资源的消耗。为了支持分析工作负载且不会引发太大的网络流量开销，几乎唯一可行的选择是将频繁访问数据的任务（特别是表扫描）从数据库节点卸载到存储节点。这个想法已被数据库厂商相应的产品（例如Oracle Exadata）和开源数据库（例如，MySQL NDB Cluster）采用。尽管概念简单，它在云原生背景下的实际应用却相当不容易（这也是本文需要解决的问题）。一方面，每个存储节点必须能够处理繁重的表扫描任务，这需要大大增加每个存储节点的数据处理能力。另一方面，控制云原生数据库的成本维持在较低的水平，不应显著（甚至适度）增加成本。阿里云的设计人员对这个问题的解决方法是给CPU配备专用硬件(FPGA,GPU)，以异构计算方式实现计算能力的增强却不显著增加成本。中心思想是将表扫描任务卸载和分散到存储节点内部的各个存储设备上。对比使用专用的集中式计算设备（例如，基于FPGA/GPU的PCIe卡）承担表扫描操作的做法，将表扫描任务分解并且分配给最接近数据的存储驱动器可以最大程度地减少存储/内存之间的数据流量并消除了数据处理的热点。这个方法在应用过程中最大的两个挑战是：1）如何在整个软件栈中实际支持表扫描算法下推操作；2）如何低成本地实现高性能的表下推操作。在结合阿里云的POLARDB实现这一简单想法的过程中，他们开发了一套的软件/硬件融合的技术以解决上述两个主要问题。为了达到缩短产品开发周期同时确保成本效益，计算型存储驱动器使用以FPGA为中心的主机管理架构。在每个计算存储驱动器内部，只有一个中档低成本Xilinx FPGA芯片可同时处理闪存控制和表扫描。利用高度优化的软件和硬件设计，每个存储驱动器在压缩数据上支持高吞吐量（超过2GB/s）的表扫描操作，同时在IO性能上与高端的NVMe SSD具有可比性。为了POLARDB能够充分利用存储驱动器的能力，他们针对软件栈开发了一系列技术。下面介绍这些设计技术，并详细说明其实施。                                                                                     图1.PolarDB体系结构这一节简要介绍PolarDB的体系结构（对PolarDB感请兴趣的同学，不妨多关注我们华为云的Taurus，架构更先进，性能更优越）。POLARDB是一款由阿里云设计的新型云原生OLTP数据库，是基于云计算框架的下一代关系型数据库。它的设计动机来自阿里云客户的真实需求：大实例存储容量（数十TB）、高TPS、高可扩展和高可用性。PolarDB提供企业级云数据库服务并兼容MySQL和PostgreSQL。图一介绍了PolarDB计算存储分离的架构。数据库计算节点和存储节点是通过高速RDMA网络连接。在POLARDB集群中，只有一个读/写数据库节点处理读写请求，其它节点作为只读节点仅处理读取请求。实例中所有的节点，包括读/写节点和只读节点，访问存储节点上的相同数据副本最小化存储开销。为了确保高可用，PolarDB使用并行化raft协议对数据实施3副本存储。从这个体系结构可以看到，为了支持分析性工作负载，系统不可避免地需要将表扫描等数据访问密集型操作卸载到存储节点进行。否则，网络带宽将会成为系统瓶颈。为了支持这个想法，最简单的操作是对存储节点进行纵向扩展。但是从成本角度考虑，这个方法不具有可操作性。此外，在行存储的数据格式上（大部分OLTP数据库采用行存储）进行表扫描对于CPU的体系结构也不友好，不能充分发挥CPU的能力（高速缓存和SIMD指令资源）。从性能角度考虑，纵向扩展存储节点从性能上也不是最优的。因此，阿里云的设计人员转而使用给存储节点配备专用处理硬件（FPGA和GPU）以便更高效，更经济地支撑表扫描操作。      传统的做法是使用集中式的架构来专门处理表扫描操作。但是他们认为这个做法有以下弊端 1）数据拥堵。所有数据都需要从存储节点移动到FPGA/GPU专用PCIe卡。由于表扫描的数据访问密集性，这个不可避免地对PCIe和DRAM通道造成严重的拥堵；2）系统热点。每个存储节点包含若干的NVMe SSD盘，这些设备可以达到数GB/s的读吞吐量。单个PCIe卡很快达到处理上限，成为系统热点。鉴于从这些角度考虑，他们使用分布式的体系结构。如图2所示。   此外，从成本角度考虑，他们使用基于FPGA的主机控制策略。这可以从以下两个方面减少开发成本，1）可以使用单个FPGA在计算型存储驱动内实现闪存控制与数据计算。对比基于ASIC编程，FPGA的电路级别的可编程性极大减少开发周期与开发成本。2）计算存储驱动完全由主机管理相应的功能（例如，地址映射，请求调度和垃圾回收）。它的主机可管理性质促进了计算存储驱动器无缝融合到现有软件堆栈中。                                                                                                                                           图二.集中式与分布式的体系结构实现                                                                                                          图3.系统整体架构    针对第一个问题。PolarDB团队提出了如图3的体系结构。图3是软件堆栈的整体展示。每个POLARDB数据库服务器都包含称为前端分析处理引擎MPP。为了与MySQL协议兼容，这种分析处理引擎可以解析，优化和使用AST（抽象语法树）以及许多嵌入式优化规则重写SQL。从本质上讲，它将每个SQL查询转换成由运算符和数据流拓扑组成的DAG（有向无环图）执行计划。这种分析处理引擎本身支持将表扫描操作从数据库节点下推到存储节点。因此，无需修改分析处理引擎。如图3所示，为了支持表扫描下推功能，系统必须适当地增强处理引擎下方的整个存储堆栈，包括POLARDB存储引擎、PolarFS（分布式文件系统在POLARDB下），以及计算存储驱动。下面将详细介绍这些模块已实施的增强功能。      PolarDB存储引擎采用类似RocksDB的LSM存储（应该是X-Engine，见sigmod 2018：X-Engine: An Optimized Storage Engine for Large-scale E-Commerce Transaction Processing）。PolarDB本身支持表扫描下推。在最初的实现中，它利用CPU执行这项操作。本文的初衷是将表扫描操作委托给计算型存储驱动，因此需要将表扫描操作从存储引擎再下移到PolarFS。如图3所示，存储引擎按照文件偏移量访问数据块。 每个表扫描请求包含：（1）待扫描的数据在文件中的偏移量（2）表模式（3）应用在表上的评估条件。 同时，POLARDB存储引擎将分配一个内存缓冲区以存储从计算驱动返回的数据，并且每个表扫描请求都包含此内存缓冲区的位置。值得注意的是，PolarFS并不是支持所有的条件查询，例如LIKE操作目前就支持不了。因此PolarDB引擎首先需要将扫描条件解析出来，将能够支持的条件下推。并且，对不支持的条件查询在本地执行。如图3所示，PolarDB需要分布式文件系统PolarFS的支持。PolarFS确保同一个文件位于同一个存储驱动上。PolarDB团队的技术人员在一下方面增强了文件系统PolarFS，（1）假设要扫描的数据跨越m个计算存储驱动，增强的PolarFS将此请求分解为m扫描请求，每个请求独立扫描不同存储驱动上的数据。 （2）对于每个扫描请求，PolarFS将数据位置信息转换为LBA中的偏移量。 如图4所示，增强的PolarFS随后将转换后的基于LBA的位置信息的m个请求转发到底层计算存储驱动。如上文第2.3节所述，计算存储驱动完全由内核空间中的主机端驱动程序管理。该驱动程序将计算存储驱动器对外暴露为NVMe块设备，并且可以提供正常的NVMe I/ O命令。收到PolarFS的每个表格扫描请求后，文件系统会分析查询条件，如有必要将重置查询条件。此外，PolarFS还会进一步将表扫描操作划分为子任务，增加并行度，减少系统资源争夺。PolarDB对底层计算存储驱动的修改主要是统一数据比较操作符，例如全部的数据比较由memcmp实现。此外，修改数据块格式，提升硬件的利用效率，体现在以下方面，（1）计算存储驱动器可以解压缩每个块并检查CRC而不要求POLARDB存储引擎传递的每个数据块大小的信息。 （2）通过在每个数据块开头的字段添加“键数”和“重新启动数”（应该是数据项的结尾和开始处的地方），硬件可以方便地处理每个块中的边界并检测每个块的末尾。 这非常适合硬件的数据顺序处理流程，因此简化了基于FPGA的硬件实现。                                                       系统评估       实验对TPC-H的6个表扫描操作进行评估，对比基于CPU（CPU-based）和基于计算存储驱动的（Computational Storage driver-Base，CSD-based）表扫描吞吐量，CPU利用率，内存带宽占用率以及延迟。                                        图4.a~c,不同测试场景下的表扫描率；d-f，不同测试场景下CPU利用率 图4的a-c显示了表扫描下推关闭的场景下的系统吞吐率。在关闭的情况下，系统的吞吐率随着CPU的增加而增加，这是必然是；在表扫描下推打开的情况下，系统吞吐率随着CPU的增加而急剧增加，这是因为计算存储驱动的表扫描吞吐量随着上层CPU下推的表扫描数据而增加。在CPU数目为4-8的时候，即可达到系统最大吞吐率，大大地节约CPU的使用。图4的d-f显示了，CPU的使用效率可以节省4-8倍左右。                                                                         图5.a-c是PCIe数据移动量；d-f是内存的数据移动量       图5展示了CPU-based与CSD-base的表扫描算法对设备带宽的压力。可以看到在测试语句TS-5的情况下CSD-based的表扫描算法基本消除了PCIe的设备带宽占用，这是因为TS-5(即图4-a)的语句选择率很高，基本过滤了需要处理的数据。而TS-6仅仅涉及投影操作，CPU-based表扫描算法可以更好地处理该类型的扫描。图4-c是平均的PCIe带宽占用。平均而言，在PCIe与内存带宽的占用上，CSD-base的表扫描算法要低8倍左右的带宽占用。                                                                                             图6.节省的查询延迟  图6是在TPC-H的测试的22查询语句上CSD-based的查询的延迟对比CPU-based的查询的提升幅度。可以看到，在22个查询语句上CSD-based表扫描方法节省的延迟平均在40%，最高的延迟时间节省接近70%的时间。个人总结       从目前看来，PolarDB的这个产品有一定的借鉴价值，利用异构计算将表扫描操作下推至文件系统级别，对存储引擎、文件系统以及存储计算驱动分别进行了相应的增强，在性能与成本之间达到一个很好的平衡。在计算与存储分离大行其道的今天，将数据访问密集型的操作下推至存储节点或者是文件系统不是一个可选项，而是一个必选项。同时，云端的OLAP产品迟迟未能有突破性产品面世，或许是受制于HTAP产品的不成熟，亦或是云端基础设施的不充分。虽然PolarDB的这个AP特性能够提升系统在AP方面的性能达40-70%，但是对比微软SQL Server的AP性能在10-100x上提升，实在是相形见绌。未来如何在华为云原生数据库Taurus是实现AP支持是我们重点思考的问题之一。                     

【前言】Taurus是华为对标AWS Aurora的一款重磅云原生数据库。其设计思想是Log-as-database以最小化网络IO，采用计算存储分离的架构。Taurus的市场定位是OLTP的企业级市场以及高端MySQL客户，但兼顾中小客户。技术路线上兼容MySQL/PG生态，减少客户获取成本，降低风险。本文介绍Taurus数据库产品产生的背景、系统架构以及技术细节。此外，我们还对比了AWS Aurora/Aliyun PolarDB与Taurus的一些特性。相关背景             图1. 第一代云数据库系统架构    在移动互联和物联网等新的应用场景之下，半结构化与非结构化数据例如图片、文本、音频、视频等出现爆炸性增长。传统数据库系统难以应对大数据时代下的存储需求，企业客户迫切需要新的数据库产品，具备动态扩缩容、高吞吐量、低成本等。在云计算技术不断成熟的背景之下，云数据库开始崛起，并因为按需扩展、按需付费等优异特性获得中小企业及互联网客户的青睐。云数据库经历了若干时期的发展，逐渐从托管式服务进化到云原生数据库。云原生数据库在某种程度上颠覆了传统数据库的架构设计。因为云环境基本已经提供相应的高可用功能，而大部分云厂商提供的数据库服务并没有利用这个特性从而错过许多优化空间。以MySQL为例子，如图1所示，数据库系统部署在虚拟机和分布式块存储之上。每个数据库有一个主实例和至少一个只读实例。外部客户通过一个虚拟IP(VIP)访问数据库。当主节点发生故障，云端管理软件会将VIP自动切换至新的主实例。主实例和只读实例都将数据存放在云存储的块设备上。主实例将数据页、保证页面原子性的double write以及redo日志通过文件系统接口写入云存储侧，然后将binlog发送到只读节点。只读节点接收到这些binlog之后写入relaylog，然后回放日志重建数据库副本。回放线程也会将这个过程产生的redo日志，binlog和数据页写到云存储。整个系统可以工作，但是却存在如下几个问题。l  存储空间浪费为了确保数据的可靠性，云存储对于写入的数据一般都是采用3副本存储。所有的数据库实例包括主实例和只读实例都是将数据写入云存储。这种情况下，主实例是3副本存储，其它只读实例也是3副本存储，总共消耗3*(N+1)副本的存储空间，其中N为只读实例的个数。理想情况下，整个数据库系统只需为主实例保留一份数据，只读实例可以共享这份数据，那么可以极大地节省存储空间。l  较大的RTO和数据滞后在现有的RDS部署中，数据库系统的高可用取决于主备之间binlog同步和故障切换协议。在事务提交之前，主机将binlog同步至备机，等待备机的ACK。备机将接收到的binlog进行回放，重建数据库副本。主机发生故障的时候，备机只有将binlog回放完成才能接管系统，对外提供服务。在云环境，MySQL将数据存储在远端的分布式云存储上。数据库日常操作产生的磁盘IO都会转化成网络IO。对比本地存储，云存储的优点在于提供了更大以及更可靠的存储空间。它的主要不足在于延迟较大。这直接影响了备机binlog回放性能。虽然MySQL5.6支持MTS特性，但是一个库只有一个回放线程。在最坏的情况下，需要等待数小时备机才能就绪，对外提供服务。MySQL5.7引入MTS多线程并行回放特性，但是帮助有限，这仍然不能从根本上解决问题。本质上而言，主库的更新压力越大，从库回放日志的时间也就越长，接管系统等待的时长随之增加。因此系统的RTO增大。由于从库需要回放日志来反映主库上的更新，备机回放性能的不足使得主从延迟较大。理想的情况下是，主备共享云端的数据，这可以完全消除备机回放过程和开销，极大地缩小RTO和主从滞后。l  计算资源浪费在现有的RDS部署中，创建备机的主要目的是回放binlog，备机不响应任何的客户端请求。这其中主要的原因是防止查询工作负载影响回放进程。类似地，只读副本系统的回放进程也会影响查询性能。如果备机能够消除回放过程，那么系统的所有计算都可以用来相应用户请求。l  系统性能RDS MySQL主实例将redo日志、binlong和数据页(双写)写入远端的分布式云存储。当系统redo存储空间或缓冲区脏页比例达到阈值，MySQ进行checkpoint操作将脏页写入云存储。对比本地存储，云端较大的写时延制约系统的性能，特别是写入性能。在AWS Aurora纯写测试基准下，现有MySQL RDS的QPS是50~60K，而Aurora能够到达110k。在64个虚拟处理核心下，Aurora甚至能够达到200K的QPS。l  网络带宽消耗在当前的RDS部署中，所有数据库实例都会通过网络将其所有数据写入后端云存储。以master为例，一个MySQL master实例需要写redo日志、binlog和数据页(双写)。对于Aurora纯写测试基准，峰值吞吐量为200 K QPS，这转换为70 M字节/秒的重做日志，但是，写数据页将生成另外700 M字节/秒的流量。对于云存储，所有这些都是多副本存储。这仅对于单个数据库实例。在这种带宽消耗规模下，在相同基础架构上运行的数据库实例数量将会很少。此外还有写入放大、大库支撑不足和从库加入时间较长等问题。Amazon首先意识到上述问题，近年来推出的云数据库Aurora就是为云计算时代而专门定制的一款关系型数据库。其目标主要是最小化网络IO，充分利用云基础设施来提升系统的可扩展性与可用性。Aurora的设计哲学是log is database，对数据的更改只写日志，不刷脏页，极大地简化恢复子系统。Amazon宣称Aurora的RTO最大为2分钟左右；可以在秒级时间内完成故障节点切换与扩容，性能对比MySQL5.6可以优10倍。TaurusDB作为一款cloud native的数据库，设计理念类似AWS Aurora，但青出于蓝而更胜于蓝。TaurusDB不仅针对IO与写操作进行了优化，而且还考虑了读优化，让应用程序可以在缓冲区内以最小的代价获得最新的数据，明显区别于国内厂商（腾讯CynosDB基本完全按照AWS Aurora的设计思路，与TaurusDB原型版本设计思路类似，这里我们把它归为AWS Aurora一类）。TaurusDB针对用户痛点进行了相应的技术革新，对比第一代云数据库其优点相当明显。以下是TaurusDB的架构设计，文章的最后是TaurusDB与其它厂商的对比。                                                                                                             TaurusDB特点             图2. 基于DFV共享存储的TaurusDB架构TaurusDB是华为MySQL RDS经历了云盘时代单机版、Active-Standby主备版和金融高可用一主两备三节点架构版本后，作为华为云自研的最新一代cloud native分布式数据库。它采用华为下一代云存储（DFV）实现弹性扩缩容、高可用和共享存储。如图2所示，系统自顶向下分为3大部分，SQL节点、存储抽象层SAL(Storage Abstract Layer)以及存储节点(storage server)。TaurusDB SQL节点形成一个集群，包括一个主节点和多个只读副本（RO，最多15个）。每个集群属于一个云租户，一个租户可以具有多个集群。SQL节点管理客户端连接，解析SQL请求，生成查询执行计划，执行查询以及管理事务隔离。主节点和只读副本之间的通信流量很小，主要交换一些状态信息（DDL更新、slice/pages分配更新和活跃事务列表、只读副本中最旧的读取视图、副本最小LSN）。在故障切换期间，任何只读副本都可以接管集群。只有主SQL节点负责数据库更新和DDL操作，而只读副本处理数据库只读查询，并为客户端提供可重复读（RR）和读已提交（RC）隔离级别。如图2所示,SAL(存储抽象层)是SQL节点和存储层之间的桥接器。SAL包括两个主要组件，SAL SQL模块和DFV存储节点内部的Slice存储。SAL SQL模块为SQL节点（主/只读副本）提供了SAL API，用以与底层存储系统进行交互。如图3所示， SAL SQL模块包含通用日志处理器CLP（Common Log Processor）、数据库分片管理器SM（Slice Manager）、页面读取器PR(Page Reader)以及与只读副本节点同步信息的工具程序。CLP负责将数据库全局重做日志持久到DFV，解析日志并将其分发到相应的DFV分片，并生成同步消息（脏页，活动事务列表，分片持久LSN等）以供只读副本获取。CLP还需要处理数据库崩溃恢复，重新加载已提交的全局重做日志并将其重新分配给所有相应的分片。SM维护分片策略以及页面映射信息，确定何时添加更多的分片以及哪些数据库页面应分配给哪个DFV切片等。页面读取器负责通过查找页面映射信息将特定的页面读取请求路由到相应的切片管理器。SAL SQL模块还为SQL节点与存储系统交互提供了其他一些接口，包括定期将日志清除信息（RecycleLSN）传递到数据库片等。                          图3. SAL-SQL包含的主要模块Slice Store是在DFV存储节点内部运行的插件模块。它需要与DFV存储框架一起使用，用以在相同DFV节点上管理多个数据库片，支持多租户资源共享，并将页面的多个版本提供给SQL节点。如图4所示，对于每个分片，slice Store使用日志目录作为中心组件来管理重做日志和页面数据。Slice store的主要职责是1) 接收分片重做日志，将其持久化并注册到日志目录中；2)接收页面阅读请求并构建特定版本的页面;3)垃圾回收和合并日志。                                                图4.slice store组件TaurusDB存储层建立在华为云存储DFV持久层之上。DFV持久层为上层SQL节点存储提供读写接口，提供跨地域3AZs之间的数据强一致性和可靠性保证。 TaurusDB使用两种模式实现write-optimized以及read-optimized，分别是PLOG模式与iShard模式。PLOG模式提供强一致性保证，而iShard模式实现最终的一致性。TaurusDB SQL节点使用PLOG模式存储整个数据库的WAL重做日志，使用iShard模式对数据在多个存储节点之间进行分片和管理。PLOG以SSD友好的追加写方式使事务提交更快；iShard将redo以页面为单位进行聚合，管理数据分片，实现快速数据读取，并支持超大型数据库（128 TB）。存储层支持多个TaurusDB集群实例，单个存储节点支持多租户数据库分片。部署灵活，可以将PLOG和iShard部署在单独的存储池中或共享同一存储池。在这种体系架构下，整个数据库集群只需一份足够可靠的数据库副本集，极大地节约成本。所有只读副本共享在云存储中的数据，去除数据库层的复制逻辑。一写多读，没有独立的备用实例。主节点发生故障，集群进行切换操作时，只读副本都可以切换为主节点，接管集群服务。为了节省宝贵的网络带宽，只有数据库日志通过网络从数据库计算节点写入 DFV 存储层，没有脏页、逻辑日志和双写的流量。基于 DFV 存储层内的数据库日志重构数据面，独立于上层的计算节点，实现存储和计算分离。为了应对大数据存储需求，TaurusDB利用DFV的切片策略对数据库进行自动分区，对应用透明。单个DFV存储节点可以管理来自不同数据库集群实例的多个分片，实现存储容量无限扩展。TaurusDB的设计中，充分使用了异步线程、批量IO以及流水线工作模式实现写入高性能。这对于有大量写入需求的场景，例如物联网是相当合适的。通过在存储层内嵌数据库插件可以快速读取所需的数据。从这一角度上来说，TaurusDB是一个write-optimized以及read-optimized的数据库系统。总的来说，TaurusDB具有以下的优点：1.   节省资源如上所述，TaurusDB只需一份足够可靠的数据库副本集。所有只读副本共享云存储中的数据。添加只读节点时，只需添加计算节点，无需额外购买存储。只读节点越多，节省的存储成本越多。另外一个值得注意的地方就是数据库去除了复制逻辑，对比主备高可用架构这在一定程度上了节省了网络流量，提升计算节点效率。总体而言，在成本开销上，TaurusDB提供企业级的服务能力，但只有1/10商用数据库的成本。2.   便捷扩展性与高可靠性在第一代云数据库的主从架构下，添加只读时需要拷贝数据，重放 binlog，这要求备库完整地执行一次查询请求，在大数据量情况下速度很慢，尤其是对于采用本地盘方案。主从复制延迟问题会影响主备切换，无法保证 RTO，影响SLA。此外，备份恢复速度很慢，TB级的数据量通常需要耗费数小时，使得数据库扩展性严重受限。对比传统的逻辑复制，物理复制则没有上述缺点。因为物理复制只需在日志指定的存储位置上恢复/应用数据的前置镜像/后置镜像即可，完全跳过了查询执行过程。TaurusDB采用物理复制，减少IO操作的同时，让复制更加可靠、高效，并且几乎不会对性能造成影响。由此带来秒级主备切换、快速动态的读扩展和故障恢复。TaurusDB最高支持扩展到15个只读节点。虽然TaurusDB使用了物理复制，但是基于客户在数据分析和传输上需要Binlog，我们也支持Binlog进行数据同步。得益于底层强一致分布式文件系统DFV的支撑以及TaurusDB架构在数据访问上的设计，TaurusDB支持跨AZ部署，跨region容灾，实现单点故障0中断，满足金融级别可靠性。3.   高性能TaurusDB包含MySQL 8.0的所有重要功能，还在其基础之上进行了大量的优化，例如针对硬件特性的适配与大并发下的优化。TaurusDB对封锁子系统进行了分区，减少了锁表的竞争，并行化死锁检测；在事务子系统上采用Lock-Free数据结构来管理事务子系统的活跃事务列表。除此之外，引入内核特性，例如Query result cache，Query plan cache，Online DDL等提升用户体验。相比于TaurusDB1.0版本，TaurusDB2.0版本在性能表现上有了显著提升，在关键情况下都有了数倍的改进。对比MySQL 8.0的官方版本，TaurusDB2.0的优化改进所带来的效果也非常明显，尤其是物理复制方面具有显著的优势。在纯写情况下，TaurusDB2.0的性能可以比官方MySQL8.0高7倍以上。4.   强悍的备份恢复支撑TaurusDB 引擎采用定制的新一代分布式存储系统DFV，极大提升了数据备份、恢复性能。DFV持久层集群包括多个存储节点。每个存储节点包含多个SSD设备和适应SSD介质的append存储服务进程，提供AppendOnly vs. WriteInPlace的数据写入模式。DFV将数据按多时间点多副本存储，支持海量快照和快照秒级生成。在这种能力支撑之下，基于底层存储系统的多时间点模式，TaurusDB不需增量日志回放，可直接实现按时间点回滚,轻松支持PITR（Point-In-Time-Recovery）特性。TaurusDB将特定计算任务（备份与恢复逻辑）下推到DFV，以便更高效，快速地实现备份、恢复，而上层计算节点专注于业务逻辑处理。在这种模式之下，客户可以通过本地访问数据并直接与第三方存储系统交互，高并发高性能。通过异步数据拷贝外加按需实时数据加载机制， TaurusDB 可在数分钟内达到完整功能可用，实现快速实例恢复。横向比较      TaurusDB 的共享存储架构将数据持久化放入新一代存储中，充分保障数据强一致性和 0 丢失；针对硬件定制上层系统，充分利用 RDMA 网络、NVME SSD 等硬件优势，在这些关键技术上整合创新，使得 TaurusDB 的性能有了质的飞跃。对比目前业界的同类型产品，AWS Aurora和阿里的PoloarDB，TaurusDB的纯写性能方面要优30%左右。从阿里云对外公布的技术资料分析，PolarDB仍然需要将数据页写入存储侧，对数据进行SSD不友好的update-in-place操作。相比Aurora，PolarDB在体系结构上进行了一些创新，例如与数据库交互的IO设计、与现代硬件的适配等。腾讯的CynosDB则基本上参照AWS的Aurora进行设计，也沿用了很多系统概念例如数据段一致LSN(SCL)，MTR完全点(CPL)，最大存储卷MTR完全点(VDL)等。TaurusDB为了应用程序能够在计算节点以最小代价读到最新的数据，另辟蹊径对系统架构进行了不同层面的思考。利用CLP组件实现快速事务提交，利用slice store达到读优化的目的。在这点上，TaurusDB跟SAP HANA的设计思路有类似之处，数据在系统不同阶段有不同的作用。SAP HANA中，数据从行存储形态逐渐转化成列存储，从写优化向读优化演变；而TaurusDB中，日志从开始阶段的写优化通过compact操作向读优化演进。日志兼顾保证系统的持久性与效率。在不同的时期，日志的作用不同。系统恢复阶段，日志通过回放将系统恢复到最新一致性状态；在系统正常运行阶段，日志通过回放将系统最新数据提供给应用程序。并且得益于对多版本数据的剪枝（页面解析plug-in），计算节点可以以最小的代价从存储节点获得最新数据，无需RDMA网络的支撑即可高效完成。这也是TaurusDB能够顺利实现跨AZ部署，跨region容灾的关键点。表一是从用户较关心的角度出发，对TaurusDB，AWS Aurora以及阿里PolarDB“三驾马车”的横向对比。文章的最后，欢迎对taurus感兴趣的技术人员加入我们一起挑战技术巅峰，长风破浪，直挂云帆济沧海！简历发送至zhuyuean@huawei.com                                                    表一 TaurusDB VS. PolarDB VS.Aurora RPO (PITR)RTO       MySQL/PG兼容          系统纯写性能比率    支持跨AZ 只写logTaurusDBY <=30sec               Y                    1 Y      Y阿里PolarDBY >=1min               Y                   0.7 N      NAWS AuroraY <=30sec               Y                   0.7 Y      Y

01 什么是云原生（Cloud Native）      在目前这个互联网时代，无论是中小型企业、还是大型的互联网公司都是可以拥抱到云计算的好处，各大公有云产商的平台提供了接近零的停机时间、无限的扩展性、可控的容错及成本控制等。但我们的业务如何配合云计算达到最大化的收益呢？那么就是云原生，通过云原生构建具有弹性、轻量级、无状态的应用以适应目前互联网发展所需的大流量及大负载服务处理的能力。02 云原生可以解决什么痛点应用需支持快速上线 应用需支持快速扩容 应用需实现故障监控探测 应用需实现故障自我隔离应用需实现故障自我恢复... 03 如何达到云原生      云原生并不是一种具体的技术，具体来说应该是一种思想的集合，包括敏捷、DevOps、CI/CD、微服务、服务治理、容器技术、云计算等，整合并重组以致于推动公司商业业务的发展。也可以说云原生是对技术、管理的一种整合。DevOpsDevOps（Development与Operations的单词组合）DevOps并不是一种技术，而是应用交付的文化，是促进开发、运维、测试3个部门间的沟通协作的整合，目标就是为了快速、稳定的交付应用。传统的开发方式会设计到多个部门，开发人员在对配置修改之后没有通知到运维人员，运维人员缺少对应用的运行环境及应用内部实现的了解，开发周期长等问题，会造成应用在发布时运维人员难以选择正确的运行环境或者配置、开发人员无法感知到应用运行潜在的问题，往往这些问题需要花费大量的时间进行解决。而为了解决这些传统开发方式的问题，就有必要引入DevOps文化。CI/CD持续集成（Continuous Integration）持续集成是指开发人员会持续的将代码更改提交到代码仓库中，更改会触发编译、测试等作业验证此次提交的代码是否满足预期要求，已确保新提交代码可以对原有代码进行集成，已防止新提交的代码造成部署后应用出现问题。持续交付（Continuous Delivery）持续交付是指持续集成的进一步扩展，已经正常通过测试及验证代码的稳定性，下一步就是将代码部署在预发环境中，可以使用自动化的方式重复的进行频繁的交付，这可以避免因为人工配置错误等原因造成问题。持续部署（Continuous Deployment）持续部署是指在持续交付的基础上，证实应用在预发环境中通过测试，将应用自动化的部署到生产环境的过程。有些应用场景也突出持续交付旨在交付构建的产物，而持续部署是负责在构建仓库中将构建产物部署到运行环境中。敏捷（Agile）敏捷是一种软件交付迭代方法，从项目开始就逐步构建应用，而不是试图在即将结束时立即交付所有应用。是将项目分解成一些称为用户故事的用户功能 ，对它们进行优先级排序，然后在较短周期中连续性的交付。微服务（Micro Services）微服务是一种架构模式，将单一大应用拆分成多个独立的轻量级服务，每个服务围绕具体的业务进行构建，服务可支持水平扩展，功能单一且独立。服务之间相互协调、互相配合并可以支持独立部署。服务治理（Service Governance）服务治理是为了实现对服务的生命周期管理与定义策略及规范，主要有服务注册、服务发现、负载均衡、服务限流、服务降级、服务熔断、服务重试、链路追踪、服务配置、API网关等等。主流有Dubbo、Spring Cloud等框架，但这些框架是针对于特定语言，如果有其他语言想要实现同等的服务治理能力，那么需要重复的造轮子去实现。服务网格应求而出，解决了开发语言之间的壁垒，解耦了服务访问者和服务提供者的拓扑，并把服务治理能力下降成通用的能力提供给不同的服务，大大的降低了服务复杂度及减少了开发人员压力。容器技术（Container Technology）容器是基于操作系统隔离的进程，这些进程间是受到资源限制并相互隔离，容器是没有自己的操作系统的，直接共享宿主机的内核，这比传统的操作系统虚拟化更加轻量级。目前容器解决方案主流是Docker，而容器管理解决方案是Kubernetes，为容器化的应用提供部署运行、资源调度、服务发现、动态伸缩、故障自愈等一些功能。云计算（Cloud Computing）云计算是提供按需弹性的计算、存储、网络资源的服务模式，这种模式可以快速提供安全可靠的IT基础设施，例如数据库、消息队列等服务，用户不需要关心太过于底层实现的事情，只需要用很简单的方法就可以接入使用。康威定律（Conway's Law）一个应用最终是什么样子大概率是由企业组织结构决定的，是组织内部、组织之间的沟通结构。要得了一个合理设计的应用或者系统架构，单单从技术方面考量是不够的，还需要从组织架构入手才真正有效。04 云原生总结再回顾下什么是云原生？我认为是软件的未来。而这个未来已经来到。      应用的架构从单机 -> 垂直扩展 -> 水平扩展 -> SOA -> 微服务一直在变革。类似互联网应用总是需要满足快速迭代、高可用性、高性能等，那么首先我们需要将应用设计成无状态并运行于容器平台之上，需要高服务能力时水平伸缩容器组的数量即可，通过容器特性实现高可用等，通过CI/CD打通实现自动化发布流程，服务网格打通语言间的壁垒及重复造轮子的问题，降低开发团队的压力。云原生应用需要与基础架构解耦，可以随意在任何一家公有云或者私有云上运行，并支持水平或垂直的扩展性要求。通过打通技术与管理上的壁垒，将二者更好的结合在一起创造出云原生应用。简单而又重复的事情，应该交由系统自动化去完成，把重点放在创造更多的业务价值上。关于作者叶康铭南开大学计算机系毕业、云计算及云原生的布道者、阿里云认证云栖专家、华为云认证云享专家、深圳HDZ社区核心组织者。熟悉国内外各大云产商，在大规模的服务应用、安全防护、计算平台、架构设计有多年的实践经验及管理方法，致力于让更多人和企业更好认识及应用云计算及云原生。为何书写作为一个布道者，有一个平台提供知识传播能力，帮助更多的人学习并应用云计算、云原生。作为一个技术人，记录下自己走过的技术道路，作为技术的沉淀积累，人生也需要定期的复盘，不断去思考优化调整。未来期待每周会定期输出云原生技术文章、从入门开始逐步剖析深入到企业级的项目中，也分享一些在架构设计领域的技术文章及想法。如果有技术上的问题，也欢迎一起探讨及分享。联系作者添加好友时麻烦请备注来源、公司及名称，谢谢HDZ社区—携手全球开发者 共建开放、创新、多元的开发者社区组织       HDZ是Huawei Developers Zone的英文缩写，是华为开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。      致力于帮助开发者学习提升、互动交流、挖掘机会，推动ICT、互联网等产业生态的建立和发展。      对云计算、IoT、人工智能、5G、区块链、鲲鹏、昇腾、软件开发与运维、开源等各技术领域感兴趣的开发者、软件工程师、创业者、运营人、产品人、大学生、老师等都可以参与到HDZ。      HDZ秉承开放、创新、多元的社区文化，完全由各地HDZ组织者、志愿者自发组建和领导。华为公司不直接参与HDZ组织建设和领导，只按需对HDZ社区活动提供必要的方向指导、资源支持、活动支撑等，并为各地HDZ组织者提供与全国组织者互动交流的机会。扫描上方二维码即可报名申请成为各城市核心者、志愿者