注意：由于安卓模拟器方案和Robox容器方案均是基于Ubuntu 18.04进行适配的，与鲲鹏硬件OS不兼容，因此对应的文档已做下架处理。鲲鹏BoostKit ARM原生使能套件的移植、部署、调优端到端使用流程和一站式资源获取。鲲鹏BoostKit ARM原生使能套件文档获取地址：cid:link_0

1月4日，2019年MongoDB中文社区年终盛会在深圳时代大厦举行，大会邀请了众多知名云服务商和业内技术大咖，共同畅谈云时代下MongoDB如何寻求突破，如何给企业带来巨大红利。华为云NoSQL数据库负责人胡达与会并发表了《云原生时代的MongoDB》的主题演讲，表示云原生数据库在性价比、数据可靠性、弹性伸缩等方面十分具有优势，对企业发展具有重大意义。华为云NoSQL数据库负责人胡达现场分享云原生时代下的MongoDB随着数字化和智能化进程的加快，数据上云成为了各大企业的首选，而MongoDB也在数字化进程中不断加速云化过程，云服务也愈来愈多样，胡达对目前云上MongoDB的典型部署架构作了简要分析。目前国内云厂商的MongoDB兼容云服务基本是以社区开源版本的托管为主，通过用云硬盘替代本地硬盘，发挥了一部分云计算优势，实现存储容量快速扩展；提供一站式的部署、管理、运维能力，在数据可靠性、安全性、备份恢复等方面有一定的易用性改进，减轻了DBA的工作负担。但是，相比国外友商的基于云原生架构同类云服务产品，在弹性、高可用、可靠性、性能稳定等方面仍存在差距。会上胡达分享了云原生时代的MongoDB，认为未来的方向是计算存储分离架构下的Serverless模式，给用户提供更简单易用的使用体验。华为云GeminiDB的更多可能性基于云时代下客户数据上云，企业的数字化转型，客户对MongoDB的使用，大数据量的压力这些痛点，胡达在会上重点介绍了华为云数据库GeminiDB，这是一款基于华为自主研发的计算存储分离架构的分布式多模NoSQL数据库服务，100%兼容MongoDB接口，并提供高性能、高可靠的优势。与市面上各类MongoDB云服务相比，GeminiDB for MongoDB API构筑了以下优势：一是分钟级计算节点扩容和秒级存储扩容，扩容性能提升百倍，满足敏捷业务弹性需要。二是高性价比，同等成本下提升了3倍写性能。三是数据高可靠，基于分布式存储的数据副本故障快速恢复能力，副本重建时长缩短10倍+。此外，GeminiDB for MongoDB API支持单套实例最大100TB数据，N-1个节点故障容忍，具备一键部署、监控报警等服务能力。胡达表示，华为云数据库会充分利用华为软硬件优势持续构建业内领先的技术和服务，打造真正的云原生MongoDB API兼容的云服务。未来，云原生数据库，我们可以做得更好。欲了解更多云数据库详情，请前往华为云官网：https://www.huaweicloud.com/product/geminidb.html

《云原生边缘计算架构分析》获中国边缘计算学术研讨会“优秀论文奖” 近日，由中国通信学会主办，中国通信学会边缘计算委员会（筹）及中国移动通信有限公司研究院承办的“2019全国边缘计算学术研讨会”在北京成功举办。工信部、通信学会、中国移动研究院的有关领导出席大会并致辞。本次学术研讨会吸引了来自政产学研各界的专家学者及企业领导等二百余人参与，以”边缘计算领域新技术的应用与发展趋势“为主题进行了深入的探讨与交流。华为云智能边缘云团队的论文《云原生边缘计算架构分析》在本次大会的众多参选作品中胜出，获颁“优秀论文奖”。          文中在分析业界与学术界多个边缘计算项目的架构后，阐述了一种基于Kubernetes架构的云原生边缘计算系统KubeEdge。KubeEdge由华为云智能边缘云团队提出，作为商业边缘服务智能边缘平台IEF的开源版本于2018年11月宣布开源，现已是CNCF官方项目之一，其本质是将Kubernetes的云原生微服务管理能力延伸到边缘，将云原生的生态和开发体验延伸到边缘，针对上层开发者提供统一的开发、部署、管理视图，并增强了离线运行能力、边云协同能力和边边协同能力。最后，给出了在智慧园区、工业互联网、 互动直播、自动驾驶等场景下KubeEdge的实际应用案例，以及未来在边缘应用安全、数据隐私和可信以及边缘AI方向的研究工作。 KubeEdge基于Kubernetes的架构体系并针对边缘场景提供了诸如离线运行能力、边云协同能力等多种特殊能力的支持，将云原生的生态和开发体验延伸到边缘，面向开发者提供统一的开发、部署、管理视图，屏蔽边缘和云端的差异。其整体架构如下图所示。         文中还特别的提到了使用EdgeMesh来支持跨越边界的微服务访问，随着微服务框架的流行和边缘节点计算和网络能力的增强，把部分服务部署到边缘处理设备产生的数据可以解决时延的问题，但由于安全等原因，大多数服务仍然运行在云上，云跟边、边跟边之间的协同是必须要解决的问题。EdgeMesh边缘微服务框架如下图所示，其主要解决了两个问题：l  由跨越了边、云而组成的大型分布式系统中的微服务之间互相发现和访问l  在微服务互相访问的过程中对访问过程进行治理、控制从而提升大型分布式系统整体的可用性                         华为智能边缘云生态经理欧争光表示，KubeEdge致力于打造一个开放共赢的边缘计算生态，助力于边缘计算行业的上下游发展，降低用户的二次开发成本，快速孵化端边云协同应用的创新。KubeEdge已经吸引了学术界和产业界广泛参与和部署，如中科大、北京邮件大学、东北大学、中国移动、烽火等著名高校和企业，也期待您的加入。点赞地址：https://github.com/kubeedge/kubeedge

