--------活动已结束--------2020 华为12月29日（周二）早上9点到下午5点30分，进行全天线上直播，汇聚多位华为重量级专家看行业趋势、玩闯关游戏、赢贺岁礼包直播地址回顾中...专家介绍四重福利，助力云筑2020 年终盛典直播启幕！！！福利一：成功报名本次直播盛典，必得200码豆福利二：12月29日参与直播盛典互动，直播间内抽取平板电脑、手表、耳机等数十件奖励！福利三：参与直播现场连线，完成闯关答题，赢取六重“包您一年系列”大礼！福利四：邀友报名直播盛典，Ta得超级贺岁礼包，你也同样获得！- 如何邀请好友？1.点击本页面上方“立即报名”按钮 > 2.登录/注册华为云账号 > 3.填写信息完成活动报名 > 4.报名成功弹窗中点击分享有礼(或进入我的直播中点击分享有礼按钮) > 5.按照引导将活动分享至你的好友，并引导ta完成本活动报名参与专家坐堂互动在本帖下方任意回复以下一项内容，即有机会获得FreeBuds 悦享版 无线耳机和定制双肩包。有效参与楼层的5%、50%、95%必得三合一数据线。*奖品样式为示意，请以实物为准（任选其一）参与互动1）  观看直播后发表您的个人观点2）  观看直播后向专家提出问题3）  参与微话题互动：讨论话题：说一个你认为的云原生领域最有前景的方向/开源项目，解决了什么问题?注：发布的内容必须与本次直播话题或微话题相关，且必须包含个人思考的内容。水帖将做删除处理，抄袭内容一经发现将取消评选资格。回复时间截至2021年1月10日。活动规则1、如本帖的有效回复人数大于等于20人，则由专家和华为云工作人员共同评选出3个优质回复，发布者可获得定制双肩包一个。如有效回复人数大于等于30人，则额外评选出一个最优回复，发布者可获得华为freebuds 悦享版 无线耳机一个。如有效回复人数小于20人，则只发放三合一数据线。2、每位参与本帖活动的用户只能获得一次奖品，每人最多回复同一内容5次，如果有恶意灌水的行为将取消获奖资格3、如您参与云筑2020年终盛典，为保证您顺利领取活动奖品，请您提前填写下方奖品收货信息链接，如截止2021年1月17日您没有填写，视为放弃奖励  填写地址请戳我>>4、本次活动奖品将于2021年1月31日前统一发出，请您耐心等待；5、本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/），奖项评比将由专家和华为云工作人员共同完成。如您对评奖方式有异议，请勿参加本次活动。点击前往云筑2020 年终盛典更多活动

微服务引擎专享版，配置了3个AZ，但只提供了两个服务注册地址，目前业务侧已配置两个服务注册地址。当某个AZ故障时，是否会影响到业务侧？

edge未开启ssl&http2，后端微服务M开启了ssl&http2edge通过RPC方式调用后端微服务M时，微服务M报错：NotSslRecordException,message:not an SSL/TLS record

如图，已确认过好几次填写了正确的ak，sk以及其他信息了，但是就是保存不了，大佬们帮忙看看问题出在哪

使用edge调用后端的微服务，去掉了熔断等，request.timeout设置了30秒，但是调用微服务的时候edge直接590错误，但是对应的微服务方法也收到了，并执行，这个有遇到过么

