云原生所具备的技术价值和业务价值，是初创企业应对不确定性的最佳选择。作为共享经济的典范，相信很多人对Airbnb并不陌生，但在征服全球用户的过程中，Airbnb也经历了很多不为人知的巨大挑战。 尤其是面对不同地区、不同文化下的多变市场，要实现预订流程、支付系统等多个步骤的简单易用，在底层技术上来讲却极其复杂。 支撑Airbnb快速发展的秘诀之一就是基于云原生（Cloud Native）的系统架构，这使其能够比竞争对手更快，更具适应性，并重塑且主导整个行业的发展。 和Airbnb类似的独角兽企业还有奈飞，同样基于云原生，奈飞从一家邮购公司成功发展为世界上最大的流媒体播放平台。01 成为云原生意味着什么？ 随着Airbnb、奈飞的惊人成功，很多企业也想搞清楚他们到底是如何利用云原生技术实现如此巨大的竞争优势的。那么，到底什么是云原生？为什么“云原生”正在变得越来越重要？为什么需要云原生，它对你的业务到底有什么价值？到了移动互联网时代和物联网时代，随着各类软件应用在各行各业渗透，企业业务高速发展，用户量激增。面对大量用户和复杂场景下的各种新需求，导致企业软件业务需要快速迭代和优化，同时要把更多人力、物力、精力放在业务逻辑构建上。如果按照传统模式，企业要么自购硬件、软件等基础设施，再请专业人员来维护，不仅耗时长、成本高，而且弹性差、速度慢，高峰时往往不够用，平峰时却会浪费资源。而通过云计算，会使得存储、计算等信息服务像水电煤等公共基础设施一样，可以通过网络灵活按需使用，企业不再需要关心运营、扩容、维护等事项。如果你说可以节省成本，提高弹性和运营效率，我们通过上云就可以实现所有这些目的，为什么我们还需要云原生？实际上，在这个过程中，基础设施的上云只是第一步，想要将应用云化才能真正发挥云的价值，而这也恰恰是云原生的核心理念。恰如“一千个人眼里有一千个哈姆**”，大家对云原生的解释和定义也众说纷纭。简单来说，云原生就是利用云的优势来更快地处理企业业务并降低IT成本，目标就是根据需求快速、敏捷地向用户交付软件产品。基于云原生技术带给企业的应用开发的技术价值，可以大幅降低企业IT开发和运维成本，从而提升企业业务的创新效率和产业价值。我们也看到，在企业上云的大趋势下，越来越多的企业和开发者也开始把业务与技术向云原生演进，微服务、容器，以及动态编排为代表的云原生技术被越来越广泛应用，成为赋能业务创新的重要推动力，并已经应用到企业核心业务。尤其是容器彻底改变了云的使用方式，容器的重要性怎么形容都不为过，它解决了许多问题的同时，还创造了新的架构可能性。容器化是搭建云原生的关键，如果说云原生是一栋高楼大厦，那么容器化便是这座大楼的地基，重要程度不言而喻。业内常以“集装箱”来比喻和解释容器，和集装箱一样，容器的特点也是标准化和可移植性。 即，将支持应用代码运行所需相关的环境打包封装，实现应用构建、分发和交付标准化，不需要再关心开发和运行环境，在任何地方都可以运行。 相比以往，开发人员不再交付大型的整体应用程序，而是要在容器内部将它们分装成小块，从而使管理、部署和更新变得更加容易。随着微服务和容器化的不断演进，应用程序也越来越靠近边缘，越来越靠近用户，如果要跟上客户的步伐，就必须在这些方面增强竞争力。大多数公司要想具有竞争力，就必须围绕微服务来架构自己的应用，而容器很适合微服务，在不同的容器中运行微服务都可以独立部署，甚至可以用不同的语言自动化部署。由于容器是可移植的，并且可以相互隔离地运行，因此使用容器创建微服务架构并在需要时将其移动到另一个环境中非常简单。这也就是Airbnb、奈飞之所以能够在不同国家、不同文化下快速发展的主要原因，云原生技术前所未有地重塑、改造和扩展了企业做软件开发的方式，让它们能够更快地为客户提供更多的功能和服务。如Airbnb从单体架构过渡到微服务架构后，团队需要横向扩展连续交付的规模时，就可以让上千名工程师使用它很容易地添加新服务。总而言之，企业采用云原生可谓好处非常多，最主要的是可以提高敏捷性和生产力，比如在几分钟或几小时内将新的想法投入生产，从而提高创新能力和竞争力。在云原生技术之前，在你的平台上添加一个新的业务组件意味着需要雇佣一大支队伍，需要几个月的时间来实施。但现在，云原生技术正在成为全新的生产力工具，通过使用云原生的微服务和容器，可以节省很多成本和时间，使您可以专注于业务创新。云原生的最终目标就是让企业的开发者不再写基础设施代码，而是专注于功能创新，当基础架构摩擦减少时，企业就会更加敏捷，更具竞争力。这也是人们对Airbnb和奈飞等独角兽公司如此感兴趣的原因之一，他们已经很好地实践并做到了这一点。02 中国企业的机遇与挑战 从云原生的进展来看，中国正在与全球市场一同迈入云原生时代。尤其是中国正越来越成为技术创新、试验的最好土壤，云原生很可能将在中国的互联网场景下逐渐走向成熟。AI、大数据、视频等能力成为新的云原生能力。CNCF大中华区总裁Keith Chan之前表示，新冠肺炎疫情从根本上改变了商业模式，我们正处在一个巨大的转变之中，越来越多的企业将成为云原生企业。据云原生产业联盟此前发布的《中国云原生用户调查报告(2020年)》显示，云原生应用建设需求在逐渐增长，60%以上的用户已在生产环境中应用容器技术，43%的用户已将容器技术用于核心生产业务。实际上，目前云原生已经进化至2.0时代，华为云此前在业界首次提出了“云原生2.0”的理念，让每一家企业都能成为“新云原生企业”，享受云原生的技术红利。而这也是企业智能升级的新阶段。在华为云看来，云原生1.0阶段，企业将业务从线下搬迁并运行在云上，即ON Cloud，解决了运维、部署、扩容的难题，但传统应用单体架构过于厚重、烟囱式架构带来的系列问题并没有解决。到了云原生2.0阶段，企业既需要让业务生于云、长于云，即IN Cloud，基于AI、大数据、音视频、边缘计算等云原生技术跨越数字化转型深水区，也需要继承和发展已有能力，与新生能力有机协同、立而不破，让每一个企业都能成为新云原生企业。可以预料的是，面对云原生技术所释放出的巨大红利，一定会重塑中国企业IT的各个环节，让企业IT能够更好地去利用云上的各种设施和服务，从而在效率和成本上更具竞争力，并进一步构建业务智能。尤其是经历了2020年这个百年未有之大变局之年，在后疫情时代，企业如何应对困境，如何转型升级成为了一个亟待解决的命题。中国企业将面临着众多不确定的挑战，亟待增强企业的灵活和适应性，云原生所具备的技术价值和业务价值，是中国企业应对不确定性的最佳选择。03 让更多初创企业长在云上 一个事实是，云原生2.0非常适合初创企业，初创企业因为自身业务的高速增长和不确定性需要云原生。同时，初创企业也没有任何历史负担，可以在应用的架构初期就按照云原生的思想和架构去构建IT系统，也决定其能够充分用好云原生的能力。云原生能够给初创企业带来四个非常关键的好处：高效、敏捷、智能、安全。先进的云原生架构能够匹配并支撑初创企业未来快速的业务发展，并持续高效获得云上快速发展壮大的云原生能力。使初创企业真正实现“生于云、长于云”。但这个过程不是一蹴而就的，国内目前仍有包括传统制造业、零售、教育等多数行业的云原生渗透处于低位，有很大的进步空间。作为云原生技术的重要引领者，华为云为此推出了一整套完备的方案、提供多重扶持来支撑初创企业云长在云上。以一个初创APP开发企业为例，不仅可以申请免费云资源，除了包含华为云部分的技术赋能，还可以结合华为终端消费者云团队，针对企业的移动APP的开发构建、应用分发、业务增长和流量变现等等提供全方位的支持。这个过程中，如果企业有出海诉求的话，还可以申请HMS伙伴计划扶持，获得更多支持。而从初创企业自身的特点来看，一般小而精的初创企业往往对产业链有着很高的依赖，因此更需要借助产业集群的力量。华为云基于中国经济本身的特点与产业集群的特点，提出了“产业云”的概念。即基于云基础设施，整合产业生态资源以提供技术、解决方案、产业实践服务的城市产业赋能平台，为推动城市产数融合、产业创新升级、重塑产业新格局提供核心驱动力。以主要研发激光眼底成像设备的苏州微清医疗器械有限公司为例，由于青光眼发病、诊断的复杂性，加之眼底病灶微小，需要具有丰富经验的眼科医生利用专业设备进行筛查，大大制约了眼底设备的使用范围及青光眼筛查速度。基于传统光学眼底相机的算法无法突破光学眼底相机低穿透性的桎梏，在面向未来老龄人口增多，屈光间质情况复杂的情况下，微清医疗的共焦激光眼底相机将大有作为。基于此，微清医疗与华为云EI算法团队进行了多次的沟通和交流，以微清眼底激光图像为基础，利用华为云在AI算法和平台上的领先技术，实现对青光眼等眼底病变的AI识别辅助诊断，同时结合微清硬件设备+华为AI模块，打造全自动AI辅助眼底诊断系统。在此基础上，华为苏州人工智能创新中心还联合微清，苏大附一院强强联合，分工合作，打造出了面向未来的AI辅助眼底诊断系统，算法甚至超过了国际水平。可以看到，类似华为苏州人工智能创新中心这样产业云创新中心，整合产业生态资源，以提供技术、解决方案、产业实践服务的城市产业数字化赋能平台，在扶持初创企业云原生发展的过程中起到了非常重要的作用。与此同时，华为还推出了沃土计划，提供免费的云资源，最大程度上减轻初创企业的成本压力。在销售通路上，华为云推出了SaaS伙伴扶持计划，可以进入严选商城，初创企业和华为云联合创新，在华为平台上提供自己的解决方案，获得更广阔的商业机会。华为云还通过搭平台，举办初创企业大赛的方式，联接初创企业和投资人，让优秀的企业可以借此机会获得投资人青睐。3月24日，在深圳落地的华为云微光训练营上，华为云就完整打包了“云技术+云资源+云市场平台+投资人的丰富资源”来赋能更多的初创企业。作为华为云“微光训练营”今年举办的首场活动，大湾区专场也将打响华为云赋能初创企业的“第一枪”。此次活动将持续三天，超百家企业现场参与，而年内训练营还将在全国6大城市集群落地，覆盖超过1000家初创企业。华为云“微光训练营”大湾区专场启动仪式2011 年，Marc Andreessen 说出了那句著名的论断：“软件正在吞噬世界，10年后的今天来看，我们已经习以为常。”今天“吞噬”世界的则成了炙手可热的“云原生”技术，未来的软件一定是长在云上，企业也必将长在云上。事实上，今天大多数公司都意识到了云原生的重要性，很多企业之间的打招呼术语已从“你今天上云了吗？”转变为“你今天云原生了吗？”能够让更多的初创企业在智能世界的“黑土地”上创意发芽，一同迈向万物互联的智能世界，这也是云原生技术的价值之所在。 