备注：安卓模拟器方案和Robox容器方案均是基于Ubuntu 18.04进行适配的，与鲲鹏硬件OS不兼容，因此下架对应的文档。方案指导链接技术白皮书鲲鹏BoostKit ARM原生使能套件 技术白皮书https://www.hikunpeng.com/document/detail/zh/kunpengcps/twp/kunpengcps_19_0001.html云手机Turbo套件Kbox云手机容器文档https://www.hikunpeng.com/document/detail/zh/kunpengcps/cpturbokit/kboxcpc/kunpengcps_kbox_0001.html视频流引擎文档https://www.hikunpeng.com/document/detail/zh/kunpengcps/cpturbokit/videostreamengine/kunpengcps_video_0001.html指令流引擎文档https://www.hikunpeng.com/document/detail/zh/kunpengcps/cpturbokit/instrucstreamengine/kunpengcps_instruction_0001.html安卓模拟器方案安卓模拟器 安全说明书已下架安卓模拟器 编译指南 已下架安卓模拟器 安装指南（Ubuntu18.04）已下架安卓模拟器 安装指南（CentOS 7.6）已下架Robox容器方案Robox安卓容器 安全说明书已下架Robox安卓容器 编译指南已下架安卓镜像 编译指南（基于x86环境）已下架调优指南鲲鹏BoostKit ARM原生使能套件 调优指南已下架FAQ鲲鹏BoostKit ARM原生使能套件 FAQhttps://www.hikunpeng.com/document/detail/zh/kunpengcps/faqs/faq/kunpengcps_10_0001.html

      我loaction in 深圳，就是一个普通的资源开发整合，从云计算了解到之前的openstack是云计算的2.0，容器是云计算的3.0，现在从原生的角度来看一个事情，越容易实现公司项目的需求，这个就是我要的王道，就是如何让1+1>2是一个资源开发整合者的基本追求。       现在身在一个大企业中，技术运维等各种能力不是那么强悍的时候，这个时候就特别需要华为云的原生的生态去运维我司的业务，出现故障问题能够第一时间找到华为云的售后去解决问题，这个就是我希望要的效果吧。      容器来说比较轻量级别，对于一些应用或者说应用的迁移切换具备很多openstack挺多的优势，比如容器可以很快就起来一个的了，容器我经常理解为一个业务层的平台，非常快，期待容器的的操作更加傻瓜一些会更好。    云原生必然跟开业很多框架是生态化的，这样的话必然会有很多免费开源可以使用的东西，这样对我们来说确实是一个特别好的事情，我们也期待华为云的容器的CCE等原生态有更好的升级和更好的有机组合。   不单单是容器，现在时势都在谈论原生技术生态，作为一个技术的爱好者必须跟上学习的，不然可能就会错过风口，然后根据自己的业务项目情况判断一下是否要上到业务去，或者自己也会做一些灰度测试，或者灰度切换一部分业务上去跑一下。    在新的风口上，我起码努力去接触过，我努力过，人生能够遇上技术浪潮，跟上技术浪潮，我此生便无悔！     

