【微服务实战第一期】《一键部署体验云上微服务应用》火热进行中，保姆级教程让你玩转应用一键上云，体验应用托管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需要修改什么？云原生开发环境初探不堆砌术语，不罗列架构，不迷信权威，不盲从流行，坚持独立思考

【中奖名单公布】 满分彩蛋奖：奖品：大狮双肩包请获奖小伙伴及时（8.31前）私信版主提供邮寄信息直播互动幸运奖奖品:大狮PVC包请获奖小伙伴及时（8.31前）私信版主提供邮寄信息ServiceStage体验幸运奖奖品：50元京东电子购物卡请中奖小伙伴及时私信版主领取奖励【活动时间】2020年7月27日-2020年8月7日【直播及回看链接】2020年7月29日20:00-21:00http://live.vhall.com/850574407【直播简介】DevRun开发者沙龙直播间7月29日20:00，华为云高级产品经理带你揭秘华为云DevCloud的微服务高效开发和创新方法，了解通过ServiceStage实现微服务的灰度发布、负载均衡、限流降级、熔断容错、错误注入、调用链分析等自动化治理能力，干货满满，不容错过！！！参与直播互动100%中奖，更有机会领取京东电子购物卡，还有更多开发者钟爱礼品等你来拿哦~~报名请戳：https://bbs.huaweicloud.com/signup/c6b7b8876b59499dac47c9005fbc397e【赢奖攻略及规则】         1.直播期间打开直播间下方“调查问卷”菜单栏，扫二维码参与华为云问卷调查，抽取京东电子购物卡、大狮棒球帽、大狮萌萌哒玩偶、大狮PVC包、大狮运动袜等多重好礼，前200参与开发者，100%中奖！        【直播报名链接】：https://bbs.huaweicloud.com/signup/c6b7b8876b59499dac47c9005fbc397e         2.直播期间在直播间评论区发表 评论，就有机会获取大师双肩包*5+大狮棒球帽*5+京东电子购物卡*8         3.活动期间（7.27~8.7）参与论坛互动赢取更多好礼【礼品展示】论坛互动规则介绍【互动参与方式】（可参考以下内容任选一个或多个进行回帖）1.  回复本帖发表直播观后感+直播或回放截图/向专家提问2.  回帖参与互动问答互动问题       问题一：DevOps诞生之初要解决的问题是什么        A.让产品研发更快，让用户更快体验到需求实现出来的功能，并及时给出反馈        B.解决软件开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通         C.开发出更多工具，使软件开发更容易         D.让开发搞定大部分工作，不需要专门的测试和运维    问题二：微服务的挑战有哪些         A.人员与组织需按微服务进行变革         B.微服务的设计与架构需要重点看护         C.要保障好微服务的开发能效         D.微服务的发布升级需要更加谨慎    问题三：华为云提供的DevOps和微服务的产品是         A.DevCloud、CCE         B.IAM、CCE        C.DevCloud、ServiceStage         D.DevCloud、AOM3.  通过以下链接体验华为云ServiceStage，并回帖上传体验截图体验链接：https://lab.huaweicloud.com/testdetail.html?testId=412【奖励及规则】1.  满分彩蛋奖数量：3奖品：价值200元，大狮双肩包评奖规则：活动结束后，从参与互动问题回答，并且答题正确的回帖里随机抽取3名小伙伴。2.  直播互动幸运数量：10奖品：价值50元，大狮PVC包评奖规则：活动结束后，活动结束后在复本帖发表直播观后感+直播或回放截图/向专家提问的小伙伴中随机抽取10名小伙伴，获大狮PVC包3. ServiceStage体验幸运奖数量：8奖品：50元京东电子购物卡评奖规则：参与华为云ServiceStage体验，活动结束后在体验完成的小伙伴中抽取8名幸运体验者，获50元京东电子购物卡奖品发放说明：每位参加活动的用户理解并同意，为联系获奖用户以及奖品发放的需要，用户须在参与活动之时提供诸如姓名、联系方式、电子邮箱、通讯地址等真实个人信息，活动主办方将仅为前述目的以及适用法律规定的最小限度内收集和使用用户的个人信息,本次活动所收集的个人信息将在活动结束后删除。（用户在向华为云提交个人信息之前，应阅读、了解华为云《隐私政策声明》；用户参加本活动视为理解并同意华为云《隐私政策声明》，华为云《隐私政策声明》网页地址如下：https://www.huaweicloud.com/declaration/sa_prp.html）。获奖用户在领奖界面填写获奖信息，活动结束且用户填写完整领奖信息后15个工作日内，将统一发出奖品，所有实物奖品包邮，不额外收取任何费用。由于获奖用户自身原因（包括但不限于提供的联系方式有误、华为云账号有误、身份不符或者通知领奖后超过30天未领取、未填写相关信息等）造成奖品无法发送的，视为获奖用户放弃领奖。为保证活动的公平公正，华为云有权对恶意刷活动资源（“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为），利用资源从事违法违规行为的用户收回抽奖及奖励资格。本活动规则由华为云在法律规定范围内进行解释。华为云保留不时更新、修改或删除本活动规则的权利。所有参加本活动的用户，均视为认可并同意遵守《华为云用户协议》，包括以援引方式纳入《华为云用户协议》的《可接受的使用政策》、《法律声明》、《隐私政策声明》、相关服务等级协议（SLA），以及华为云服务网站规定的其他协议和政策（统称为“云服务协议”）的约束。云服务协议链接的网址：http://www.huaweicloud.com/declaration/sa_cua.html*因为回帖内容中包含华为云账号，出于对大家个人信息保密的原则，回帖内容已设置为仅作者可见。如有其他问题，请联系微信小助手