IoT并不是一个新名词、新技术，很长一段时间，它甚至给人一种“下工地”的印象：由于IoT设备的落地场景经常与工程环境强相关，又不容易远程配置，所以难免“形象不佳”。近几年，当IoT与创新、科技、互联网等挂钩时，成为一个相当“新锐”的行业，尤其云计算时代的IoT，有了许多让老树开新花的功能，也让这个行业有了许多新的想象空间。比如，Serverless、微服务，这些新技术和IoT有什么关系？纵观IoT行业的发展，云服务又扮演了什么角色？华为云云享专家董昕以业内人的视角给出了他的理解。董昕是个喜欢折腾的人，既在Intel、中国银联、Trident这样的大公司待过，负责芯片、IoT、安全、云计算等多个领域的技术开发；同时，他也是一个连续创业者，肩挑背扛整个公司的技术架构，所以对中小企业在信息安全和云计算上的紧迫感有着深刻的认知。如今，董昕担任国内某大型第三方支付公司的高级架构师，一直处在技术一线的他，对当前IoT行业的发展有着理性的洞察，以下是他对IoT技术发展趋势的一些预判。 物联网比互联网更适合ServerlessServerless即开发人员无需再关注服务器的运维工作，直接将代码部署在云端，对外提供RESTful API 即可，云计算会自动根据请求编排资源。这种模式非常适合前端实现许多功能、后台记录状态的场景，可以说是大前端发展的必然趋势。在董昕看来，目前各大云服务商针对IoT设备提供的物模型，本质上就是一种Serverless，甚至更进一步，已经是Codeless了。沿着这个思路去考量互联网和物联网在Serverless上的差异，会发现 IoT 仅仅只是将联网的主体从人改成了物，而消息的请求与响应并无差别。甚至在大多数情况下，联网的物比联网的人，要更容易数据化，所需提供的服务也更单一，几个属性和服务就足以清晰的定义某类IoT设备。所以从这个角度看，物联网比互联网更适合Serverless这种模式，而物模型就是这种模式在IoT上的落地形式。Serverless 的发展趋势、优势与目标都可以匹配IoT，比如海量接入、快速扩缩容、可移植性等等。对于物模型，我们可以做与当下的Serverless几乎一致的畅想，把Serverless上的经验全盘复制到IoT的场景中，比如Serverless中最迫切的代码可移植性问题。站在云服务商的角度，用户建立了物模型，就是与云服务商进行了强绑定。可对于普通用户而言，物模型的可移植性，甚至是物模型的编排工作，都是要解决的难题。如同 Serverless已涌现出了数家跨云服务商的中间件提供方一样，伴随着IoT的发展，物模型的编排将很可能将会成为开发者值得去探索的方向。另外，在Serverless上暴露的物模型组件的继承与复用，传统代码与物模型之间的转译等问题，在IoT的将来都会是无边无际的蓝海，同时还有互联网软件的前辈们留下的宝贵经验，广阔天地，大有可为。硬件正在不断的软件化，这个观点早已不再新鲜，但仍未过时。软件中的许多设计思想，都值得在硬件设计中去复制与实践。 每个IoT设备都是一个独立的微服务 “微服务”是软件行业里很热门的一个词，即把一个大的功能模块拆解成数个小的，然后在整个系统中，小模块可以合并、复用。微服务各司其职，大系统化整为零。这样做的好处很多，但维护管理众多的微服务成了一个麻烦事，于是就有了Docker和 Google发布的微服务治理框架Kubernetes。延续前文提过的“硬件正在不断的软件化”思路，每个IoT设备，从功能目标上看，都可以看作一个独立的微服务，所以软件微服务治理的那套规范一样可以运用到IoT设备上。比如华为开源的KubeEdge项目——这个项目可以将容器化应用程序编排至边缘主机上，让每个边缘主机化身为微服务节点。准确的说，KubeEdge并不是部署在IoT设备上，而是针对边缘计算端的，毕竟目前绝大多数IoT设备的算力还不足以支持。边缘计算节点作为IoT网关，联合各种终端IoT设备，已经完全足够成为一个微服务节点，也让算力能够提供更契合场景的定制化输出，而非单纯的依靠软件提供标准化产品。类似的，在边缘节点成为硬件的微服务节点之后，软件微服务治理的设计思想也可以移植到了边缘计算当中，包括但不限于：CI/CD、DevOps、ServiceMesh、服务监控与追踪，甚至AIOps等等。我们时常说的“端边管云”也只有在这样的基础上，才能真正实现无缝连接、自由组合、实时配置等。至彼时，IoT的工作模式就仿佛人类社会分工的某种终极形态：各个终端设备都具有能独自解决某类问题的能力，又可以随时与周边的其他设备组建团队解决棘手的问题，还能够从云端实时得到更多重量级的支援——这哪里还是以前“不受待见”的IoT开发啊，完全是一支海军陆战队嘛！我来，我见，我征服。 鸿蒙之我见：江湖路远，吾道不孤鸿蒙虽时常被拿来与安卓对比，但它实际上是为IoT设备设计的，尤其是其模块化耦合的特性，完全是为IoT设备量身定做的。相对于电脑和手机，IoT设备缺乏统一的标准协议，每种设备都可能只具备某种特性实现为此，鸿蒙提供了对不属性的设备做定制化裁剪的功能，而对于硬件资源的多寡，鸿蒙又设计了多层架构，各种设备可以根据自身资源的情况选择不同的层数。简而言之，鸿蒙试图以一站式服务的方式，为各式各样的IoT设备提供从底层到应用层软件的全方位支持，让硬件制造商摆脱了软硬件双线作战的困扰，同时也为所有的 IoT 设备统一了标准与接口。实际上，意图统一IoT接口标准这一野望，安卓和苹果都曾以Android@Home和HomeKit的方式奢望过。但应者寥寥，归根结底，具备了软件开发能力的硬件制造商，即便是面对 Google和苹果这样能为其提供海量流量的巨头，也不愿惟其马首是瞻，从而最终彻底丧失独立性。而在软件上乏善可陈的制造商又难入巨头的视野，也难堪海量流量的冲击。于是，这种只定义接口让厂商自行实现的方式最终沦为一场双输的博弈，看似风光无限，实则互相提防。不只是系统设计，鸿蒙在功能特性上也为IoT设备提供了丰富的想象空间，比如分布式软总线。以往我们在讨论总线，都是在一个固定且封闭的硬件组合当中，比如电脑的南北桥总线， SoC芯片内部的AMBA总线——都是在一个封闭的硬件环境中，各功能模块固定不变的情况下，以硬件的方式实现的总线。而在鸿蒙的场景下，多个IoT之间是通过网络连接，各组件也随时都可能下线或属性变更。打个简单粗暴的比方，分布式软总线是要在把电脑拆散了，各个模块通过有线/无线的方式进行通信，且都支持热插拔的情况下，用软件协议的方式将各个模块串接起来，同时还需确保数据安全与读写效率。事实上，不止是华为，Google正在研发的新一代操作系统Fuchsia，本着一样的目标，也在积极推进中。星辰大海，百舸争流。  结语曾经，单独一个IoT设备既不起眼，还需要不少的人力维护，甚至必须到现场蹲点，实在是一个费力不讨好的行当。现在，云计算的浪潮正改变这个行业，星星之火，必将燎原。当老树发新芽，在新技术的加权下，如何把握IoT大势中新一轮浪潮，让我们拭目以待。

 摘要：架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。善用兵者，役不再籍，粮不三载。取用于国，因粮于敌，故军食可足也。——《孙子兵法》在古代，带兵作战的将领，不仅要能善于用兵，而且要能保障粮食的充足。正所谓兵马未动，粮草先行。粮草永远摆在第一位，因为在冷**时代，战争中的将士都是在拼力气，吃饱才有力气打仗。在今天互联网的“战争”环境中，我们为了能更快的应对市场变化，一直以来不断调整着作战的方针和打法，也从传统的开发方式转变为了敏捷开发，由敏捷开发又过渡了到DevOps。在2019年的中国DevOps行业报告中指出：“尽管受访企业期望 DevOps 能够带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践 DevOps 依然是一个难题 。”其中28.22% 被调查者认为自己组织的 DevOps 实践是不成功的， 41.13%的被调查者不清楚如何衡量自己组织的 DevOps 实践是否成功。如果以一个更加直观的数据来展示，就是在接受调查的企业中有69.35%是没有能很好的了解和实践DevOps的。也许，在实践DevOps的这几年来，并没有多少公司是真正知道什么是DevOps的。DevOps只是从字面上理解的打破部门墙的一键发布的工具链吗，是否有了这个工具链就是DevOps？答案是否定的。那么，DevOps是什么？DevOps 是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争——AWS从AWS给出的定义来看，好像也还是比较的抽象。那如果简单的来说，DevOps就是让软件过程既“快”又“稳”。何为快和稳，这个快和稳体现在，部署频率、交付周期、平均修复时长、变更失败比例这4个维度上。在2018年的DevOps调查报告中基于上述4个维度，由于仅有6%达到了所规定的高性能指标，为了避免特殊原因造成数据过低，所以放宽的条件，并给出了准高性能DevOps指标。从达成这一准高性能DevOps指标的团队分析来看，其具体体现在三个方面：一方面是自动化、标准化、质量保证、敏捷方法的实践活动上；一方面是DevOps各个阶段的对应工具上。除此以外就是，团队正在开发应用的架构上。架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。受访的准高性能DevOps指标的团队将“使用微服务框架”作为团队正在开发应用的架构上的Top1。什么是微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为Microsoft下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单URI来开放接口，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。微服务的特点根据Martin Fowler的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizza team”- 不超过12人）。产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。“去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。“去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。微服务适用的场景基于微服务的优势，我们可以看到，微服务比较实用于以下场景：对于业务流程较为复杂，且业务会变得逐渐复杂的项目，可以考虑使用微服务架构项目存在多个团队（公司）多种开发语言时核心业务和非核心业务变得泾渭分明需要平滑升级时（服务无中断、客户无感知）想对系统进行细粒度监控时 （bug调查困难或性能等问题）既然微服务有其使用的场景，那么也一定有其优缺点。微服务的优势微服务的诞生正是在互联网高速发展，技术日新月异变化以及传统架构无法适应快速变化等多种因素共同推动下的必然产物。从一个网站的演变可以看到使用微服务后带来了很多优点，总结如下：逻辑清晰：这个特点是由微服务的单一职责的要求所带来的。逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。简化部署：微服务则可以只对一个微服务单独进行部署，不影响其他功能的同时，在效率上也得到了提升，从而快速的发布新的功能。可扩展性强：在分布式系统中，采用微服务的系统相对单块系统具备更好的可扩展性。灵活组合减少浪费：在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的，减少了重复浪费。技术异构：微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。微服务的缺点以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：提高了系统的复杂度，此外还有：服务的注册与发现问题；服务之间的分布式事务问题；数据隔离再来的报表处理问题；服务之间的分布式一致性问题；服务管理的复杂性，服务的编排；不同服务实例的管理。微服务在使用上是一把“双刃剑”，这就像粮草如果在搬运的过程中被敌方夺取，那可能会是毁灭性的。所以DevOps团队在微服务的架构上需要非常的重视，一个成熟度高的微服务框架才是实现其DevOps的重要前提，反之亦然。