作者名：关耳山石作者博客链接：https://bbs.huaweicloud.com/community/usersnew/id_1593343710234702 摘要：对于一个合格的CloudNative应用，应该把自己的程序当做开源软件来编写的，不该将数据库连接信息和密码放在代码里，一定要将配置外置。对于一个合格的CloudNative应用，应该把自己的程序当做开源软件来编写的，不该将数据库连接信息和密码放在代码里，一定要将配置外置。因此我试着在华为云上落地这套标准，期间尝试了从ServiceStage、CCE、CSE这三个入口进行配置注入，最终实现能够在应用启动时，主动拉取配置，覆盖本地配置文件里的调试配置，并能够在线配置并生效。打法是：CCE配置启动参数，制定SpringProfiles；配合CSE做应用配置，将资源外置后的配置记录于此，并可以动态更新，最终实现了配置外置的诉求。另外，通过这次增加的多版本管理，尝试梳理了一下ServiceStage的组件、CCE的workload、CSE的应用和微服务之间，错综复杂的概念之间的关系，个人浅见，欢迎指正：1. 初始化配置在系统初始化的时候，不可能一点配置都没有，所以保留一些基础配置在配置文件里是有必要的。配置外置并不意味着100%的配置都要外置，而是把外部依赖资源的配置，特别是容易变化配置外置。1.1 启用Bootstrap和Spring profile在代码层面，首先要进行基础配置。先看代码结构，这里除了最基本的application.yaml，增加了bootstrap.yaml和*-dev.yml等带后缀的文件。介绍一下原理：首先介绍Bootstrap Application Context：它是Spring Cloud Context的父Context，所以从外部配置源里加载配置一般从这里来，且优先级高于其他一切配置文件。于是，我们也利用这个能力，借助CSE的微服务配置中心能力，进行Spring的外部参数写入。然后介绍Spring profiles：为了把通用配置和环境相关的配置区分开，比如DEV环境没有AK/SK认证，而线上环境都有认证，这种配置项上的区别，引入了Spring profiles的概念，当Springboot启动的时候，会根据profiles.active参数判断应该启用那个环境配置PS：参考SpringCloud官方解释另外，就是哪些配置应该放在配置文件里，理论上除了最基础的配置，在启动时使用的，其余的配置都可以放在CSE的微服务配置中心里，而不必在本地配置文件里存在，另外就是本地配置里存在的，也可以通过二次设置在微服务的配置中心里，进行覆盖，比如数据库连接池的大小，而不需要修改代码，至于改完以后，要不要重启，那就得看生效的逻辑了。1.2 引入CSE配置中心CSE配置中心引入，需要先引入依赖包，然后在bootstrap.yaml中配置CSE配置中心的地址、认证信息等。这里可以参考官方文档，主要关注bootstrap.yaml的配置参数：使用分布式配置中心补充：获取spring-cloud-starter-huawei-config的版本参考地址：huaweicloud/spring-cloud-huawei可以参考现有的SpringCloud基线版本，选择SpringCloud-Huawei的版本补充：关于配置中心的优先级微服务引擎提供了分层次的配置机制。按照优先级从高到低，分为：配置中心（动态配置）Java System Property（-D参数）环境变量配置文件参考官方文档：配置微服务2. 本地CSE配置中心能力验证前提条件，本地得安装一个Local-CSE并启动，这部分参考云上DevOps：2.1-本地环境准备2.1 配置application.yaml和bootstrap.yml原始文件可以参考Github的Demo，配置文件入口，我这里进行了修改，因为bootstrap.yaml优先级高于application.yaml，参数只要在bootstrap.yaml中出现过，就不会使用application.yaml中的配置了。上代码，application.yaml，可以看到配置很少，因为大部分bootstrap.yml中已经包含，就都去掉了这是bootstrap.yml，注意这里的spring.application.name、spring.cloud.servicecomb.discovery.appName和spring.cloud.servicecomb.discovery.version会组成一个微服务私有的参数作用域，这里的优先级高于全局作用域application。特别注意，云上的CSE环境，除了上面提到的，还需要增加server.env参数。另外，server.env有四个参数可以选development、testing、acceptance、production关于如上参数的定义，参考官方文档：使用分布式注册中心和官方文档：使用分布式配置中心。2.2 准备验证代码直接上代码2.3 静态配置能力为了验证CSE配置中心的参数，是否能覆盖application.yaml中的参数配置，我选了一个很特别的参数：spring.datasource.password，如果能够覆盖成功，那么启动后，创建数据库连接池一定会报错。首先，打开本地CSE配置中心，地址为：http://localhost:30106/#/cse/services/config，创建一个配置项，作用域选VodMgrService@CabgOne#1.0.0，关于application的作用域后面再解释。重启本地微服务，启动后创建数据库连接池就报错了，符合预期。结论：CSE配置中心的参数，能够覆盖application.yaml中的参数配置2.4 动态配置能力为了验证CSE配置中心的参数动态生效，需要使用注解@RefreshScope，同时也引入ConfigRefreshEvent来监听事件变化，这样就会得到一个效果，对于动态生效的参数，可能需要一些重建或刷新，比如连接池、缓存、Client等。首先，增加一个配置项config.value然后很快可以看到后台日志打印出来，包括自己的监听器，也响应了日志查看一下数据，已经响应为TryMe具体的配置，在后台是轮询的，响应周期配置参数为cloud.servicecomb.config.watch.delay，目前是10秒一次修改一下配置，为TryMeAgain

如下图所表示的，修改了yaml文件，然后报错了。已经替换了几次ak/sk，而且都是新建的ak/sk，还是超出了次数。怎么解决呢？？？？？在线等。

--------活动已结束--------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故障时，是否会影响到业务侧？

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大势中新一轮浪潮，让我们拭目以待。

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，全功能团队等管理实践，整体规模上升的同时，版本编译、版本构建成功率、系统回归测试、研发作业时间、资源复用率等指标不仅没有降低，反而得到了大幅度的提升，是支撑云原生架构的最佳组织和工程实践。