常常有童鞋做完任务领了奖励就挥一挥衣袖不带走一片云彩但是！！创建的资源没有删，它它它就一直在扣费啊，心痛！所以小助手在这出个删除【ELB+集群+VPC】的教程，避免大家有不必要的损失。删除资源秘笈一、首先删除我们创建的环境（这个免费）二、其次删除ELB负载均衡器（这个正在扣钱）先删除监听器：listener-test01和listener-HTTP然后返回负载均衡器页面删除ELB，记得一定要勾选【释放该负载均衡绑定的弹性公网IP，不然要再去删一遍弹性IP，切记】三、然后删除k8s集群（这个扣钱最多）注意：如果是购买的包年包月，则无需操作，包租期类型的资源到期之后会自动释放先在基础设施下找到K8S集群，单击要删除集群的“更多”下的删除集群然后勾选图上内容，输入“DELETE”确认删除即可四、再然后删除弹性IP（扣钱ing）先在左上角服务下找到虚拟私有云VPC，并进入控制台然后在弹性公网IP和带宽下找到弹性公网IP，如果操作需要解绑，那就先解绑再删除，如果不需要解绑，就直接点更多里面的删除即可。五、最后删除VPC（这个免费）先在基础设施下找到虚拟私有云（VPC），单击要VPC的名称找到子网并删除，才能删除VPC注意，出现如下提示，是因为集群还没完全删除，需要【休息休息一下】，等待集群删除完成就可以啦！集群删除成功后，单击操作中的删除，子网也可以删除了最后在虚拟私有云页面删除VPC即可好啦，本次的保姆级删除资源教程就到这里，还有啥问题可以直接社区发帖求助哦，小助手不会的，大神来帮忙！

跟着我左手右手一个慢动作，解决问题是关键一、在环境管理页面创建一个环境二、环境名称设置为env-test01，然后设置基础资源和可选资源，创建一个环境        基础资源选择刚才创建的集群        可选资源选择ServiceStage免费提供的微服务引擎和刚才创建的ELB负载均衡      单击立即创建即可三、回到体验中心单击立即体验四、选择已有环境，选择刚才创建的环境并单击立即部署即可五、单击应用入口就能看到部署的天气预报啦，大家可以查询自己城市的天气哦六、今天的深圳也在下开水和蒸包子之间徘徊呢.......ε=(´ο｀*)))唉，你那里呢？

微服务实战点击立即部署没有反应，请问如何解决？使用的是谷歌浏览器。