善用兵者，役不再籍，粮不三载。取用于国，因粮于敌，故军食可足也。                                                                                                                 ——《孙子兵法》在古代，带兵作战的将领，不仅要能善于用兵，而且要能保障粮食的充足。正所谓兵马未动，粮草先行。粮草永远摆在第一位，因为在冷**时代，战争中的将士都是在拼力气，吃饱才有力气打仗。在今天互联网的“战争”环境中，我们为了能更快的应对市场变化，一直以来不断调整着作战的方针和打法，也从传统的开发方式转变为了敏捷开发，由敏捷开发又过渡了到DevOps。在2019年的中国DevOps行业报告中指出：“尽管受访企业期望 DevOps 能够带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践 DevOps 依然是一个难题 。”其中28.22% 被调查者认为自己组织的 DevOps 实践是不成功的， 41.13%的被调查者不清楚如何衡量自己组织的 DevOps 实践是否成功。如果以一个更加直观的数据来展示，就是在接受调查的企业中有69.35%是没有能很好的了解和实践DevOps的。也许，在实践DevOps的这几年来，并没有多少公司是真正知道什么是DevOps的。DevOps只是从字面上理解的打破部门墙的一键发布的工具链吗，是否有了这个工具链就是DevOps？答案是否定的。那么，DevOps是什么？DevOps 是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。——AWS从AWS给出的定义来看，好像也还是比较的抽象。那如果简单的来说，DevOps就是让软件过程既“快”又“稳”。何为快和稳，这个快和稳体现在，部署频率、交付周期、平均修复时长、变更失败比例这4个维度上。在2018年的DevOps调查报告中基于上述4个维度，由于仅有6%达到了所规定的高性能指标，为了避免特殊原因造成数据过低，所以放宽的条件，并给出了准高性能DevOps指标。从达成这一准高性能DevOps指标的团队分析来看，其具体体现在三个方面：一方面是自动化、标准化、质量保证、敏捷方法的实践活动上；一方面是DevOps各个阶段的对应工具上。除此以外就是，团队正在开发应用的架构上。架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。受访的准高性能DevOps指标的团队将“使用微服务框架”作为团队正在开发应用的架构上的Top1。什么是微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为Microsoft下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单URI来开放接口，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。 微服务的特点根据Martin Fowler的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：1.  通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。2.  围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizza team”- 不超过12人）。3.  产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。4.  智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。5.  “去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。6.  “去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。7.  基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。8.  故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。9.  演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。微服务适用的场景基于微服务的优势，我们可以看到，微服务比较实用于以下场景：1.    对于业务流程较为复杂，且业务会变得逐渐复杂的项目，可以考虑使用微服务架构2.    项目存在多个团队（公司）多种开发语言时 3.    核心业务和非核心业务变得泾渭分明 4.    需要平滑升级时（服务无中断、客户无感知）5.    想对系统进行细粒度监控时 （bug调查困难或性能等问题）既然微服务有其使用的场景，那么也一定有其优缺点。微服务的优势微服务的诞生正是在互联网高速发展，技术日新月异变化以及传统架构无法适应快速变化等多种因素共同推动下的必然产物。从一个网站的演变可以看到使用微服务后带来了很多优点，总结如下：逻辑清晰：这个特点是由微服务的单一职责的要求所带来的。逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。简化部署：微服务则可以只对一个微服务单独进行部署，不影响其他功能的同时，在效率上也得到了提升，从而快速的发布新的功能。可扩展性强：在分布式系统中，采用微服务的系统相对单块系统具备更好的可扩展性。灵活组合减少浪费：在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的，减少了重复浪费。技术异构：微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。微服务的缺点以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：提高了系统的复杂度，此外还有：1.    服务的注册与发现问题；2.    服务之间的分布式事务问题；3.    数据隔离再来的报表处理问题；4.    服务之间的分布式一致性问题；5.    服务管理的复杂性，服务的编排；6.    不同服务实例的管理。 微服务在使用上是一把“双刃剑”，这就像粮草如果在搬运的过程中被敌方夺取，那可能会是毁灭性的。所以DevOps团队在微服务的架构上需要非常的重视，一个成熟度高的微服务框架才是实现其DevOps的重要前提，反之亦然。那么如何算得上是一个成熟度高的微服务呢？在华为云DevCloud专业服务中提供了微服务的能力评估，想知道成熟度高不高，快来看看你的微服务的成熟度评估结果吧~~~~~~~~~~~