一、微服务架构实施的前提如图，Martin Fowler结石的生产率和复复杂度的关系。可以看出：1.当复杂度较小时，采用单块系统的生产率更高，微服务架构反而可能降低生产率。2.当复杂度达到一定规模时，无论单块系统还是微服务架构都会降低生产率，但是单块系统会面临急剧下降的情况，而微服务架构相对平稳。3.我们发现有一个明显的拐点存在，但是并没有量化这个拐点的具体大小，也就是说系统或代码的规模达到具体多大适合进行微服务的拆分，这个需要各个团队因地制宜。4.只有当出现这个拐点时对系统进行微服务化的拆分才是合适的方案，服务的合理拆分是实施微服务架构的一大前提。5.微服务的实施需要基础设施自动化，这和服务规模有关，从开发之后的构建、测试、部署都需要高度自动化的环境来支撑才能有效降低边际成本。二、微服务实施的三大模式1.典型模式：从一个单块系统开始逐步转变到多个维度的微服务架构。2.从无到有的实施，但是小系统没有必要直接采用微服务架构。3.混合式，微服务架构很容易与现有系统并存，微服务与遗留系统的易整合性也是采用微服务的一个主要原因。三、实施微服务架构的优势基本优势可如图分析：                    实际例子举例，如图：            （一）、六大技术优势1.组件化方案：高内聚，低耦合；2.技术自由度：每个微服务高度独立，可以采用适合自身开发团队和技术体系的工具和框架来实现某个微服务；3.可扩展性：单个微服务在保证通信方式不变的情况下，对其内部功能和技术的改变不会对外部依赖它的服务产生任何影响；4.可伸缩性：注意可以伸缩的前提是对系统有合理的划分，高扩展往往能够带来高可伸缩性；5.有效应对遗留系统：微服务时改造遗留系统的强有力武器，只要可以获得遗留系统的暴露接口，微服务架构就能与之进行通信并完成功能整合。6.持续可交付：简单、可重复流程确保软件发布过程的可靠性。（二）、业务与组织优势康威定律，组织形式等同于系统设计，直白的说就是，你想要什么样的系统就搭建什么样的团队。举例：原有的功能团队-----------------微服务架构的自治性组织文化（大系统变为小系统、小产品）1.消除过程浪费可采用产品开发周期与成本之间的关系开分析：明确的边界有助于减少团队之间的扯皮现象，提升开发效率。2.快速产品开发通过技术创新缩短同行产品开发周期，具体分析如图：四、实施微服务面临的挑战（一）、技术架构的挑战1.去中心化与平衡：去中心化的思想意味着微服务之间不需要共享技术，然而缺少通用技术体系同样会加剧系统的复杂度，当从统一发布和运维等角度去看待整体系统时，这种技术复杂度可能会是一个问题，需要进行平衡。2.服务版本控制：提倡为每个微服务建立版本并根据业务迭代更新版本，那么需要考虑在多版本更新频率很高时，应充分思考如何正确管理服务版本。（二）、研发过程的挑战1.需求的边界：如何确定业务功能的粒度、如何把非功能性需求分解到各个微服务中、如何从系统整体上把握需求的优先级等；2.引入变化：当微服务架构被引入时，依旧需要做很多事情，因为我们所提到的各种技术、架构和过程的挑战需要我们跟踪和协调。 参考书籍、文献和资料：【1】郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.【2】Sam Newman. 微服务设计[M]. 崔力强，张骏译. 北京：人民邮电出版社，2016.【3】 MartinLAbbott, MichaelT.Fisher. 架构即未来：现代企业可扩展的Web架构、流程和组织[M]. 陈斌译. 北京：机械工业出版社，2016.————————————————本文为CSDN博主「张彦峰ZYF」的原创文章原文链接：https://blog.csdn.net/xiaofeng10330111/java/article/details/85253477  