微服务实战四期码豆已经发放，小伙伴们快来！大家可以通过会员中心看自己的码豆到账哟为避免无法发放码豆，请从未登录过会员中心的用户提前登录一次码豆会员中心四期活动时间为：2020年10月12日~10月30日添加小助手微信：little-one-1806 或 扫下方二维码 进群了解更多微服务信息，码豆发放、奖品抽奖和每期活动开启，小助手会在群里pick大家哦~微服务全生命周期实战体验（第三、四期）再不学微服务你就out啦！华为云微服务推出全生命周期实战，依托一键部署应用上云，零门槛体验引用托管DevOps全流程，微服务灰度发布、微服务治理统统掌握，保姆级教程让你玩转微服务。提升微服务能力，云原生进阶实战正当时，快来体验吧！  活动时间2020年10月12日-2020年10月30日 参与流程01 分享海报02 邀请体验03 完成打卡04 奖励发放分享文案+海报至朋友圈或100人以上技术群（微信、QQ、钉钉不限）。即可获得码豆奖励点击完成ServiceStage流程体验（体验指导见下方）（免费）按打卡样例截图，在教程帖完成打卡，即可获得码豆奖励活动结束后15个工作日内发放码豆奖励·         点击领取分享任务>>>·         点击进入四期微服务治理Demo体验>>>·         点击进入四期微服务治理Demo体验详细指导>>> 活动期间参与活动获码豆换好礼：     1、分享海报并上传分享截图：可获得500码豆（最高可获1000码豆）2、 完成第四期学习和体验并截图打卡：可获得1000码豆；3、 邀请好友并成功完成打卡：可额外获得1000码豆；参与活动用户最高可获得4000码豆注：具体活动规则见下方活动规则&奖励为避免无法发放码豆，请从未登录过会员中心的用户提前登录一次码豆会员中心  活动规则 & 奖励·         活动期间内，完成课程学习与体验并截图打卡，可获得1000码豆（注：需按下方打卡格式打卡），还可获得由华为云专家精选10个反馈送出荣耀智能体脂秤、华为快充移动电源 10000mAh (Max 18W) Micro版。·         邀请好友完成学习&体验并完成打卡，可获得1000码豆，注：被邀请人打卡时需提交邀请人账号·         分享任务规则&奖励：分享活动可获得500~1000码豆奖励第一步：      点击领取分享任务>>>第二步：     分享完成1小时后截图，点击这里或复制打开链接：https://www.wjx.top/jq/90009476.aspx 上传分享截图；符合要求的截图即可算作分享成功。注：上传分享海报截图时，请勿填错账号，影响奖励发放·          邀请好友体验任务规则&奖励第一步： 登录ServiceStage控制台，单击“开始教程”学习应用上云流程第二步： 浏览并截图打卡即可（必须包含右上角华为云账号）邀请好友体验任务打卡格式样例注：回帖打卡格式：（打卡样例）1、华为云账号：hw202007（即右上角的字母数字组合ID）2、邀请我的华为云账号：hw202006（即右上角的字母数字组合ID，如无就不填）3、课程学习心得/实战问题反馈/课程建议：：（选填，欢迎发表感想）4、体验任务截图：（打卡样例图） 好友体验任务打卡截图1（必须包含右上角华为云账号）请按回帖格式在教程帖回复并上传截图进行打卡注：华为云账号请勿填错，如填错码豆奖励无法发放到账。 ·          实战打卡任务规则&奖励微服务实战三期灰度发布正在酝酿中，具体开始时间请加小助手进群等待通知微服务实战四期服务治理：打卡格式样例注：回帖打卡格式：（打卡样例）1、华为云账号：hw202007（即右上角的字母数字组合ID）2、邀请人华为云账号：hw202006（即右上角的字母数字组合ID，如无就不填）3、课程学习心得/实战问题反馈/课程建议：（选填，欢迎发表感想，可参与最佳体验反馈奖）4、体验任务截图：（打卡样例图）实战体验截图1（必须包含右上角华为云账号）实战体验截图2请按回帖格式在教程帖回复并上传截图进行打卡注：华为云账号请勿填错，如填错码豆奖励无法发放到账。 ·         深度体验抽大奖啦完成以上分享、邀请、打卡体验活动，即可参与抽奖~·         三期抽奖送豪礼 HUAWEI WATCH GT 2e 运动款·         四期抽奖送豪礼 HUAWEI Sound X 智能音箱   以下满足抽奖资格的用户请以下用户加小助手微信（servicestage02），反馈分享任务所填写的微信号进抽奖群啦！四期深度体验抽奖时间：11月16日上午10点整，请符合抽奖资格小伙伴快进抽奖群啊！序号华为云账号1DouDou_2hw199822173JaneConan4jinxingfei5khg3053875436yinzhenxing  注意事项1）活动结束后15个工作日内发放码豆奖励，码豆发放后自行在兑换商城兑换即可，所有奖品均包邮，不额外收取任何费用。2）禁止恶意刷数据等作弊行为，如有发现，取消获奖资格；3）遵守华为云社区常规活动规则：https://bbs.huaweicloud.com/forum/thread-5766-1-1.html4）本活动最终解释权归华为云智能应用平台团队所有。---------------以下为一期二期相关数据---------------【微服务实战第一、二期】《微服务全生命周期实战体验》任务规则&奖励保姆级教程让你玩转应用一键上云，体验应用托管DevOps全流程！任务一：分享任务规则&奖励： 活动时间：2020年9月03日-2020年9月26日分享海报，可获得500码豆激励！最多可获得1000码豆。第一步： 分享以下文案+海报至朋友圈或100人以上技术群（微信、QQ、钉钉不限）。（注：如分享朋友圈需满1小时后截图）分享可获得500码豆！码豆可用于兑换DevCloud会员中心精美实物礼品。（1）文案：我正在参与华为云【微服务实战第一期】《一键部署体验云上微服务应用》，保姆级教程玩转应用一键上云，体验应用托管DevOps全流程！实战进阶还能赢千元豪礼，快来参加吧！（2）海报：添加小助手微信（little-one-1806）或扫下方二维码，回复“分享海报”获取海报和文案。第二步： 分享完成后，截图并点击链接上传分享截图；符合要求的截图即可算作分享成功，获得500码豆，最多可获得1000码豆！码豆奖励会在活动结束后15个工作日内发放。注意：为保证码豆成功发放，请先登录一次会员中心 任务二：体验任务规则&奖励：活动时间：2020年9月03日-2020年9月26日完成体验任务，可获得1000码豆激励！还可参与抽奖哦~第一步： 体验微服务实战，就可获得1000码豆！同时打卡晒出你的课程学习心得/实战问题反馈/课程建议等，还可获得由华为云专家精选10个反馈送出荣耀智能体脂秤、华为快充移动电源 10000mAh (Max 18W) Micro版（白色）。第二步：体验完成后，截图并在教程帖盖楼回复上传截图和心得；符合要求的截图即可算作分享成功，获得1000码豆！码豆奖励会在直播活动结束后15个工作日内发放指路第一期：【微服务实战第一期】《一键部署体验云上微服务应用》保姆级教程指路第二期：【微服务实战第二期】《体验微服务DevOps流程》保姆级教程注：活动期间，每人最多盖5楼。添加小助手微信：little-one-1806 或 扫下方二维码 进群了解更多微服务信息，码豆发放、奖品抽奖和每期活动开启，小助手会在群里pick大家哦~注意：为保证码豆成功发放，请先登录一次会员中心 任务三：深度体验任务规则&奖励： 活动时间：2020年9月03日-2020年9月26日小助手会自动统计完成深度体验的用户，并于每周五在活动群公布上榜名单并通过社区帖回复独立验证码，上榜的用户可加小助手微信反馈独立验证码，活动结束后将给用户发放抽奖码，记得进群关注哟~完成分享、盖楼、体验活动，即可参与抽奖，每期都送千元豪礼！一期抽奖 OSMO MOBILE灵眸手机云台3二期抽奖送豪礼 HUAWEI FreeBuds 3 无线耳机三期抽奖送豪礼 HUAWEI WATCH GT 2e 运动款四期抽奖送豪礼 HUAWEI Sound X 智能音箱       一期深度体验的用户名单出炉啦！以下用户请添加小助手微信号并反馈独立验证码哟~（小助手会在您盖楼的教程帖私发给您独立验证码，请注意查收，收到后通过微信反馈给下方的小助手即可）一期新增的几位用户（蓝色体）请注意，请添加小助手微信号并反馈盖楼时填写的微信号，请注意，是一期体验反馈盖楼时填写的微信号~反馈给小助手微信little-one-1806 即可反馈格式为：我在微服务实战中获得了一期抽奖资格，华为云账号：hw89000；盖楼反馈微信：ServiceStage029月29日下班前未反馈视为放弃抽奖资格序号一期深度体验用户账号1lyz06992JaneConan3bruce204hw091246985hw721308106cnfox02737zhanghui_china8yzq189415961819hw8488216110hw115976803911hw5245346812wuliangcheng13DouDou_14user_beifeng15Lionel_pang16khg30538754317vaza123456789y18hw8799184819hw19982217二期深度体验的用户名单出炉啦！以下用户请添加小助手微信号并反馈盖楼时填写的微信号，请注意，是二期体验反馈盖楼时填写的微信号~反馈给小助手微信little-one-1806 即可反馈格式为：我在微服务实战中获得了二期抽奖资格，华为云账号：hw89000；盖楼反馈微信：ServiceStage029月29日下班前未反馈视为放弃抽奖资格序号二期深度体验用户账号1hw199822172bruce203hw848821614wuliangcheng5hw721308106khg3053875437Lionel_pang8zhanghui_china9JaneConan10lyz069911DouDou_12hw0912469813cnfox027314zhenyuxu一期二期深度体验抽奖时间：9月30日上午10点整，请符合抽奖资格小伙伴快进抽奖群啊！添加小助手微信：little-one-1806 或 扫下方二维码 进群了解更多微服务信息，码豆发放、奖品抽奖和每期活动开启，小助手会在群里pick大家哦~活动首页戳微服务全生命周期实战体验