动动手指点一点，领取码豆换好礼1、 跟着指引做任务→领取任务a)       在会员中心页面下拉，找到“应用管理与运维任务>微服务管理”，单击“查看服务治理面板”，跟着指引做任务注意，如果您还不是微服务的用户，需要单击“同意授权”成为微服务用户后再领取任务2、 完成任务后返回会员中心查看码豆到账喜欢的老铁请下方回帖给小助手刷不存在的火箭和潜艇，让小助手在寒风中感受下老铁们如春天般的关怀，球球了

当前全球的数字化浪潮逐步加深，云计算成为当今信息化发展的重要基础设施，云原生（Cloud Native）在数字化浪潮中的角色逐步提升，成为近几年云计算领域炙手可热的话题。首先我们来看看一张图，看看云原生产生的业务背景。商业模式决定了整个的研发模式，研发模式又决定了需要采用什么样的技术。从图中看出，传统应用、互联网应用、VUCA时代的应用，所处的不同时代引发的不同需求，由此带来对技术的不同要求。以往传统的应用需求是相对固定的，通常以项目化运作，用户的访问量可以预测，容量是有限的；而互联网应用的特征是，需求持续发展，产品化而非项目制，用户量并非线性往往会有陡增陡降，7x24小时是基本要求；逐渐到现在的VUCA时代，商业边界、业务层面是完全不可预知的，即便是对于互联网原住民都是巨大的挑战，要求快速地尝试、快速探测、快速的感知，应用是服务化的方式提供，业务敏捷性前提之下，对技术体系的持续发布、分布式海量并发、灰度发布和线上测试都是基本诉求。业务的敏捷性持续发布，应用平台的弹性诉求，商业环境的变化，这是整个云原生产生的业务背景。一个中心三个基本点，真正构建云原生能力云原生时代，在享受架构解耦与云端弹性带来的便利同时，对软件研发与交付模式提出了更高的要求。真正做到云原生的成功，我的总结是一个中心三个基本点：一个中心：以业务的价值交付为中心，达到快速与高效的交付价值，并且在规模化扩展的同时，兼顾可靠性、灵活性等。三个基本点：1、架构层面采用服务化架构/微服务架构实现全面解耦：把系统划分多个功能内聚、粒度合适、业务边界清晰、独立自治的服务/微服务。以（微）服务为单位演进系统架构，演进式的以绞杀者模式，而不是革命式的一次性改造；单个（微）服务以大于一个的无状态进程运行，实现自身的高可用和负载均衡；把业务数据分布到不同的（微）服务中实现数据的垂直切分；通过API，重用云原生公共服务提供的基础能力和架构能力：内部每个（微）服务须充分利用原原生的公共服务提供底层基础能力，例如微服务管控与生命周期管理服务、数据库服务、消息队列服务、缓存服务等；内部每个（微）服务须充分利用应用与资源编排服务，实现部署、配置自动化；通过API，打造生态化经济：API是非常重要的方式，除了定义服务之间的业务边界，更重要的是可以通过API的方式做整个生态，数字化转型中比如开放银行，都是这样的思路，搭一个平台，通过各种合作伙伴在不同的行业、不同的领域提供相关的服务，这些服务是相互进行连接，通过链接和网络的思维来去做这个事情。华为云也在打造自己的API生态。2、工程层面系统与环境、流程、配置解耦：与架构层面解耦相匹配，系统和环境、流程、配置等等需要解耦，工程层面也需要去相应的匹配跟解耦。开发、测试、生产环境等价，屏蔽环境差异性；采纳不可变的基础设施（immutable infrastructure）；构建端到端的DevOps研发体系：研发流程标准化、敏捷化；严格的区分构建、分布、运行的准入准出，并进行版本化和自动化；全自动化测试（单元测试、集成测试、自动生成Mock依赖服务）；一切皆代码，代码、配置与环境严格分离，并进行版本化和自动化；（微）服务持续交付流水线（按需发布版本）；研发运维一体化：运维和开发互相融合，高度协同，共担职责；自动监控，持续可视化反馈，并最终传导到开发团队；按需实时部署、配置热加载实时生效；使用自服务、敏捷的云化基础设施服务：基础设施以自服务的方式对开发团队提供。依赖底层云化基础设施的计算服务、存储服务、网络服务提供基础运行资源；使用云监控服务监控自身的运行状态包括基础资源使用状态、自身业务运行状态，同时根据自身运行状态触发相应的运维事件，实现弹性伸缩、故障自愈等关键架构特征；核心度量外部指标：业务层面的核心的一个业务指标叫TTM，在DevOps有另外一个词叫Lead Time，就是你的前置时间，从业务需求提出来那一刻起，到这个业务需求上线的时间叫前置时间，这个是可以被客户可知的，所以是端到端的业务指标。技术层面，对应的有多个前置时间，工程这一侧的，则是从提交代码那一刻起，一直到代码上线，这段时间是完全工程可控的，理论上应该是控制在分钟级。这个指标，也是华为云最为看重的一个。3、组织层面遵循康威定律：应用的架构和组织架构之间是高度的匹配，单体的应用，逐渐到服务化的方式，到逐渐分布式的模式。组织架构也是转移到自组织，没有一个唯一的中心在里面，自组织团队的敏捷性与多样性需要兼顾。整个团队的规模，典型的就是5-10人规模。全功能团队：从全功能团队一直到云化的运维团队。以服务为单位组织整个团队，涵盖设计、开发、测试、发布、部署、运维全流程职能；开发人员、发布工程师、IT和运维之间可信合作云化运维团队：基于云平台的提供的监控、报警等能力，成立专门的团队负责系统运行时的质量，保障系统可用性和业务无中断的升级、回滚自主经营，面向服务的全生命周期：逐渐转型为自主经营的全功能团队。除了技术栈是全功能以外，每一个服务化的团队都需要面向服务进行全生命周期的考虑，除了技术层面的怎么样去产品的设计、开发出来部署，架构层面保持优美，更多的还需要去考虑商业层面的东西，需要考虑服务定位，考虑产品上线以后，运营层面应该做什么事情，应该做什么样的拉新的活动，怎么样促活，怎么样留存。整个团队都需要有商业思维和产品运营的思维。这是整个思维上的转变，去考虑这个服务为什么这么做、谁去用、用的场景是什么，怎样完成商业的闭环。关注七大领域，持续优化交付粒度，加快交付速度，提升交付质量云原生架构下DevOps的落地与转型，是一个量变到质变的过程，需要从团队模型、分支模型、测试模型、技术架构、部署模型、基础设施、数据库模型等七大领域进行相应的匹配，持续优化交付粒度，加快交付速度，提升交付质量。以发布频度为抓手，从100天发布一次，逐步的十倍速增长，到10天发布一次。在这两个阶段点，从七个维度来看，需要匹配与采纳的实践是什么。这是一张能力演进的地图，我们可以清晰的看到自己业务当前所需要的发布节奏是怎样，当十倍速的走到下一个节点，方向在哪里，有的放矢的进行相应的采纳。持续交付实施框架华为内部有很多的优秀实践，华为云DevCloud就是生于云长于云的DevOps实践。华为云DevCloud从成立至今，软件的规模、团队的管理以及人员之间沟通的复杂性都急剧上升。通过云化、微服务化、容器化和流水线自动化等工程实践，以及敏捷、DevOps，全功能团队等管理实践，整体规模上升的同时，版本编译、版本构建成功率、系统回归测试、研发作业时间、资源复用率等指标不仅没有降低，反而得到了大幅度的提升，是支撑云原生架构的最佳组织和工程实践。

 中奖名单公布，以实际填写兑奖信息为准发放奖品。所有奖品将于12月20日前发放完成。1、活动期间（11月19日-12月10日）加入直播课堂抽奖-中奖名单。请获奖者填写领奖信息>>https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=9b25612506964581a2ea315ec9f00bf9&utm_source=kfz_qdjd，注：领奖信息收集截止至12月15日8点，过期未填写者将视为放弃领奖。2、12月2日&12月9日直播间抽奖（领奖信息已收集，12月20日前将完成奖品发放，请耐心等待~）回放地址＞＞https://classroom.devcloud.huaweicloud.com/joinclass/d2784d62244346b79d7c94576d7cef7c/1?utm_source=kfz_qdjd&utm_medium=techday—— （2大福利仍在继续） ——仍在继续的福利...福利3：体验微服务赢码豆 登录会员中心领取并完成任务，即可获得码豆奖励，码豆可兑换实物奖品。传送门＞＞https://bbs.huaweicloud.com/forum/thread-90982-1-1.html福利4：0元开通DevCloud基础版，回帖赢平板等大礼 开通地址＞＞https://console.huaweicloud.com/devcloud/?region=cn-north-4&version=0&utm_source=kfz_qdjd&utm_medium=techday#/order/periodApply回帖地址＞＞https://bbs.huaweicloud.com/forum/thread-90536-1-1.html（部分奖品）以下活动已结束→福利1：＞＞加入华为云技术开放日（第七季）课堂可抽奖可抽取京东卡、专业技术图书、¥465案例学院会员卡等奖品。抽奖时间：12月10日，抽奖对象：11月19-12月10日加入《华为云技术开放日（第七季）》直播课堂的全部学员。中奖信息将于12月11日在本帖及直播群公布。福利2：加小助手微信 解锁直播地址，直播过程中还可参与抽奖哦~奖品包括京东卡、专业技术图书、¥465案例学院会员卡—— 分享内容 ——话题1：异构微服务技术实践话题简介：本次直播分享微服务架构实践中为什么会使用多种微服务开发框架，存在什么样的问题，最佳实践是什么。重点探讨透明通信和统一治理等挑战性课题。期望通过直播，能够帮助开发者更好的做技术选型，更加敏捷的实现产品交付。分享嘉宾：刘宝Apache ServiceComb PMC，华为云微服务架构师拥有10+年Java开发运维经验，专注于微服务领域，目前负责Apache ServiceComb Java微服务开发框架、华为云微服务引擎的架构设计和开发，乐于分享开发和软件工程能力建设的心得，并在华为云微服务论坛、知乎微服务专栏发表。分享时间：2020年12月2日19:30-21:00话题2：微服务架构下的分布式事务技术话题简介：本主题介绍几种传统分布式事务技术，并重点介绍近几年流行起来的非侵入事务的技术原理与实践，为大家带来关于分布式事务技术选型的深入思考和实践经验。分享嘉宾：姜宇华为云微服务与分布式事务技术专家任职于华为云计算团队，20级技术专家，分布式事务中间件国内第一人。从0到1设计研发了业界领先的分布式事务中间件 DTM （十万级TPS）和高性能注册中心 SC （千万级服务实例）。曾就职于阿里中间件团队，是著名的分布式事务中间件 GTS / TXC 的创始人，独立开创了非侵入式事务技术领域，带领 GTS 成功商用于100+ 客户核心交易系统。作为顶级热度的开源项目SEATA（GitHub Star 17.8k）的作者，引领了分布式事务技术发展方向，已服务于数百重要客户。个人拥有20多个发明专利，包括3个华为B+ 级潜高专利（都是第一作者）。分享时间：12月9日19:30-21:00 *华为云开发者社区享有法律范围内的活动最终解释权。补充说明a)      本活动需要用户正常加入华为云Classroom课堂，同一电话号码注册的账号视为同一个用户，使用非正常途径或手段（如写脚本刷接口等方式）获得的奖励无效，且一旦发现作弊行为，华为云开发者社区将取消对应人员的获奖资格、冻结违规账号，已兑换的礼品也不予发放。b)      中奖名单将在本帖和微信群公布，请添加小助手微信确认获奖信息，并告知您的收货信息，以便于奖品的发放，未在规定时间内提供信息者视为弃奖。c)      活动期间获得的礼品将于活动结束后7-30个工作日内统一发货。

        服务网格 （Service Mesh）是一个用于管理、观测、支持工作负载实例之间安全通信的管理层。服务网格通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，而对应用程序来说无需感知代理的存在。服务网格通常由控制平面和数据平面两部分组成。数据平面运行在Sidecar 中，Sidecar 作为一个独立的容器和业务系统运行在同一个Kubernetes 的Pod 里面，或者作为一个独立的进程和应用程序进程运行在同一个虚拟机上，其主要充当业务系统的网络流量的代理。传统 RPC 中的服务发现、限流、熔断、链路追踪等能力都会下沉到Sidecar 中。Sidecar 为应用程序提供了一个透明的网络基础设施，让业务在低侵入或者零侵入的情况获得更健壮的网络通信能力。服务网格控制平面示意图        服务网格为微服务带来新的变革，主要体现在：服务治理与业务逻辑解耦，服务网格把SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以Sidecar 的模式部署，将服务通信及相关管控功能从业务程序中分离并下层到基础设施层，使其和业务系统完全解耦，使开发人员更加专注于业务本身；异构系统的统一治理，通过服务网格技术将主体的服务治理能力下沉到基础设施，可方便地实现多语言、多协议的统一流量管控、监控等需求。              服务网格相对于传统微服务框架拥有较多优势：超强的通信线路数据观察性，服务网格是一个专用的管理层，鉴于它在技术堆栈中处于独特的位置，所有的服务间通信都要经由服务网格，以便在服务调用级别上提供统一的遥测指标；“面向目的地的”流量控制能力，由于服务网格的设计目的是有效地将来源请求调用连接到其最优目标服务实例，所以这些流量控制特性是“面向目的地的”，而这也正是服务网格流量控制能力的一大特点。通过服务网格，可以为服务提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各种控制能力；微服务网络的增强安全特性，在某种程度上，单体架构应用受其单地址空间的保护。一旦单体架构应用被分解为多个微服务，网络就会成为一个重要的攻击面，更多的服务意味着更多的网络流量，这对黑客来说意味着更多的机会来攻击信息流，而服务网格恰恰提供了保护网络调用的能力。服务网格的安全相关的好处主要体现在以下三个核心领域：服务的认证、服务间通讯的加密、安全相关策略的强制执行。        服务网格带来了巨大变革，拥有其强大的技术优势，被称为第二代“微服务架构”。然而软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也有它的局限性：网络复杂性大幅增加，服务网格将 Sidecar 代理和其它组件引入到已经很复杂的分布式环境中，会极大地增加整体链路和操作运维的复杂性；学习曲线较为陡峭，当前的服务网格几乎都建立在以 Kubernetes 为基础的云原生环境上，服务网格的运维人员需要同时掌握Kubernetes 和服务网格两种技术，才能应对使用中的问题，增加用户的学习成本；系统调用存在额外性能开销，服务网格在服务链路中引入了Sidecar proxy，因在系统调用中增加了跳转而带来了延迟。虽然该延迟是毫秒级别的，在大多数场景下是可以接受的，但是在某些需要高性能低延迟的的业务场景下，可能是难以容忍的。来源：云原生产业联盟