我在华为云社区已经发布的博客《云原生（Cloud Native）产品之路》中阐述了一个观点：“Cloud Native产品之路的起点必须是产品团队对业务的深度理解，并且覆盖到团队每一个人。第二，将Cloud Native文化融入到业务与产品团队中。第三，团队的组织形式包括考核方式与这种文化匹配，简单的说，这个产品团队不应该有明确的职能划分。最后，选择合适的架构与平台，这个选择中做权衡时的原则是前三点。”在这篇博文中，我想详细打开第一点来讲讲。为什么说先要认识清楚自己的业务，然后再考虑云原生的问题？举个例子，你了解了云原生，告知你的团队需要打造一个云原生的产品，然后当进入到云原生细节之后发现，这里面太多的概念。说实话，一开始我就是完全处在混沌之中，技术词汇之多令人晕头转向。这时候很有可能你会放弃这条路，或者半推半就的摸索，事实上很多团队都是这么做的。其核心问题就是没有认识到这一规律：康威定律指出的组织形态决定了产品架构的形态。进一步说产品愿景决定了产品战略，产品战略决定了产品组织，产品组织决定了产品架构与开发模式。云原生的本质是一种产品组织方式，是否采用这种模式是产品战略自然而然选择的结果。举例来说，如果你的产品是一个小区智能监控系统，用户就是小区物业，需求几十年都不会变，这样的产品就不会选择云原生模式。再展开来说，如果你的产品是基于小区的智能监控，提供个性化的小区综合服务，比如访客管控、宠物跟踪等服务，主要用户变成了小区业主，产品要解决的问题是不同业主的生活服务需求，每天可能都有业主提出自己的想法，这时候如果你依靠产品体验而非资源垄断活下来了，可以断定你的产品一定会是云原生的，而且你的团队基本上聚焦在产品的体验与功能上，其他的中间件及底层都交给了服务提供商。产品愿景与战略是云原生产品的源点。因此，总结如何做优秀的云原生产品的第一条军规：明确产品愿景与战略，不人云亦云。那么云原生适配的产品愿景与战略是什么呢？我认为离不开这一点：为用户提供快速及可靠的服务。天下武功，唯快不破。云原生的最核心优点就是使用云端的资源将自己聚焦在业务之上，让自己的产品能够永远快人一步。只有这样，才能立于不败之地。如果你的产品战略有“快”这个核心要素，那么一定要选择云原生的产品组织形态。云原生为什么能快呢？简单来说就是人、流程与技术都是“快”的组织模式。云原生所提倡的“人”接近“通才”而非“专才”，这并不是说就不需要专业深度了，而是说具备专业深度的人还必须具备广度，要能做到专一且“什么都能做点”。我们所熟悉的全功能团队、全栈工程师都是如此，只不过这样的人确实不好找，所以需要营造一种文化，让团队每个人都开始打开思维。云原生的流程被人所熟知：DevOps。也即敏捷工程文化。其核心的思路就是不要什么都做完美了再拿出手，而是边做边给用户体验反馈，基于此将产品Idea到Product Feature的过程尽可能快起来，需求要快、设计要快、开发要快、测试要快、发布要快、交付上线要快......云原生的技术是最为被人知晓的，当然很多人也迷失其中，太多太多的技术栈了。简单一条，选择最主流的技术栈及最有实力的技术服务提供商。要想做到技术上快起来，一定不要小家子气，甚至有些还尝试自己去搭建云原生的基础环境，这绝对是错误的。总结如何做优秀的云原生产品的第二条军规：开放的拿来主义，只做自己擅长的，其他都交给别人。再强调，即使你再强大，如果你不是想做云原生的技术服务提供商，那你绝对不要关起门来思考与选择，找一个好平台，比如华为云的Service Stage，专心做自己的业务。第三条军规：把前两条军规告知每个人。结合我做的金融云产品，谈谈三条军规实践，以及为什么选择华为云。金融云产品的发展得以于蚂蚁金服和微信支付，将慢的金融行业变成了快的互联网行业。其中的本质我认为是：普惠化。普惠化实际上就是降低使用门槛，这需要技术和模式上的创新突破来实现，比如小额的信贷产品，银行为什么做不了？效率和成本的考量，简单地说就是不划算。蚂蚁金服通过大数据下的智能风控，实现了小额信贷的普惠化，一下子小生意的效率和成本问题没有了。这是中国的情况，世界更需要普惠化的金融技术，比如非洲和东南亚区域。这是中国金融云产品的更大机会。这就谈到第一条军规了，产品愿景和战略。我们定位于向世界输出普惠的金融技术平台，因此必须是云原生的，来处理不同的业务需求。第二条军规就需要选择适合自己的好平台，华为云被选择，因为全球通达的属地化服务能力、宏观资源的获取能力以及全栈技术的积累。开放的拿来主义，我们剥离掉了一切非业务核心的任务到华为云Service Stage，专心于业务本身。当然，师从蚂蚁金服也是必须的，Sofastack是一个很好的开源框架，值得每个金融云产品玩家实行拿来主义，至少是学习。其次，开放还要生态优先，也必须不重复造轮子。最后要基于三条军规做优秀的云原生产品，还要保持创新，更简单的说要正确的做正确的事。必须破除沉没成本，非云原生的那些积累通通要丢掉，别被老资产的复用思维所累。

    我来自一个手机厂商，了解到云原生的时候，是因为自己有用到这个技术的需求，当时自己在做一个私人的项目，需要同时兼顾前后端、数据库等这些组件，因为是自己的项目，所以没有很大的资金支持每种技术都配一**立的服务器，所以就查到了云原生这个系统里面的容器能解决我的问题。    首先来科普一下云原生是怎么一个东西，有什么特征，由什么组成。云原生是在2015年由科技巨头google这家公司牵头，一百多家企业和机构一起合作成立的一个项目，云原生包括3大特征，一是容器化封装，容器化封装就是将每一个小的功能封装起来，使得他不受当台电脑上其他的业务影响，也是我受用到的技术，二是动态管理，就是通过集中式的编排来对各项技术进行动态调配和管理，三是面向微服务，就是将原本一个很复杂的系统拆分成很多个小的板块来进行合作编排。    接下来讲一讲我和云原生中的容器三生三世的事情，这些事情可能没有电视中那么有趣，但看完后同样值得人去深思......    当时在做一个项目，需要同时搭建起来app和网站这两个东西，而且是online的，那么必定要有前后端代码支持放在服务器上，因为还要存储一些用户数据和后台数据，那么mysql数据库自然也需要一定的线上存储空间，因为是自己的一个项目，每项功能用不到考虑稳定性、延时性，而且要考虑成本，所以我刚开始就找了好几台1核1cpu的华为云机器去做这个技术，这就是云原生的第一世---错过篇。    租好这几台服务器后，第一步要做的就是搭环境，这几台服务器之间有一些公用的环境，我刚开始的时候就挨个在每台服务器上去搭建，这样不仅耗时而且无聊，然后我就了解到了云原生这个技术，第一仅要1台服务器就可以搞定，给我省了不少维护时间，第二很多环境只用搭建一遍，又省了一些时间，并且保证了稳定性(少动就会稳定)，这样我就将整个技术架构用到了云原生的容器分割里面，稳定又高效，这就是我和云原生的第二世---相约篇。    利用云原生技术，我最终的项目成果在公共展示的时候，获得了很好的一个成绩，这就是我和云原生的第三式---付出与回报篇。    云原生因为他的优势，现在已经有好多个开源技术框架产生，比如lstio、Prometheus、Helm、Spinnaker、KubeLess。