【微服务实战第一期】《一键部署体验云上微服务应用》火热进行中，保姆级教程让你玩转应用一键上云，体验应用托管DevOps全流程！参与任务赢2000+码豆换好礼！ 还有超多千元豪礼等你抱回家！加小助手微信：little-one-1806进群还能pick更多奖品攻略哦~动动手指赢码豆，保姆级教程开始啦~  首先领取代金券，并创建VPC + CCE集群 + ELB具体创建方法可以参考创建VPC/CCE集群和ELB然后单击体验链接并登录后，进入如下界面： 选择“体验中心”，单击立即体验选择“基于已有资源创建环境”，设置环境名称为“env-test01”。选择之前创建的集群和公网ELB，单击立即部署即可。示例如下： 在应用部署完成这一步截图并单击完成，结束体验。截图注意一起截取用户名。 温馨提示：单击立即部署没有反应的童鞋可以试试这个操作哦~https://bbs.huaweicloud.com/forum/thread-75601-1-1.html完成后，截图并在本帖盖楼回复上传体验截图；前400名符合要求的截图即可算作体验成功，获得1000码豆！码豆和实物奖励会在体验活动结束后15个工作日内发放，请注意查收哦~请务必按照以下格式要求进行回帖打卡，否则无法计算奖励：华为云账号名：XXX（即右上角的字母数字组合ID）微信昵称：XXX课程学习心得/实战问题反馈/课程建议：打卡样例图：打卡完成后还可通过应用入口访问天气预报应用操作完成后请记得一定要删除资源！操作完成后请记得一定要删除资源！操作完成后请记得一定要删除资源！删除资源指导：https://bbs.huaweicloud.com/forum/thread-75608-1-1.html

什么是微服务?微服务是一种软件系统结构类型,复杂的应用程序由许多微小并且相互独立的服务组成:这些服务相互之间通过与语言无关的API通信;这些服务是微小的,高度松耦合,并且只关注在一个小的任务;便于系统构建的模块化方法;服务是自治并且完整的,控制所有组件,包括UI、中间件、存取和事务。微服务和容器的关系本质上微服务和容器没有什么直接关系微服务理念出现的比容器技术要早很多,其理念是在70年代提出的容器技术是2013年才提出的微服务是应用软件架构设计模式,推崇单一职责、服务自治,、轻量通信和接口明确等原则,基于此,容器可以比较好的配合使微服务易于开发和维护、按需伸缩:(1)按照微服务的理念,如果使用容器作为基础设施,能够实现快速部署,快速迭代;(2)在云计算浪潮中，容器作为替代VM的基础设施受到大家的关注度更高;(3)k8s作为几乎实际默认的容器化平台标准,其集成了配置中心和注册中心,相当于天然的帮微服务架构解决了自己开发配置中心和注册中心的问题。微服务架构的特点是开打系统的边界,接口公开化,接口服务化。在IT系统中产品的概念比较模糊, 比如阿里云中有大量的应用,只有服务存在和服务间功能相互依赖引用，这里与5G明确的产品边界特点上存在差异。在后续的产品设计中会发现该差异很影响系统的实现,从结果看5G的微服务和IT的微服务味道上有差异。