云原生大趋势下，微服务架构也越来越盛行，11月14日在北京中关村e世界财富中心，针对“微服务”这一技术专题，举办了一场 “北京HDZ微服务专题技术交流会暨北京HDZ线下授旗仪式”。本场活动由北京HDZ开发者社区主办，邀请了华为、美团、字节跳动三大厂的架构师轮流分享，与现场的开发者交流技术，干货满满。（华为HDZ开发者社区，以下简称HDZ，是Huawei Developer Zone的英文缩写，是华为开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。） 技术分享环节中，首先是华为云微服务首席架构师田晓亮分享了《华为云的微服务实践》。华为云引入了kubernetes、promethues等云原生项目，自然也开始大范围使用go语言自研云服务。几年前go的生态并不完善，往往需要自己从头到尾编写工具库，另外要落地微服务架构模式，有大量基础能力需要编写，go chassis就是在这样的背景下诞生的，本次就是分享华为云微服务实践，介绍如何治理go云原生应用。华为云微服务首席架构师田晓亮 第二位分享嘉宾是C，分享主题为《复杂环境下落地Service Mesh的挑战与实践》。首先介绍美团Service Mesh技术与服务治理体系融合的进展，重点分析美团及大家落地Service Mesh需要面对的多个层面的复杂性困境，并详细讲解应对策略及实践经验。华为云微服务首席架构师田晓亮 第三位分享嘉宾是字节跳动架构组资深架构师马子昂，分享课题为《字节跳动微服务流量治理体系简介》。微服务架构和单体架构有着诸多不同，它解决了很多问题，也带来了治理上的复杂度。为了应对这些复杂度，我们需要逐步完善公司内的流量治理体系，来满足微服务的治理需求。本次演讲将详细列举出成熟的微服务流量体系应当具备的治理能力。这可以方便已经做了微服务体系迁移的公司进行一些查漏补缺，也可以帮助打算向微服务体系迁移的公司，做微服务基础设施建设。 字节跳动架构组资深架构师马子昂现场观众认真聆听并做笔记，纷纷对三位讲师提出了自己的问题和疑惑，与老师探讨交流。活动现场还举办了北京HDZ授旗仪式，宣布北京HDZ开发者社区正式成立，核心组表示，北京HDZ将开展更多的线上、线下技术分享和沙龙活动，与开发者们交流、切磋、共享，也希望有更多的人加入进来，一同共建开放、创新、多元的开发者社区组织，共同构建繁荣的开发者生态。【北京HDZ微服务-微话题】正在进行中，点击参与活动， 盖楼赢手表！！！PS：附件为讲师们分享的ppt，欢迎大家收藏~~HDZ社区—携手全球开发者 共建开放、创新、多元的开发者社区组织       HDZ是Huawei Developer Zone的英文缩写，是华为开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。      致力于帮助开发者学习提升、互动交流、挖掘机会，推动ICT、互联网等产业生态的建立和发展。      对云计算、IoT、人工智能、5G、区块链、鲲鹏、昇腾、软件开发与运维、开源等各技术领域感兴趣的开发者、软件工程师、创业者、运营人、产品人、大学生、老师等都可以参与到HDZ。      HDZ秉承开放、创新、多元的社区文化，完全由各地HDZ组织者、志愿者自发组建和领导。华为公司不直接参与HDZ组织建设和领导，只按需对HDZ社区活动提供必要的方向指导、资源支持、活动支撑等，并为各地HDZ组织者提供与全国组织者互动交流的机会。