构建微服务架构的系统方法主要包括四个方面，具体内容如图所示。一、服务模型服务模型主要由两部分组成：服务建模方法+服务拆分和集成。建模要明确服务的类别以及服务与业务之间的关系，从而明确服务的概念模型并给出服务的统一变现形式，同时，也需要借助诸如领域驱动设计中的界限上下文和领域事件等技术合理划分微服务的边界，剥离微服务与数据之间的耦合。服务拆分需要考虑拆分的维度、策略并管理微服务之间的依赖关系、数据以及边界。服务的集成主要考虑在轻量级服务通信的要求下所应当采用的技术实现方式。这个放于后面具体博客中讲解。 二、实现技术构建微服务架构的重点部分就是对其实现技术的考量，微服务本身具有分布式架构的基本特征，在基础组件上要充分考虑服务通信+事件驱动+负载均衡+服务路由+API网关+配置管理等内容的实现，在关键要素上要落实服务治理+数据一致性+服务可靠性等重要方面，同时在实现技术上要充分利用Spring Boot、Spring Cloud等技术选型。这个放于后面具体博客中讲解。 三、基础设施作为微服务架构的管理体系，主要包括服务测试、服务交付与部署、服务监控和服务安全四个方面。这个放于后面具体博客中讲解。 四、研发过程主要涉及关于业务结构、组织架构和研发文化等方面的内容，具体开发团队整体研发过程主要包括微服务架构转型过程与方法+微服务架构与研发过程转变两部分。这个放于后面具体博客中讲解。 参考书籍、文献和资料：【1】郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.————————————————本文为CSDN博主「张彦峰ZYF」的原创文章原文链接：https://blog.csdn.net/xiaofeng10330111/java/article/details/85253412

一、微服务高内聚 + 交互决定低耦合  基本概念：大小决定二、微服务架构四大特点和三大切入点 三、微服务与现有架构体系的对比1.微服务架构与SOA2.微服务架构与ESB3.微服务架构对比SOA两者的主要差异如下：服务拆分粒度：SOA首先要解决的是异构系统应用的服务化；微服务强调的是服务拆分尽可能小，最好是独立的原子服务。服务依赖：传统的SOA服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是服务自治、功能单一独立，避免依赖其他服务产生耦合，耦合会带来更高的复杂度。服务规模：传统SOA服务粒度比较大，多数会采用将多个服务合并打成war包的方案，因此服务实例数比较有限；微服务强调尽可能拆分，同时很多服务会独立部署，这将导致服务规模急剧膨胀，对服务治理和运维带来新的挑战。架构差异：微服务化之后，服务数量的激增会引起架构质量属性的变化，例如企业集成总线ESB逐渐被P2P的虚拟总线替代；为了保证高性能、低时延，需要高性能的分布式服务框架保证微服务架构的实施。服务治理：传统基于SOA Governance的静态治理转型为服务运行态微治理、实时生效。敏捷交付：服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。总结：量变引起质变，这就是微服务架构和SOA服务化架构的最大差异。————————————————声明：本文为CSDN博主「张彦峰ZYF」的原创文章原文链接：https://blog.csdn.net/xiaofeng10330111/java/article/details/85253353