云社区 博客 博客详情spring cloud 2.0 概述 【摘要】 传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的微服务架构演变过程传统单体架构 =》 分布式架构 =》 soa面向服务架构 =》 微服务架构传统单体架构传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的cn.itycu.controler ---springmvc 视图层 jsp/ftl cn.itycu.service ---业务逻辑层 cn.itycu.dao ---数据库访问层 将所有的代码都放入到同一个项目中，部署在同一个tomcat中该架构模式存在的优缺点优点：开发简单、运维简单缺点：该架构模式没有对业务逻辑进行拆分，这样子耦合度非常高，只适合小团队或者个人形式开发，不适合团队模式协同工作开发，维护性很难，如果系统中某个模块出现问题，会导致整个系统无法使用。应用场景：政府项目、管理系统、crm、oa，适合于小团队或个人进行开发分布式架构分布式架构模式基于传统的架构模式演变过来，将我们传统的单点系统实现根据业务拆分。会拆分为会员系统、订单系统、支付系统、秒杀系统等。从而降低整个项目的耦合度，这种架构模式开始慢慢适合于互联网公司开发。会员系统 memner.itycu.cn 支付系统 pay.itycu.cn 项目命名为系统意味：包含视图层和服务层soa面向服务架构sso单点登录系统，抽离出通用服务soa面向服务架构基于分布式架构模式演变过来，俗称服务化，也就是面向于服务与接口开发（服务开发），将共同存在的业务逻辑抽取成一个公共服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。服务：只是有接口、没有视图层cn.itycu.service cn.itycu.dao能够解决我们的代码冗余性问题soa架构模式特点传统政府、银行项目还是保留的在使用webservicewebservice架构模式wsdl组件表示接口信息、方法、调用地址、参数soa架构模式传输协议采用soap协议（HTTP/https+xml）实现传输，在高并发情况下实现通讯协议存在大量的冗余性传输，而且非常占用带宽。所以后来微服务架构中使用json替代了xml。soa架构模式实现方案webservice或者esb企业服务总线，底层采用soap传输协议。soa架构模式存在缺点前后端分离就是对我们控制层和业务逻辑实现区分，前端控制可以采用vue调用我们后端接口（http+json）采用soap协议实现通讯，xml传输非常重，效率比较低。服务化管理和治理设施不够完善依赖于中心服务发现机制不适合前后端分离架构模式微服务架构微服务架构模式基于soa架构模式演变过来的，比soa架构迷失对服务拆分力度会更加精细，采用前后端分离模式让专业的人做专业的事（专注），目的可以实现高效率开发。微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧，轻量级、适合于互联网公司开发模式。服务与服务之间通讯的协议采用restful形式，数据交换格式采用http+json格式实现传输整个过程中，采用二进制，所以http协议可以实现跨语言的平台，并且和其他语言实现通讯，所以为什么开放都是采用http+json格式传输SOA架构与微服务架构有哪些区别微服务架构模式比soa架构模式，更加适合于互联网公司敏捷、高效、快速迭代版本开发，因为力度非常精细。微服务架构模式比soa架构模式拆分力度更加精细，提倡让专业的人做专业的事，目的是实现高效的开发，每个服务与服务之间互不影响，每个服务都是单独独立数据库、redis连接、MQ等。并且都是实现独立部署，整个微服务架构更加轻量级。在soa架构中，有可能纯在多个服务共享同一个数据库，但是微服务架构必须强调每个都是独立数据库部署，互不影响。微服务架构基于soa架构模式演变过来，继承了soa架构的优点，在微服务架构中去除soa架构中soap协议和esp企业服务总线。改为http+json形式传输我们的数据。esb企业服务总线解决多系统间跨语言无法实现通讯的问题，对我们的数据实现转换，可以提供可靠的消息传输。一般情况我们采用http+json传输数据，不需要esb对数据进行转换。通讯协议服务拆分力度迭代微服务架构中可能会存在哪些问题分布式事务解决方案（rabbitmq、rocketmq事务消息、lcn（淘汰）、setata）最终一级概念分布式任务调度平台（xxl-job、elastic-job）分布式服务注册与发现（eureka、consul、zookeeper、nacos）分布式日志采集系统elk+kafka分布式服务最综与调用链系统zipkin分布式服务配置中心（spring cloud config/携程阿波罗/nacos/disconfig）微服务架构中有个非常重要的概念：独立部署、可配置、动态化。为什么要使用到spring cloudspring cloud 并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。理念就是***服务解决我们在微服务架构中遇到的问题。服务治理：eureka分布式配置：config客户端调用工具：rest/feign客户 rpc远程调用说明：阿里巴巴、腾讯、百度注意：大家如果去一些比较大型的互联网公司中，整个公司内部实现rpc通讯的框架、服务帮助治理都是内部自己研发。rpc远程调用框架：HTTPclent、dubbo、feign、grpc、基于netty手写rpcspring cloud一代和二代的区别spring cloud第一代实际上采用Netflix开源的组件整合微服务解决方案。spring cloud第二代实际上就是自己研发和国内的优秀的服务解决微服务框架进行组合。nacos实现服务注册于发现微服务服务治理核心概念Nacos产生背景rpc远程调用框架：HTTP client、grpc、dubbo、rest、openfeign等。传统rpc远程调用中存在哪些问题？超时、安全、服务与服务之间的url地址管理在我们的微服务架构通讯中，服务间依赖非常大，如果使用传统方式管理我们的服务，非常麻烦，所以采用url治理技术，可以实现我们整个实现动态服务注册与发现、本地负载均衡、容错等nacos分布式注册与发现功能 | 分布式配置中心产生于rpc远程调用中，服务的url的治理传统服务注册中心的实现方式把每个服务器的地址信息和端口号人工存放到数据库表中IdserviceIP端口号1itycu.cn192.168.1.180802itycu.cn192.168.1.18000维护成本高没有实现动态自动化基于数据库形式实现服务url治理的缺点分布式注册中心实现原理注册中心的作用管理整个微服务url地址可以实现动态感知注册中心：duboo依赖zookeeper、eureka、consul、nacos、redis、数据库nacos与eureka的区别eureka与zookeeper的区别注册中心的原理keyIP端口号服务名称192.168.1.18080生产者启动时，根据这种存储方式注册到微服务注册中心根据以上存储方式的服务名称获取到IP地址和端口号获取到地址后在本地实现rpc远程调用生产者：提供我们接口被其他服务调用消费者：调用接口实现服务服务注册：提供服务接口地址信息存放Naxos基本介绍实现注册中心和分布式配置中心默认账号密码：nacos使用命令模式实现对nacos的注册使用discovertyClient从注册中心获取接口地址使用rest Template实现rpc远程调用纯手写本地负载均衡轮询算法实现线下服务动态感知