云原生的概念自2013年一经提出，就备受关注和推崇在IT圈儿混的，对云原生技术想必都不陌生特别是对容器、服务网格、微服务、Serverless 等云原生代表技术，或多或少都有一定了解很多企业甚至已利用云原生技术成功实现了业务上云的转型 那么问题来了从邂逅云原生到相识相知携手踏上新征程，你/公司是怎么做到的，都经历了些啥？520秀完恩爱，是时候秀秀你与云原生的那些事儿了！华为云容器团队现面向广大程序猿征集你与云原生的故事、技术心得、上云实践/案例等参与即有机会获得华为手环、云原生专业书籍、京东E卡等多重好礼哦分享创造更大价值，你还在等什么，赶紧参与吧~ 活动具体内容&规则如下：1. 征文时间：2019年5月27日-7月31日2. 参与对象：华为云容器服务用户、云原生技术爱好者3. 参与方式：点击进入“云原生研究所”- 选择“云原生生态”分类，即可发布参赛文章帖啦，记得将帖子标题及链接回复在本帖下哦（用于参赛统计和奖品发放，一定要回复到本帖下，否则可能无法参与评选）4. 内容要求：分享你/公司与云原生的故事、技术心得、上云实践/案例……只要与云原生相关内容皆可，500字以上，不限题材，自由发挥。比如，可以谈谈你对云原生技术的理解，聊聊你个人or公司在使用华为云容器服务过程中的心得体会。当然，如果能分享一些容器给公司业务带来的变化就更好啦~>举个栗子：-标题：我与容器的不解之缘-正文：坐标深圳，XX公司程序猿一枚，一直有关注容器技术……公司去年开始使用华为云容器服务CCE，逐步将应用进行容器化改造……大幅度降低了成本，提高了运维效率，还让我得到了晋升的机会……5. 评选规则：>评选标准：1）可学习参考性  2）内容真实性  3）内容完整性>评选方式：活动结束后，华为云容器服务专家评审团将对参赛文章进行评审，并于1周内公布结果。6. 活动奖励：一等奖：1名   华为手环+云原生专业书籍二等奖：3名   云原生专业书籍 三等奖：6名   50元京东E卡7. 注意事项：1）按参与方式参与，其他方式无效；2）请勿大篇幅抄袭其他用户的文章，一经发现，取消参赛、获奖资格；3）禁止恶意刷数据等作弊行为，如有发现，取消参赛、获奖资格；4）遵守华为云社区常规活动规则https://bbs.huaweicloud.com/forum/thread-5766-1-1.html5）本活动最终解释权归华为云容器团队所有。激扬文字，创造更大价值，点击参与吧~

【华为云专家，期待您的加入】如果您也热爱技术、乐于分享；想要参与技术沙龙、拓展人脉、打造个人技术品牌....华为云专家欢迎您的加入！华为云MVP：点击了解华为云·云享专家：点击了解更多问题欢迎咨询华为云专家小助手↓↓↓

【有奖问卷】填写云原生技术的问卷，倾听你的声音，我们共同成长！华为云应用服务的云原生技术产品是基于华为多年累积的复杂企业IT经验和应用云化改造经验，华为云应用服务产品族提供系列化的云原生服务栈，围绕传统企业应用上云、云上应用全生命周期管理(开发、测试、部署、管理)，提供应用云化框架、中间件云服务、自动化部署、自动化测试、应用托管与运维服务想知道云原生技术的产品与你的业务是否气质相符？想让我们的产品更能满足你的业务需求？你对我们的产品有很好的优化建议？我们针对不同的产品域分别准备四份问卷！还等什么呢，快动动你的手指，让我们知道你的感受和想法~（小声叨叨，每份问卷只需要占用你宝贵的3分钟哟）注意啦！！！参与问卷的同学有机会获取华为云100元代金券哦快来点击下方链接或者扫描下方二维码填写问卷留下你的意见和感受！Ready Go 开始有奖答题吧！！！问卷一：您对于K8S容器集群服务的意见收集：https://huaweiucd.wjx.cn/jq/35234782.aspx 亦可扫描下方二维码答卷问卷二：您对于微服务产品的意见收集：https://huaweiucd.wjx.cn/jq/35234732.aspx 亦可扫描下方二维码答卷问卷三：您对于应用运维服务的意见收集：https://huaweiucd.wjx.cn/jq/35234765.aspx 亦可扫描下方二维码答卷问卷四：您对于分布式缓存服务的意见收集：https://huaweiucd.wjx.cn/jq/35234714.aspx 亦可扫描下方二维码答卷活动规则：1、问卷调查时间：2019.3.15~2019.4.302、活动对象：华为云应用服务用户3、活动流程：填写完成问卷——问卷内要求用户填写各自的华为云官网账号4、抽奖资格：完成调查问卷的用户即可参与抽奖5、奖品设置：华为云100元代金券*20份【总共问卷数大于200份开奖】6、奖品发放说明：活动结束后3个工作日内开奖，中奖名单会在此帖公布。中奖的用户，代金券将会再中奖名单公布后7个工作日内直接发放到您的华为云账号内。7、所有参加本问卷调查的用户，均视为认可并同意《华为云用户协议》，本活动最终解释权归华为云所有。