下载obs文件到本地，使用断点续传下载，分段大小为3G。代码参考https://support.huaweicloud.com/sdk-java-devg-obs/obs_21_0709.html6G的文件失败一次再重试可以成功，但是25G的文件重试了3次还是失败，一直报SSL peer shut down incorrectly。使用的是华为内部的jre1.8.0_232

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。如果你也对这样的话题感兴趣，欢迎参与到我们的这次微话题讨论中来。=========【本次微话题】分享盖楼 赢好礼==========微话题：“您所在的企业正在使用go做哪些业务，期望框架能够帮助你做哪些事？”微话题活动：参与本次微话题讨论，有机会获得优质评论奖活动时间：2020年11月05日-11月25日参与方式：直接在本帖回复你关于以上问题的观点或评论（要求：需要写出回答，如具体什么业务、什么事情）（要求：需要写出回答，如具体什么业务、什么事情）（要求：需要写出回答，如具体什么业务、什么事情）获奖方式：一、【优质评论奖】活动结束后，将由华为云讲师选取出3名优质评论奖：HUAWEI WATCH GT2，选4名。 二、【盖楼奖】6层、16层、66层、，获得：HDZ定制钢笔+笔记本套盒。166层、266层、366层，获得：华为智能体脂秤 2 Pro 雅致白+笔记本套盒，以此类推。【注意事项】1.获奖结果将在活动结束后5个工作日内进行公示，请获奖者在公示后5个工作日内联系或添加HDZ小助手（微信号Huawei-HDZ）微信反馈您的邮寄信息，所有奖品将在活动结束后15个工作日内发放。2.为防止有恶意发帖行为，同一ID回帖不得超过5条，若超过将取消获奖资格。3.每个ID只能参与一次评选，同一ID不可重复中奖。4、发帖要求：需要写出回答，如具体什么业务什么事情—————※—————※—————※—————※—————※—————※—————※—————※—————北京HDZ将于11月14日 下午13:30举办一场微话题实践的线下交流会邀请了来自华为云、美团、字节跳动的技术专家一同分享微服务实践专题欢迎北京的开发者们前来活动现场参加备注：扫描海报上的小助手二维码，入活动群，活动前将通知具体地点本次活动将在14日下午进行同步直播：点击跳转至直播观看地址PS：附件为讲师们分享的ppt，欢迎大家收藏~~中奖名单：恭喜以上的伙伴，获得相应礼品~请添加HDZ小助手（微信号Huawei-HDZ） 将收货地址及中将截图凭证发给小助手哦~另新增2个超用心回答的惊喜补充奖品，将获得：分别HDZ笔记本套盒1份 ~获得手表的伙伴记得给小助手提供中奖秘钥哦~HDZ社区—携手全球开发者 共建开放、创新、多元的开发者社区组织       HDZ是Huawei Developer Zone的英文缩写，是华为开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。      致力于帮助开发者学习提升、互动交流、挖掘机会，推动ICT、互联网等产业生态的建立和发展。      对云计算、IoT、人工智能、5G、区块链、鲲鹏、昇腾、软件开发与运维、开源等各技术领域感兴趣的开发者、软件工程师、创业者、运营人、产品人、大学生、老师等都可以参与到HDZ。      HDZ秉承开放、创新、多元的社区文化，完全由各地HDZ组织者、志愿者自发组建和领导。华为公司不直接参与HDZ组织建设和领导，只按需对HDZ社区活动提供必要的方向指导、资源支持、活动支撑等，并为各地HDZ组织者提供与全国组织者互动交流的机会。