微服务架构演变过程传统单体架构 =》 分布式架构 =》 soa面向服务架构 =》 微服务架构传统单体架构传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的cn.itycu.controler ---springmvc 视图层 jsp/ftl cn.itycu.service ---业务逻辑层 cn.itycu.dao ---数据库访问层 将所有的代码都放入到同一个项目中，部署在同一个tomcat中该架构模式存在的优缺点优点：开发简单、运维简单缺点：该架构模式没有对业务逻辑进行拆分，这样子耦合度非常高，只适合小团队或者个人形式开发，不适合团队模式协同工作开发，维护性很难，如果系统中某个模块出现问题，会导致整个系统无法使用。应用场景：政府项目、管理系统、crm、oa，适合于小团队或个人进行开发分布式架构分布式架构模式基于传统的架构模式演变过来，将我们传统的单点系统实现根据业务拆分。会拆分为会员系统、订单系统、支付系统、秒杀系统等。从而降低整个项目的耦合度，这种架构模式开始慢慢适合于互联网公司开发。会员系统 memner.itycu.cn 支付系统 pay.itycu.cn 项目命名为系统意味：包含视图层和服务层soa面向服务架构sso单点登录系统，抽离出通用服务soa面向服务架构基于分布式架构模式演变过来，俗称服务化，也就是面向于服务与接口开发（服务开发），将共同存在的业务逻辑抽取成一个公共服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。服务：只是有接口、没有视图层cn.itycu.service cn.itycu.dao能够解决我们的代码冗余性问题soa架构模式特点传统政府、银行项目还是保留的在使用webservicewebservice架构模式wsdl组件表示接口信息、方法、调用地址、参数soa架构模式传输协议采用soap协议（HTTP/https+xml）实现传输，在高并发情况下实现通讯协议存在大量的冗余性传输，而且非常占用带宽。所以后来微服务架构中使用json替代了xml。soa架构模式实现方案webservice或者esb企业服务总线，底层采用soap传输协议。soa架构模式存在缺点前后端分离就是对我们控制层和业务逻辑实现区分，前端控制可以采用vue调用我们后端接口（http+json）采用soap协议实现通讯，xml传输非常重，效率比较低。服务化管理和治理设施不够完善依赖于中心服务发现机制不适合前后端分离架构模式微服务架构微服务架构模式基于soa架构模式演变过来的，比soa架构迷失对服务拆分力度会更加精细，采用前后端分离模式让专业的人做专业的事（专注），目的可以实现高效率开发。微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧，轻量级、适合于互联网公司开发模式。服务与服务之间通讯的协议采用restful形式，数据交换格式采用http+json格式实现传输整个过程中，采用二进制，所以http协议可以实现跨语言的平台，并且和其他语言实现通讯，所以为什么开放都是采用http+json格式传输SOA架构与微服务架构有哪些区别微服务架构模式比soa架构模式，更加适合于互联网公司敏捷、高效、快速迭代版本开发，因为力度非常精细。微服务架构模式比soa架构模式拆分力度更加精细，提倡让专业的人做专业的事，目的是实现高效的开发，每个服务与服务之间互不影响，每个服务都是单独独立数据库、redis连接、MQ等。并且都是实现独立部署，整个微服务架构更加轻量级。在soa架构中，有可能纯在多个服务共享同一个数据库，但是微服务架构必须强调每个都是独立数据库部署，互不影响。微服务架构基于soa架构模式演变过来，继承了soa架构的优点，在微服务架构中去除soa架构中soap协议和esp企业服务总线。改为http+json形式传输我们的数据。esb企业服务总线解决多系统间跨语言无法实现通讯的问题，对我们的数据实现转换，可以提供可靠的消息传输。一般情况我们采用http+json传输数据，不需要esb对数据进行转换。通讯协议服务拆分力度迭代微服务架构中可能会存在哪些问题分布式事务解决方案（rabbitmq、rocketmq事务消息、lcn（淘汰）、setata）最终一级概念分布式任务调度平台（xxl-job、elastic-job）分布式服务注册与发现（eureka、consul、zookeeper、nacos）分布式日志采集系统elk+kafka分布式服务最综与调用链系统zipkin分布式服务配置中心（spring cloud config/携程阿波罗/nacos/disconfig）微服务架构中有个非常重要的概念：独立部署、可配置、动态化。为什么要使用到spring cloudspring cloud 并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。理念就是***服务解决我们在微服务架构中遇到的问题。服务治理：eureka分布式配置：config客户端调用工具：rest/feign客户 rpc远程调用说明：阿里巴巴、腾讯、百度注意：大家如果去一些比较大型的互联网公司中，整个公司内部实现rpc通讯的框架、服务帮助治理都是内部自己研发。rpc远程调用框架：HTTPclent、dubbo、feign、grpc、基于netty手写rpcspring cloud一代和二代的区别spring cloud第一代实际上采用Netflix开源的组件整合微服务解决方案。spring cloud第二代实际上就是自己研发和国内的优秀的服务解决微服务框架进行组合。nacos实现服务注册于发现微服务服务治理核心概念Nacos产生背景rpc远程调用框架：HTTP client、grpc、dubbo、rest、openfeign等。传统rpc远程调用中存在哪些问题？超时、安全、服务与服务之间的url地址管理在我们的微服务架构通讯中，服务间依赖非常大，如果使用传统方式管理我们的服务，非常麻烦，所以采用url治理技术，可以实现我们整个实现动态服务注册与发现、本地负载均衡、容错等nacos分布式注册与发现功能 | 分布式配置中心产生于rpc远程调用中，服务的url的治理传统服务注册中心的实现方式把每个服务器的地址信息和端口号人工存放到数据库表中IdserviceIP端口号1itycu.cn192.168.1.180802itycu.cn192.168.1.18000维护成本高没有实现动态自动化基于数据库形式实现服务url治理的缺点分布式注册中心实现原理注册中心的作用管理整个微服务url地址可以实现动态感知注册中心：duboo依赖zookeeper、eureka、consul、nacos、redis、数据库nacos与eureka的区别eureka与zookeeper的区别注册中心的原理keyIP端口号服务名称192.168.1.18080生产者启动时，根据这种存储方式注册到微服务注册中心根据以上存储方式的服务名称获取到IP地址和端口号获取到地址后在本地实现rpc远程调用生产者：提供我们接口被其他服务调用消费者：调用接口实现服务服务注册：提供服务接口地址信息存放Naxos基本介绍实现注册中心和分布式配置中心默认账号密码：nacos使用命令模式实现对nacos的注册使用discovertyClient从注册中心获取接口地址使用rest Template实现rpc远程调用纯手写本地负载均衡轮询算法实现线下服务动态感知