0  我是谁？杜军，《Docker——容器与容器云》和《云原生分布式存储基石：etcd》这两本书的作者。现任职于华为Cloud BU PaaS服务产品部，主要负责容器与Kubernetes集群管理技术的研发。是Kubernetes核心维护者，也是CNCF TOC Contributor。在Kubernetes社区主导了Kube-proxy IPVS模式，Pod网络QoS，流图调度器Poseidon，Cluster-API-OpenStack和边缘计算KubeEdge等项目的开发。你可以在KubeCon，LinuxCon和CNUTCon等大会找到我分享的主题演讲，我也做过多次Kubernetes和CKA考试的培训。1      如何理解“云原生”这三个字？  云计算时代，企业将不再耗巨资投资自己的IT系统，而是直接使用无限制的按需付费的云服务，这无疑将显著降低IT基础设施的开销，加速软件占据世界的进程。作为程序员，我时常为自己有机会投身于这个波澜壮阔的技术变革事业而感到莫名激动。  回到正题，我理解的云原生是一种新的软件工程方法，即充分利用云计算的优势来构建（build）和运行（run）软件。“Build once, run everywhere”，当初Docker公司提出的这个口号现在喊起来是否已经朗朗上口了？  有时候我们会反思，当容器技术方兴未艾的时候，是什么促使了云原生技术如雨后春笋般在企业内萌发呢？诚然，“一次构建，到处运行”——容器良好的良好的可移植性，敏捷性和Docker革新的镜像打包方式相较云计算最初的IaaS虚拟机形态，更加容易地成为公有云全新的基础设施和交付手段。但Docker毕竟只是一个runtime，当我们需要一个编排框架作为系统核心来串联开发、测试、发布、运行和升级等整个软件生命周期时，它就略显单薄。  搞大规模的基础设施，还得看Google，毕竟人家管理大规模的容器集群已经快二十年了，哪怕是在公有云领域攻城略地、出尽风头的AWS，都没有Google在容器领域积累的深厚经验。Kubernetes就是Google照着鼎鼎大名的Borg系统开源出来的容器编排引擎。如今的Kubernetes，既是 GitHub上的明星项目，也获得了了全世界所有公有云厂商（包括AWS）的青睐，更是让当年不可一世的Docker公司低下了他那高傲的头颅。  关心容器生态圈的朋友，想必都已经接受了Kubernetes作为容器编排甚至是云原生标准的事实。2      什么样的技术才能配得上“基石”二字？  etcd的作者，李响曾“傲娇”地说，“etcd就是用来存储云上最重要的数据的”。  从技术上的角度，用户大可以放心这么做，因为etcd底层采用的Raft一致性协议保证了数据的分布式强一致性和高可用。一个etcd数据集群，即使挂掉半数节点，也不影响集群的正常工作。  李响的底气更来自于，etcd同时被经典PaaS的代表Cloud Foundry和容器云新贵Kubernetes采用，作为他们后端数据存储和协同的关键组件。毫不夸张地说，etcd就是Kubernetes和Cloud Foundry的“心脏”。更饶有趣味的是，Docker Swarm的节点管理系统也引用了etcd的Raft库，要知道Docker和CoreOS（开发etcd的公司）曾经在容器runtime战场上有过一番争夺啊！我只能感叹，etcd的代码质量之高以至于让商业竞争对手都放下了门户之见。又或许，Docker Swarm那时也找不到更稳定的Go语言版本的Raft实现了。更不用说，TiDB这类新兴的分布式NewSQL数据库基于etcd的Raft库构建分布式事务、跨数据中心数据强一致性、故障自恢复等能力。  经典PaaS我们不必再提，考虑到Kubernetes在当今云原生时代所扮演的角色，用“基石”二字形如etcd的重要性一点都不为过。事实上，etcd也不负众望，很好地扮演了“坚若磐石，稳如泰山”的云原生大厦基石的角色。etcd作为硅谷明星创业公司CoreOS最重要的项目，一开始便含着“金钥匙”出生，直接被Kubernetes指定作为其后端的存储实现。  “Kubernetes是Borg的开源实现，在Google内部，Borg使用Chubby作为分布式协同的后端，Kubernetes选择了etcd——一个Go语言的Chubby实现。”  Kubernetes的创始人如是解释道Kubernetes和etcd的结缘。相较于基于Paxos协议，并且给Google的工程师们带来无尽软件工程梦魇的Chubby，etcd底层的Raft协议容易实现太多，再加上由Go这门被Google寄托了太多云时代愿望的编程语言编写，自然能够无缝融入到Kubernetes的生态之中。  如果说当初etcd搭上Kubernetes的快车还有些“幸运”的成分，但是etcd伴随着Kubernetes共同成长，历经了从V2到V3的重大版本更新，经受住了Kubernetes大规模部署最严苛的可用性和性能考验，就是它实力的体现了。Kubernetes项目早期还预留了对接多种后端存储的接口设计，现如今再去讨论这个话题已经失去了意义，因为etcd作为Kubernetes后端唯一存储早已深入人心。诞生于云原生星火燎原之时，上天再把你派到Kubernetes这个老大哥身边，把你打造成开源的Chubby，云原生的分布式存储基石，这是一份多么让人艳羡的履历啊！什么叫天之骄子？我想这便是！3     成书缘由  笔者求学于国内云计算研究最前沿的浙大SEL实验室，从研究生开始便投身于云原生技术的探索与实践。从最开始研究KVM虚拟机，再到后来的底层基础设施CloudStack，OpenStack，也参与过经典PaaS Cloud Foundry在企业私有云的落地。  在2014年Docker和Kubernetes技术刚诞生之时，我们实验室的几位老师和博士（其中便包括后来的Kubernetes核心维护者张磊）便敏锐地意识到这将是改变未来十年基础设施的新技术，出于技术布道的目的，我们合著了并出版了国内第一本深度解析Docker和Kubernetes的书《Docker——容器与容器云》。由于我负责该书Kubernetes部分，因此在写作过程中便对etcd有过较深入的研究，但考虑到彼时etcd还是0.4版本，功能比较简单，而且和该书的主题关联不强，所以就没有花篇幅介绍etcd。但彼时便被etcd简明的架构设计和优美的Raft算法实现深深折服，从此心中埋下了一颗独立出版一本介绍etcd书籍的种子。  毕业后由于工作关系一直深耕Kubernetes，并基于Kubernetes构建华为公有云的PaaS平台。自然，etcd是整个华为PaaS平台的重中之重，我所在的技术团队也经历了从Kubernetes 1K节点到10K节点百万容器规模的艰辛蜕变，积累了不少etcd在大规模场景下的运维和性能调优经验。我想，任何基于Kubernetes构建的云平台都会碰到我们之前解决过的各种etcd相关的问题，比如：数据容灾恢复，watch缓冲区溢出，高并发带来的读写性能衰退，磁盘I/O低下导致的集群频繁选主等问题。很多情况下，这些问题并非etcd的问题，是因为我们对etcd的核心机制不理解或理解不充分导致的。     etcd的官网只有粗浅的API使用等资料，缺乏对etcd架构和原理的深度剖析——可能这个世界上最懂etcd的人太忙没时间写文档吧。市面上介绍Kubernetes的书籍多如牛毛，却“不约而同”地忽略了最关键的etcd的相关内容。按李响的原话讲，“etcd是一个需要动脑子的项目”。尽管Raft算法和Paxos相比容易理解了很多，但对初学者来说里面仍然有不少奥秘需要点破。恰逢etcd准备捐献CNCF，急需中立的项目维护者，我希望更多人了解到这个优秀的项目，壮大开源社区。  因此，本着技术分享，回馈社区的心态，我们华为云容器服务团队合著了这本《云原生分布式存储基石：etcd深入解析》，希望在探索云原生落地的道路上，有更多志同道合的朋友加入，有你从此便不再孤单。  可能有人会问，市面上不是已经有一本etcd源码解析的书了吗？但我们需要注意到，etcd项目迭代更新快，今天拉的代码过上几个月有可能就变得面目全非，纯粹的源码解析的书籍很难做到与时俱进。此外，很多etcd的运维人员可能并不关心etcd的源代码，他们更关心如何使用etcd。在我的上一本书写作过程中，我就意识到了这个问题，因此《云原生分布式存储基石：etcd深入解析》是第一本涵盖分布式基本理论，分布式一致性协议Raft，etcd使用，运维，API，源码解析等内容的书，更是第一本综合分析了etcd V2和V3差异的书。希望各个层次的读者都能够从中获益。4      谁应该看这本书？如果你正在学习或者使用Kubernetes，我建议你看下这本书，因为Kubernetes后期的坑都在etcd，这本书可以让你提前知晓并且避开那些坑。如果你是分布式系统的爱好者，你可以从这本书了解到分布式系统的基本理论，包括：CAP理论，复制状态机，拜占庭将军问题，FLP不可能性等。如果你想自学Raft协议，这本书详解了Raft一致性算法，包括：Raft选举过程，日志同步，快照，异常恢复等机制。如果你是etcd的初学者，这本书手把手教你如何部署一个etcd集群，并用相当多的篇幅解释了etcd的基本概念、常用命令和配置方法等，更有常见问题的Q&A和实践分享。如果你是Kubernets/etcd的运维人员，etcd集群的稳定性关乎线上/线下环境的平稳，我建议你的案头放一本这书，每天闲时翻一翻，集群升级，备份恢复，日志监控，性能调优，认证授权等知识点一网打尽，彻底告别临时抱佛脚。如果你是etcd的开发者，这一本不错的API参考书，里面详细罗列了etcd V2和V3的常用API调用和各个参数的含义。如果你是高阶的分布式系统开发者和架构师，这本书你没有理由错过，因为它从源码级别娓娓道来etcd的多版本并发控制（MVCC），etcd V2存储机制，etcd V3数据模型，etcd的日志和快照管理，etcd V3的事务和隔离，etcd watch机制等实现细节，你可以从中汲取分布强一致性存储系统的设计灵感。5     如何获得这本书？《云原生分布式存储基石：etcd深入解析》一书由机械工业出版社在2018年11月5日正式出版，华为云容器服务团队荣誉出品。 各大平台均有发售，新书发售期间折扣力度较大：京东（自营有电子版），淘宝，当当（自营有电子版）。欢迎大家积极勘误，找到的错误直接回帖即可，找错最多的五位同学将有机会获得作者本人给各位充值话费哦~还请各位专家不吝赐教并反馈宝贵意见帮助后续改进！