【摘要】 本文介绍了基于开源自建和适配云厂商开发框架两种构建多云架构的思路，以及这些思路的优缺点。微服务生态微服务生态本质上是一种微服务架构模式的实现，包括微服务开发SDK，以及微服务基础设施。目前比较成熟的 JAVA 微服务生态包括 servicecomb（华为）, spring-cloud (Pivotal), dubbo（阿里）, tsf（腾讯）等。gRPC、Thrift 等也用于内部服务之间的通信，但是微服务基础设施比较欠缺。核心的微服务基础设施包括：注册中心、配置中心、应用网关。此外，分布式事物管理、计划任务、调用链跟踪系统等也是微服务基础设施的组成部分。完整的微服务基础实施还包括开发使能工具，包括接口管理工具、灰度发布管理、代码生成等，这部分主要由云厂商提供，比较少开源方案。微服务生态的核心是 SDK，而 SDK 的核心是 RPC 框架，这个是不同微服务生态的本质区别。在基础设施方面，不同的微服务生态是可以相互选择的，比如 spring-cloud 生态可以采用 spring-cloud-huawei 接入servicecomb 提供的注册中心 servicecomb-service-center、配置中心 servicecomb-kie，也可以通过 spring-cloud-alibaba 接入阿里的配置中心；servicecomb 也可以通过引入扩展，使用其他的配置中心。一些基础的开发组件，比如 spring、spring boot，这些微服务开发 SDK 都支持集成。对微服务生态进行比较是一个很难的课题。下面的表格仅对一些核心功能进行比较。使能工具、核心基础设施、可选基础设施等方面，不同的微服务生态是可以相互使用的，这里的比较只针对该生态原生提供的来说，并不代表某个微服务生态缺少这块功能，该生态的开发者用不了这方面的能力。对于开源生态应该采用一个大生态的眼光来看待，每个生态的设计者也会尽可能融入其他生态，继承和复用其他生态的能力。但是在商业选型上，需要考虑技术支持等因素。对微服务生态的比较的另外一个视角就是如何构建微服务应用架构。 一般的微服务应用架构会包括应用网关、业务微服务和静态页面。静态页面的部署相对比较灵活，可以放到应用网关内部，也可以放到应用网关，还可以放到应用网关外面。其中放到网关里面的方式最灵活，比如可以通过配置网关的负载均衡策略，将请求转发到用户最近的region，也可以对部分静态页面进行访问控制。增加应用网关可以增强应用系统的弹性，能够支撑系统的持续演进（参考分析文章），同时可以结合网络基础设施，更好的实现应用系统的能力开放。比如如果接入层使用 API Gateway 挂载，可以很好的实现内部系统的能力开放和计费；使用LVS接入，只可以提高转发性能，比较适合访问量大的应用，接入网关逻辑少，应用网关可以弹性扩容；使用DNS则对于网站很有用，屏蔽用户访问的地址差异，并且可以使用DNS将请求转发到不同区域的应用网关。Servicecomb, spring-cloud 都能够很好的支持这种架构，而 dubbo 对这种架构支持的不是很好，很多 dubbo 开发者都是通过在业务服务之外增加一个接入层，使用 spring-cloud 的应用网关来搭建这个应用架构。多云微服务架构的两种方案采用开源微服务框架很多业务系统的构建，都是从选择一个开源方案开始。 一般会首先选择一个微服务开发 SDK， 然后选择其他的微服务基础设施。 对于自主研发的情况，微服务基础设施也会选择开源方案。 比如选择 ServiceComb 微服务开发 SDK 的场景，可以通过在不同的云上部署开源服务，来实现一套系统，多个云上运行。 云厂商如果存在微服务基础设施的商业版本， 可以在云上购买使用， 使用云产商提供的基础设施服务，通常可以降低自己运维的成本，并能够得到更好的性能优化和可靠性支持。另外一个开源解决方案是部分集成云产商提供的组件，尽可能多的使用云产商的基础设施。 比如选择 Spring Cloud 微服务解决方案， 可以使用 spring-cloud-huawei, spring-cloud-alibaba 等云产商提供的扩展，使用云上的基础设施。下面对开源解决方案的评估点做一个总结：1. 只需要维护一套代码和熟悉一个开发框架，多云运行。不同云的运行体验存在差异，可以部分使用云厂商的中间件。 如果其他云没有对应的中间件，需要自行安装和维护中间件。2. 微服务框架选型之前，需要考虑“基础设施”是否也开源。比如微服务基础设施最重要的中间件“配置中心”、“注册中心”和“应用网关”。开源可获得性是一套代码，多云运行的前提。适配多供应商开发框架每个云产商都存在一个主打的微服务开发框架， 使用主打微服务开发框架能够最好使用云产商提供的微服务基础设施。 为了在不同的云上， 获得最佳的微服务管理能力，需要尽可能使用对应云的主打框架。 但是维护多套代码是困难的。 适配多供应商的开发框架， 需要对核心业务做好分离，避免重复开发，然后将适配层做薄，只实现简单适配，降低开发难度。 大部分 JAVA 微服务开发框架都支持 Spring， 因此可以采用下面的设计模式，实现一套核心代码，编译成多个云产商开发框架的可执行程序的多云版本。上图是一个微服务的内部结构，一个微服务可能包含如下几个目录：* application-core* application-runtime-servicecomb* application-runtime-hsf下面对适配多供应商开发框架方案的评估点做一个总结：1. 需要做好业务抽象，并熟悉多个开源微服务开发框架，相对于开源自建方案维护成本高。2. 不需要考虑自行安装和维护基础中间件的问题，云厂商自己的微服务框架，一般针对这个框架提供了各种中间件支持，使用和接入开发成本低。3. 这种方案是优秀代码架构设计。在开源方案中，也建议做好核心业务逻辑分离和接口抽象，每个方案适配不同云厂商非微服务基础设施（比如数据库、对象存储、EI等功能）也都是需要的。转载自：华为云开发者论坛