DevOps,是Development和Operations的组合词,是指一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。DevOps是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。DevOps:企业迈向敏捷之钥DevOps的出现,源于在传统模式下的开发和运维组织上的分离造成的管理混乱,开发要不断的迭代新版本上线新功能,但是运维关注的是稳定,这两种需求实际上是矛盾的。但DevOps旨在打破这道混乱之墙,让开发、运维、测试协同作战,提高研发效率,实现高效交付,解决传统模式下的运维之痛。而事实证明,DevOps确实能够较好的解决开发和运维之间的混乱问题,提升研发效率,实现高效交付。在近期中国信通院(CAICT)发布的《中国DevOps现状调查报告(2019年)》(以下简称报告)中,超八成企业表示,通过采用DevOps中的核心工程实践——持续交付——获得了研发效率的显著提升。同时调查发现,具备清晰、明确变更管理系统的组织,平均变更前置时间(即从代码被成功提交到成功运行在生产环境平均需要的时间),即通常意义上的交付时间也相对较短。正是因为DevOps能够给企业带来的诸多益处,目前,DevOps已经成为企业软件研发的主流,被众多企业所采用。报告显示,超半数企业使用DevOps的敏捷工程实践管理开发项目,近6成企业选择编码规范、单元测试和持续集成。                                              DevOps:想说爱你不容易然而,虽然众多企业都期望DevOps能够给它们带来更高效的交付效率,提升客户满意度,创造更多的商业价值,但成功实践DevOps依然是一个难题。在报告中,实际能够真正成功实施DevOps的企业仅有31.65%,另外,还有接近四成(41.13%)的企业居然不清楚自己是否成功实施DevOps,这不得不说是一个令人感到意外的结果。而当我们认真研究当前中国企业的DevOps现状时,就会明白这个结果也在情理之中。当前,虽然国内应用DevOps的众多,DevOps已经在国内逐步落地实践,但大部分企业仍然位于DevOps能力成熟度初始级和基础级,其比例高达7成。而在DevOps的细分领域,例如DevOps的敏捷开发管理成熟度方面,同样是近七成企业仍然处在基础级和全面级,仅有1.83%的企业处于卓越级。而且虽然大多数企业企业普遍采取了敏捷开发方法以提升研发效率,但敏捷开发技术普及率有待提升,研发管理流程严谨性不足。同样,在应用设计方面和安全风险管理方面,多数企业也是位于初始级和基础级。同时,在持续交付方面,企业的自动化测试整体覆盖率普遍偏低;在技术运营方面,企业整体运营能力有待提高,缺乏对潜在风险的管理。再加上企业中有近7成的的研发人员DevOps经验少于1年,在这样的情况下,得到上述的调查结果也就不足为奇了。总之,从报告来看,目前国内大多数企业的DevOps应用还是处在初始级和基础级的阶段,需要向全面级、优秀级、卓越级转变。DevOps:工具技术如何选而要实现企业DevOps从初始级、基础级向全面级、优秀级、卓越级转变,除了企业要增强对于DevOps的重视度之外,选择合适的DevOps工具和技术就显得至关重要了。而从报告中显示,近九成的企业会选择云来助力DevOps实践落地,这是因为,DevOps就是在开发和部署周期中设计开发人员需要的环境的自动化,以最大限度地减少开发人员的等待时间,并允许开发人员在代码基础上获得更多的迭代。考虑到这些环境一直处于变化状态,因此,DevOps是基于云计算的天然盟友,在云计算的支撑下企业能够立即启动支持开发和部署过程中涉及的各种环境所需的资源以实施DevOps。同时,在易用性、可伸缩性和性能方面有着卓越表现的微服务,成为了企业软件开发最受欢迎的架构,而微服务和DevOps有着非常密切的联系。微服务在具有众多优势外也带来了实施上的复杂性,整个系统由单一应用拆分为多个服务,微服务之间存在较强的依赖关系,服务之间如何协作如何处理就变得非常复杂。由于微服务是一个网状分布的,有很多服务需要维护和管理,对它进行部署维护和监控管理的时候就比较复杂。因此使用微服务,第一步是要构建一个一体化的DevOps平台。DevOps包含了持续集成与持续发布,服务依赖关系管理,服务的发现与负载均衡,以及集中化监控管理,这些都是微服务生态系统所必不可少的工具和实践。而近几年火热的容器技术也被誉为是DevOps的天作之合,它的出现使DevOps落地实践相对容易,而保持跨环境的一致性和灵活的可移植性是企业选择容器的主要因素。这些调查结果表明,大多数企业在DevOps实践过程中,基于云计算、微服务、容器给企业带来的诸多益处,都会选择云+微服务+容器的方式来具体落地DevOps。而在具体的工具选择上,国外厂商的产品仍然占据大半江山,JIRA在需求和项目管理领域拔得头筹、Gitlab位居代码管理首位。一体化DevOps:DevOps的潜力股虽然国外老牌传统工具JIRA仍然以52.13%的市占率高居DevOps工具选择之首,但与云结合的DevOps工具的发展势头良好,国内厂商也在其中占据了一席之地,特别是在软件开发一体化管理领域,排名前两位的分别是国内公有云大厂华为云DevCloud与阿里云效,分别占据16.46%与10.98%的市场份额。尽管从整体上来看,软件开发一体化的DevOps平台目前在市场中的占有率仍然偏低,但从未来发展的趋势来看,与云结合的一体化DevOps将是未来DevOps平台发展的一个重要方向,这从报告中的企业广泛选择云以及与云计算有着紧密联系的微服务架构和容器可以得到很好地佐证。而在这个领域,之所以中国厂商能够占据领先的地位,和两家厂商在中国公有云市场的强势发展是分不开的。特别是华为云DevOps之所以能够成为报告中唯一占据一个首位的DevOps工具,首先应该得益于华为30多年软件研发的沉淀,这些在多年软件研发中积累的丰富经验,使得华为深知开发者到底需要怎样的DevOps工具,在这样的理念上推出的DevCloud,受到企业和开发者的青睐,自然就是水到渠成的事情了。其次,华为云DevCloud针对需求变动频繁、开发测试环境复杂、多版本分支维护困难、无法有效监控进度和质量等开发者研发中的普遍痛点,使开发人员实现软件研发过程可视、可控、可度量,还可以实现一键式部署,解决开发者在应用部署方面的挑战。而云端代码检查、自动化测试管理和APP测试功能,能够显著避免代码出错情况的发生,分布式代码托管功能更是为开发者的代码提供了一个可靠的“家园”。第三,华为云DevCloud不仅对外服务,其本身就孵化于华为内部的软件研发能力中心,至今还在为内部所有软件研发人员服务,在可用、可靠、安全性方面都经过了实践应用的检验。这些优点汇聚起来,得到这样的结果也就在情理之中了。DevOps:未来谁领风骚实际上,从本质上讲,DevOps 不只是一种技术或方案,它更多的是文化,它重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作,以提高整个软件开发生命周期的效率以及质量。因此,谁拥有更多的开发者,谁更加了解开发者,谁就能更加准确的掌握开发者的需求,引领软件工程能力的趋势,也能做出更加接地气的产品,谁更新迭代的速度更快,谁就越有可能在未来的长跑中获胜。虽然从此次调查结果来看,国外厂商的DevOps产品仍然处于领先地位,但我们相信,在以华为云为代表的国内厂商的共同努力下,我国的软件工程能力将会得到显著的提升,我国的DevOps产品的能力也会得到迅速的提高,从而帮助中国企业落地DevOps,推动中国企业从DevOps的初始级和基础级的阶段,向全面级、优秀级、卓越级转变,全方位的促进国内软件产业发展,打造软件产业发展新模式,推动中国软件产业不断向前发展。重磅活动推荐:2019华为全联接大会万众瞩目的2019华为全联接大会即将在今年9月18日-9月20日上海世博中心举办,在这里你可以在业界大咖牛人的演讲中学习,在与名企零距离交流中收获,更能现场围观各个开发者大赛的竞技PK。目前,华为全联接大会的限量早鸟票现已开售,早鸟票价低至150元,学生更是享受惊爆价99元。搜索“DevCloud”,点击进入华为云DevCloud官网,在最新活动中点击“华为HC大会开发者专场门票热销中”,进入购票通道,尊享HC大会早鸟票,数量有限,先到先得。来源：消费日报网 

