SpringbootSpringcloud微服务架构
1.  什么是微服务？
  微服务是⼀种架构风格，⼀个⼤型复杂软件应⽤由⼀个或多个微服务组成。系统中的各个微服务之间是松耦合的，同时微服务之间，通常是采⽤轻量级的基于 HTTP 的RESTful API通信机制互相沟通，互相配合。每个服务都围绕着具体业务进⾏构建，并且能够被独⽴地部署到⽣产环境。
2.  微服务有什么特点？
(1).复杂度可控
在将应⽤分解的同时，规避了原本复杂度⽆⽌境的积累。每⼀个微服务专注于单⼀功能，并通过定义良好的接⼝清晰表述服务边界。由于体积⼩、复杂度低，每个微服务可由⼀个⼩规模开发团队完全掌控，易于保持⾼可维护性和开发效率。
(2).独⽴部署
独⽴部署由于微服务具备独⽴的运⾏进程，所以每个微服务也可以独⽴部署。当某个微服务发⽣变更时⽆需编译、部署整个应⽤。由微服务组成的应⽤相当于具备⼀系列可并⾏的发布流程，使得发布更加⾼效，同时降低对⽣产环境所造成的风险，最终缩短应⽤交付周期。
(3).技术选型灵活
微服务架构下，技术选型是去中⼼化的。每个团队可以根据⾃⾝服务的需求和⾏业发展的现状，⾃由选择最适合的技术栈。由于每个微服务相对简单，所以需要对技术栈进⾏升级时所⾯临的风险就较低，甚⾄完全重构⼀个微服务也是可⾏的。
(4).容错
当某⼀组件发⽣故障时，在单⼀进程的传统架构下，故障很有可能在进程内扩散，形成应⽤全局性的不可⽤。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应⽤层⾯的容错。
(5).扩展
单块架构应⽤也可以实现横向扩展，当应⽤的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独⽴进⾏扩展。
3. Spring Boot / Cloud 都做了那些事情?
(1).什么是 Spring Boot？
Spring Boot使⽤了特定的⽅式来进⾏配置，其设计⽬的是⽤来简化新 Spring 应⽤的初始搭建以及开发过程，从⽽使开发⼈员不再需要定义样板化的配置.  Spring Boot 不是什么新的框架，它默认配置了很多框架的使⽤⽅式，Spring Boot 简化了基于 Spring 的应⽤开发，通常我们想要集成的常⽤框架，它都有对应的组件⽀持，通过少量的代码就能创建⼀个独⽴的、产品级别的 Spring 应⽤.
Spring Boot的核⼼功能 :
(1)  起步依赖
SpringBoot⼯程继承spring-boot-starter-parent后已经具备版本锁定等配置了，然后对于我们需要的某种功能添加起步依赖，起步依赖会进⾏依赖的传递，这些依赖组合在⼀起即⽀持某项功能。简单的说，起步依赖就是将具备某种功能的坐标打包到⼀起，并提供⼀些默认的功能。
Spring  Boot配置⽂件的加载：
传递依赖时会依次从resources⽬录下加载l和application.properties配置⽂件。
(2).⾃动配置
Spring Boot的⾃动配置是⼀个运⾏时（更准确地说，是应⽤程序启动时）的过程，考虑了众多因素，才决定 Spring配置应该⽤哪个，不该⽤哪个。该过程是Spring⾃动完成的。
SpringBoot可以简化开发的⼀个主要原因就是采⽤了默认配置，所谓约定⼤于配置就是这个意思。在没有⾃⼰指定配置的时候使⽤默认配置的原理，如若需要更改配置，则需要在application.properies或者l配置中添加对应属性。
Spring Boot⾃动配置运⾏原理：
(1). SpringBoot项⽬运⾏类启动，就是添@SpringBootApplication注解的类。
先看@SpringBootApplication
@SpringBootConfiguration：标记当前类为主配置类
@EnableAutoConfiguration：开启⾃动配置
@ComponentScan：扫描主类所在的同级包以及下级包⾥的被注解的Bean
(2).⾃动配置的核⼼功能是由@EnableAutoConfiguration这个注解提供的。
springboot框架的作用@Import(AutoConfigurationImportSelector.class)导⼊的配置功能，
AutoConfigurationImportSelector⾥有⼀个selectImports⽅法，这个⽅法⾥有⼀个configurations，返回的configurations对象中包含待配置的class的类名集合。
在⽅法⾥调⽤了getCandidateConfigurations⽅法, ⽽这个⽅法⾥⼜调⽤了SpringFactoriesLoader下的loadFactoryNames⽅法, loadFactoryNames⽅法会扫描META-INF/spring.factories⽂件, 这⽂件列出了哪些需要⾃动配置。
但是⾃动配置类是否会被⾃动配置，还需要满⾜类上边注明的条件判断注解。
这⾥使⽤⾮常常⽤的DataSourceAutoConfiguration类来做例⼦讲解⼀下⾃动配置的流程。⾸先进⼊这个类，可以上⾯的⼏个注解。简单介绍⼀下这⼏个注解的作⽤。
@Configuration注解：声明此类为配置类。
@ConditionalOnClass注解：判断classpath下是否存在后⾯指定的类，因为我这⾥没有引⼊对应的类，所以会报红，所以这个⾃动配置也并没有⽣效。
@EnableConfigurationProperties注解：启⽤ConfigurationProperties功能，这个注解后⾯指定的类就是需要映射属性到配置⽂件的属性类。这⾥的配置⽂件是指application.properties⽂件.(如若要修改默认配置，可在此配置⽂件添加⾃定义属性和值得键值对)
@Import注解：数据库配置相关的类，有的⾃动配置类时没这个注解的，⽐如RedisAutoConfiguration类，所以这个看具体情况，但是前⾯三个注解是必须的。
附：常见org.springframework.dition包下的条件注解意思
@ConditionalOnBean：当容器⾥有指定的bean的条件下。
@ConditionalOnMissingBean：当容器⾥不存在指定bean的条件下。
@ConditionalOnClass：当类路径下有指定类的条件下。
@ConditionalOnMissingClass：当类路径下不存在指定类的条件下。
@ConditionalOnProperty：指定的属性是否有指定的值，⽐如@ConditionalOnProperties(prefix=””, value=”enable”, matchIfMissing=true)，代表当为enable时条件的布尔值为true，如果没有设置的情况下也为true。
Spring Boot的使⽤：
(1). 创建⼀个maven⼯程，该⼯程为普通的java⼯程即可。
(2). SpringBoot要求项⽬要继承SpringBoot的起步依赖spring-boot-starter-parent
(3). 提供SpringBoot引导类。
(4).在引导类同级包或者⼦级包中创Controller类。
(2).什么是Spring Clound？
Spring Cloud 是⼀系列框架的有序集合，它是基于Spring Boot实现的微服务架构开发⼯具，并且为微服务中设计的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策精选、分布式会话和集状态管理等操作提供了⼀套简单的开发⽅式，这些操作都可以⽤ Spring Boot 的开发风格做到⼀键启动和部署。
Spring Cloud 原理详解及核⼼组件使⽤：
推荐博⽂:blog.csdn/qq_41701956/article/details/83829539
4.微服务、Springboot、Springcloud他们三者之间⼜有什么关系?
(1).微服务是⼀种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。
(2).Spring Boot 是⼀套快速配置脚⼿架，可以基于 Spring Boot 快速开发单个微服务。
(3).Spring Cloud基于 Spring Boot 实现服务治理⼯具包;Spring Boot 专注于快速、⽅便集成的单个微服务个体;Spring Cloud 关注全局的服务治理框架。Spring Boot / Cloud 是微服务实践的最佳落地⽅案。
Spring Cloud 和Dubbo分布式架构的对⽐.
(1).从两个公司的背景来谈
Dubbo是阿⾥巴巴服务化治理的核⼼框架，并被⼴泛应⽤于中国各互联⽹公司;Spring Cloud 是⼤名⿍⿍的 Spring 家族的产品。阿⾥巴巴是⼀个商业公司，虽然也开源了很多的顶级的项⽬，但从整体战略上来讲，仍然是服务于⾃⾝的业务为主。Spring 专注于企业级开源框架的研发，不论是在中国还是在世界上使⽤都⾮常⼴泛，开发出通⽤、开源、稳健的开源框架是他们的主业。
(2).从社区活跃度这个⾓度来对⽐
Dubbo 虽然也是⼀个⾮常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这⽅⾯做的⽐ Spring Cloud 还好，除过当当⽹在此基础上增加了 rest ⽀持外，已有两年多的时间⼏乎没有任何更新了。在使⽤过程中出现问题，开发者提交到 GitHub 的 Issue 也少有回复。相反 Spring Cloud ⾃从发
展到现在，仍然在不断的⾼速发展。从GitHub 上提交代码的频度和发布版本的时间间隔就可以看出，现在 Spring Cloud 即将发布 2.0 版本，到了后期会更加完善和稳定。
(3).从整个⼤的平台架构来讲
Dubbo 框架只是专注于服务之间的治理，如果我们需要使⽤配置中⼼、分布式跟踪这些内容都需要⾃⼰去集成，这样⽆形中增加了使⽤ Dubbo 的难度。Spring Cloud ⼏乎考虑了服务治理的⽅⽅⾯⾯，更有 Spring Boot 的⽀持，开发起来⾮常的便利和简单。
(4).从技术发展的⾓度来讲
Dubbo 刚出来的那会技术理念还是⾮常先进，解决了各⼤互联⽹公司服务治理的问题，中国的各中⼩公司也从中受益不少。经过了这么多年的发展，互联⽹⾏业也是涌现了更多先进的技术和理念，Dubbo ⼀直停滞不前，⾃然有些掉队，有时候我个⼈也会感到有点可惜，如果 Dubbo ⼀直沿着当初的那个路线发展，并且延伸到周边，今天可能⼜是另⼀番景象了。
(5).两者使⽤特点
⾸先springcloud对⽐dubbo，最⼤的特点之⼀就是使⽤Restful的模式进⾏交互，dubbo是基于RPC进⾏通信的，⽽Restful是基于Http协议进⾏的，从协议的⾓度上来说Http和RPC都是基于TCP进⾏研发
的协议，Http是最⼴泛的，不仅⽀持浏览器还⽀持各种APP通信，这么来说吧Http就是⼤家都在⽤的协议，⽽RPC是针对某⼀个平台某⼀个环节针对性开发的⾃定义协议，Http由于⼤众化，所以本⾝协议会有点笨重，解析起来⾃然也⽐RPC要慢，这也是RPC的优势之⼀，但是Http具有良好的跨平台性质
微服务 vs 传统开发
1.分⼯不同，以前我们可能是⼀个⼀个模块，现在可能是⼀⼈⼀个系统。
2.架构不同，服务的拆分是⼀个技术含量很⾼的问题，拆分是否合理对以后发展影响巨⼤。
3.部署⽅式不同，如果还像以前⼀样部署估计累死了，⾃动化运维不可不上。
4.容灾不同，好的微服务可以隔离故障避免服务整体 down 掉，坏的微服务设计仍然可以因为⼀个⼦服务出现问题导致连锁反应。
5.给数据库带来的挑战
每个微服务都有⾃⼰独⽴的数据库，那么后台管理的联合查询怎么处理?这是⼤家普遍遇到的⼀个问题。
有如下三种处理⽅案：
(1).严格按照微服务的划分来做，微服务相互独⽴，各微服务数据库也独⽴，后台需要展⽰数据时，调⽤各微服务的接⼝来获取对应的数据，再进⾏数据处理后展⽰出来，这是标准的⽤法，也是最⿇烦的⽤法。
(2).将业务相关的表放到⼀个库中，将业务⽆关的表严格按照微服务模式来拆分，这样既可以使⽤微服务，也避免了数据库各种切换导致后台统计难以实现，是⼀个折中的⽅案。
(3).数据库严格按照微服务的要求来切分，以满⾜业务⾼并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进⾏数据清洗，⽤来满⾜后台业务系统的使⽤，推荐使⽤ Mongodb、Hbase 等。
第⼀种⽅案适合业务较为简单的⼩公司；第⼆种⽅案，适合想在原有系统之上，慢慢演化为微服务架构的公司；第三种适合⼤型⾼并发的互联⽹公司。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。