微服务的挑战微服务将一单体的复杂应用分解成若干小的服务，服务间使用轻量级的协议进行通信。这种方式带给我们很多好处：1）  从Dev上看，每个微服务的功能更内聚，可以在微服务内设计和扩展功能；并且微服务可以采用不同的开发语言，不同的开发工具；2）  从Ops上看，微服务化后，每个微服务在独立的进程里，可以自运维；更重要的是微服务化是单一变更的基础，迭代速度更快，上线风险更小。                                                                                                                 复杂单体应用改造成微服务示意图  但是，在享受微服务带给我们福利的同时，微服务也给开发和运维功能在带来了很大的挑战。因为微服务化也仅仅是一种分而治之，化繁为简的方法论，业务本身的规模和复杂度并没有变少，而且为了支持微服务中间还要多做些事情。你会发现你的系统变成了分布式的，网络可靠性、通讯安全、网络时延、网络拓扑变化等这些原来不用特别关心的也得关心起来。另外还有微微自身机制的问题，比如服务怎么找到对端服务需要服务发现和负载均衡等。原来的在一个进程里的调用栈，现在变成了跨进程的分布式调用栈，就是所谓的分布式调用链追踪。那么面对这些问题，就需要对应的工具集来搞定这些事情，就是治理的工具集，包括服务发行，负载均衡，熔断容错，调用链分析等等。 微服务从业者，一直试图告诉大家这些工具集是微服务提供的福利，我更愿意认为这是解决微服务化带来的问题的工具集。 Service Mesh 微服务治理逻辑最初由开发人员写在业务代码里，缺点很明显，功能重复，业务代码和治理逻辑耦合。                                                         阶段一：微服务治理逻辑耦合在业务逻辑中 那么很容易想到通过封装吧公共逻辑提炼出来，形成一个公共库，就是所谓的SDK，使用SDK开发，则所有治理能力就内置了。Spring Cloud和Netflix都是此类的工具，使用比较广泛。但语言相关，而且对于开发人员有一定的学习成本。虽然SDK都强调开箱即用，使用anotation或者其他配置的方式，或者starter方式便让开发人员入手，但使用起来并不容易。另外推动已经在用的旧的系统使用SDK重写下也不是个容易的事情。                                                         阶段二：提供SDK进行开发 于是考虑是否可以继续封装，将治理能力提到进程外面来，作为独立进程。即Sidecar方式，也就是当前比较受广泛关注的service mesh的方式。真正可以做到对业务代码和进程0侵入，这对于原来的系统完全不用改造，直接使用sidecar进行治理。                                                         阶段三：service mesh方式   如下图深色是proxy，浅色的是服务，所有流入流出服务的都通过proxy。服务网格正是由这一组轻量代理组成，和应用程序部署在一起，但是应用程序感知不到他的存在。尤其对于云原生应用，一般有都有着复杂的应用访问拓扑，服务网格保证请求可以在这些拓扑中可靠的传递。为了能对这这么多代理有个统一的管理，所有的代理都一般都接入了一个控制面，对代理进行生命期管理和统一的治理规则的配置。 Istio的问世Istio是一个Service Mesh开源项目，是Google继Kubernetes之后的又一力作，主要参与的公司包括Google，IBM等公司。它提供了完整的微服务治理的完整的解决方案。2017年5月发布第一个release 0.1.0，当前版本0.8是一个LTS版本于6.1发布，预计1.0版本会在七月份发布，最新的信息是7.20号1.0版本就会发布。 下图反映了Istio项目的一个发展现状。Star数基本上一直是线性增长。右图是前阵子哥本哈根kubecon上议题里istio相关的，可以看到还是非常有热度的。 Istio的架构以下Istio的总体架构图：由两部分组成，控制面和数据面。 Pilot负责部署在Istio服务网格中的Envoy实例的生命周期管理，主要干两个事情：服务发现和治理规则的配置和下发。Mixer是负责在服务网格上执行访问控制和策略，并从Envoy代理收集遥测数据。Citadel提供服务间认证和终端用户认证，使用交互TLS，内置身份和证书管理。 ISTIO架构上非常注重解耦这个点，一个好的系统，一个设计好的系统，都满足这个特点，k8s满足，istio也集成了这个基因。不只是提供一个功能。而是一个框架，提供足够的可扩展性。在国内我们好像更愿意管这个叫做二次开发。像模板的设计模式订好了模板留下实现的接口，就像java语言喜欢在框架上用接口和抽象类来定义行为，这本身就体现了设计，体现了约束，甚至体现了现在开发中角色地位。Pilot服务发现的解耦设计  首先看下istio的服务发现。本身还是微服务的框架，微服务的模型。定义了一个抽象的服务模型，包括服务、服务实例、版本等，Adapter对接不同的平台。 如在k8s中，Pilot中的Kubernetes适配器通过Kubernetes API服务器得到Kubernetes中Pod注册信息的更改，入口资源以及存储流量管理规则等信息，然后将该数据被翻译为标准模型提供给Pilot使用。同样对接Eureka，也是用一个httpclient去rest访问eureka的名字服务的集群，获取服务实例的列表。Istio的服务模型：服务、服务实例、pilot的model. ServiceInstance中的定义连字段都和版本 和 netflix的eureka和springcloud的 servcieinstance类元素基本一样。 Pilot数据面接口的解耦设计除了对接各种运行的平台外，istio和数据面的对接也非常灵活，设计了标准的接口，只要满足该接口的proxy都可以被istio管理。Envoy提供服务发现，负载均衡池和路由表的动态更新的API，这些API将Istio和Envoy的实现解耦。Envoy API负责和Envoy的通讯, 主要是发送服务发现信息和流量控制规则给Envoy。可以在运行期对微服务的流量进行调整和控制。提供标准的API接口，可以对接多种不同的数据面，当前支持Envoy，也可以对接其他的满足协议的Sidecar。 Mixer后端的解耦设计 Mixer通过使用通用插件模型实现的对接不同后端，避免了proxy对每种处理后端的对接。每个插件都被称为Adapter。对于每个请求Sidecar会从每一次请求中收集相关信息，如请求的路径，时间，源IP，目地服务，tracing头，日志等，并请这些属性上报给Mixer。Mixer和后端服务之间是通过适配器进行连接的，Mixer将Sidecar上报的内容通过适配器发送给后端服务。可以在不停止应用服务的情况下动态切换后台服务。除了可以通过adapter机制接入不同的后端，mixer还支持根据需要定义收集的metric，和对metric的处理方式，如下样例所示，可以自定义监控指标：apiVersion: "config.istio.io/v1alpha2"kind: metricmetadata:  name: requestduration  namespace: istio-systemspec:  value: response.duration | "0ms"  dimensions:    source_service: source.service | "unknown"    source_version: source.labels["version"] | "unknown"    destination_service: destination.service | "unknown"    destination_version: destination.labels["version"] | "unknown"    response_code: response.code | 200 Istio API开放ISTIO服务治理能力对于治理策略都是定义在服务提供者的对象上，但是执行大部分都是在服务消费者一端。典型的如负载均衡，又请求端选择调用后端哪个实例，其实ribbon等sdk的对应组件也都是同样逻辑，下表展示了ISTIO的服务治理能力以及执行方： V1alph3 API在0.8后Istio推出了最新的V1alph3的API。V1alpha3在0.7时候就有了，在0.8时做了些少的调整。当前版v1a1已经标记成废弃了，在未来会被弃用。它将完全取代之前的API。尽管v1alph3和之前的API模型基本相同，但它不向后兼容，需要从旧API手动转换。在Istio接下来的版本中会包含一个转换工具提供转换的功能。  1. Gateway，提供外部服务访问接入。不同于v1alph1使用ingress做服务接入，只能支持七层。使用Gateway后可以将内部任意一个端口上的服务发布出去进行外部访问。配合VS规则，使用标准的Istio规则来控制进入Gateway的HTTP和TCP流量。和内部流量统一套的治理外部力量。2. VirtualServiceVS是istio中最核心的接口。所有的路由访问规则都是通过VS来描述。比如比较典型的做灰度发布，可以描述满足什么条件的规则去哪个特征的路由上。在V1alpha1里是多个routerule搞优先级，VirtualService的引入使路由规则的配置更为集中和灵活。4. DestinationRule配置将流量转发到服务的策略集。断路器，负载均衡设置，TLS设置等5. ServiceEntry外部服务接入到服务注册表中。可以像注册表中的任何其他服务一样,与VirtualService和/或DestinationRule一起使用 Istio和kubernetes 谷歌围绕k8s打造了一个生态圈，我们以微服务的视角看下这里的功能：K8s提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但是往上的如熔断、限流降级、调用链治理能力就没有了. Istio很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像springcloud netflix等完全重新做一套。istio是谷歌微服务治理上的非常关键的一环。 Istio基于k8s之上构造能力，包括：Sicecar 运行在k8s pod里，作为一个proxy和业务容器部署在一起，部署过程对用户透明。Mesh中要求业务程序的运行感知不到sidecar的存在，基于k8sd的pod的设计这部分做的更彻底，对用户更透明，用户甚至感知不到部署sidecar的这个过程。试想如果是通过VM上部署一个agent，不会有这么方便。istioctl 命令行工具提供类似kubectl风格的功能，提供命令行的配置功能。Istio所有的配置都是通过CRD表达，通过对K8S原生API的扩展，用户可以方便的使用起来。Pilot中包含一个controller，listwatch kubeapiserver，做服务发现。pilot通过在kubernetes里面注册一个controller来监听事件，从而获取Service和Kubernetes的Endpoint以及Pod的关系，但是在转发层面，不再使用kube-proxy转发了，而是将这些映射关系转换成为pilot自己的转发模型，下发到envoy进行转发。 K8s编排容器服务已经成为一种事实上的标准；因为微服务与容器在轻量、快速部署运维等特征的匹配，微服务运行在容器中也正成为一种标准实践；随着istio的成熟和ServiceMesh技术的流行，使用Istio进行微服务治理的实践也越来越多；而istio和k8s的天然融合使得上面形成了一个完美的闭环。对于云原生应用，采用kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。 Istio和k8s在华为云Istio在华为云这是istio加入华为云k8s全栈容器服务大家庭的一个全局视图，可以看到华为云容器服务提供了从容器集群、容器运维、容器镜像、应用编排、serviceless container以及微服务治理的端到端完整容器全栈服务，让企业上云更简单，运行更高效。 在华为云容器应用中可以使用istio进行服务治理和服务发布管理功能，下面以灰度发布功能为例。用过CCE的用户会发现使用方式和原来使用基本没有差别，如果您的集群下应用需要进行微服务治理，只需要在集群创建时启动istio服务网格，简单的鼠标点击就可以实现开启服务治理的能力！最佳实践：通过简单2个步骤即可实现微服务的新版本灰度发布下面以灰度发布的例子来看如何通过ISTIO服务网格简单、快速的实现新版本发布诉求。下方图示为典型的灰度发布以及版本管控流程： 那么按照这个步骤，在华为云容器服务中如何实现呢？ 第一步：在已有应用组件中点击“添加灰度版本”，只需要简单配置新版本号即可（如下方配置，版本号为V1.1），系统将自动为您选择最新版本的镜像，并继承已有版本配置（支持按需更新），如下图示：  第二步：配置灰度流量策略，根据您的发布诉求，选择基于权重或者内容的策略：   基于权重的策略：基于请求内容的策略：配置完毕点击“提交策略”即可实现灰度发布，可以看到，在华为云容器服务上，如果要对您的应用微服务进行灰度发布，只需要简单的两步操作，总共输入3个配置项即可实现微服务的灰度发布。而后，通过华为云容器应用性能监控服务做进一步的运行态监控以及版本管理  按照权重和内容的业务数据流向分别如下图所示：    基于比例调度的业务流量示意图     基于内容调度的业务流量示意图 最后，用户可以根据诉求逐步提升灰度版本的流量比例，通过简单的点击将流量全部切换到灰度版本，便捷实现新版本的逐步、平滑、稳定的在现网发布上线： （1）简单点击即可实现灰度版本“接管所有流量”：（2）所有流量已切换至灰度版本（V1.1）  华为云容器服务Istio服务网格震撼公测目前ISTIO服务网格能力已开放公测，如欲获取更多信息，更便捷的解决企业微服务化过程中碰到挑战，可通过下方链接，快速申请公测，华为云容器服务的专家将全力为您服务，为您的成功保驾护航. 申请链接：https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/istio/meshList

每期直播预告+材料下载，请点击收藏总帖：https://bbs.huaweicloud.com/forum/thread-9573-1-1.html【Cloud Native Lives系列直播 】第1期：《云原生技术的前世今生 》，7月12日直播已经结束。错过直播的朋友也不用遗憾，奉上最全材料~1.网页回放地址：https://zhibo.huaweicloud.com/watch/22349432.扫码观看回放：3.PPT最全下载：Cloud Native Lives 课程一：云原生技术的前世今生 (1).pdf( 预览 )

本帖最后由 橘色祥云楼楼主 于 2018-4-20 15:33 编辑本文作者：乔雷 原华为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-native 2. 华为云如何使能云原生应用以下这张图，来自于我前一段时间答标某项目的RFP。这个RFP中客户招标几个核心的应用。除了对应用本身功能的要求，客户还要求是云原生应用，使用云基础设施，采用目前流行的DevOps，微服务，容器，大数据/AI等技术。因此我画了一张Huawei Cloud Enables Cloud-Native Applications的PPT，重点讲解华为云如何使能云原生应用。我引用在这里供大家参考和探讨。 14160概要解释如下： [*]服务开发者使用华为云的软件开发云(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画了一张更详细一点的，供参考。如下： 14161 附件原图更清晰：