特性描述概述● EdgeGallery开源平台，包括为用户提供MEP开发者平台（MEP Developer Portal）， MEP平台（MEP Platform），MEP应用商店（MEP Application Store），MEP管理（MEP Manager）。● EdgeGallery提供开源端到端的MEC解决方案，系统采用微服务的设计思想，各个微服务之间通过HTTP进行通信，基于Kuberenetes，所有服务已经实现容器化。● EdgeGallery向第三方APP或厂商提供开放的接口，旨在最大程度帮助应用上车。● EdgeGallery提供了统一的Web Portal和一致的Web运维体验。

转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作，但说他“首次提出云原生（CloudNative）的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生，详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务，但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步，各方面都不成熟，Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能，最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起，共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的，它的“Netflix OOS”系列工具至今仍被广泛使用，特别是Java社区，并被移植到其他语言。在这个过程中，也同时开创了云计算的先河，它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算（Cloud）和云原生（Cloud Native）还是有很大区别的。Netflix是云计算的开拓者，但并不是云原生的创造者。云原生的基石是k8s，没有k8s就没有云原生， 而k8s的1.0版诞生于2015年。云原生计算基金会（CNCF）也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行，因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会（CNCF）的定义：下面就让我们看一下CNCF给出的云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”摘要来源：CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，**圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。云技术的三大基石：基础设施即代码 (Infrastructure As Code）基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施（immutable infrastructure）说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API（declarative APIs）声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣，请参见把应用程序迁移到k8s需要修改什么？云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具，请继续阅读下一篇“ 云原生开发环境初探"。索引：Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么？云原生开发环境初探不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考

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

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

转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作，但说他“首次提出云原生（CloudNative）的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生，详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务，但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步，各方面都不成熟，Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能，最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起，共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的，它的“Netflix OOS”系列工具至今仍被广泛使用，特别是Java社区，并被移植到其他语言。在这个过程中，也同时开创了云计算的先河，它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算（Cloud）和云原生（Cloud Native）还是有很大区别的。Netflix是云计算的开拓者，但并不是云原生的创造者。云原生的基石是k8s，没有k8s就没有云原生， 而k8s的1.0版诞生于2015年。云原生计算基金会（CNCF）也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行，因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会（CNCF）的定义：下面就让我们看一下CNCF给出的云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”摘要来源：CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，**圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。云技术的三大基石：基础设施即代码 (Infrastructure As Code）基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施（immutable infrastructure）说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API（declarative APIs）声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣，请参见把应用程序迁移到k8s需要修改什么？云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具，请继续阅读下一篇“ 云原生开发环境初探"。索引：Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么？云原生开发环境初探不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考