什么是SpringBoot？
1、用来简化spring初始搭建和开发过程使用特定的方式进行配置(properties或者yml文件)
2、创建独立的spring引用程序main方法运行
3、嵌入Tomcat无需部署war包，直接打成jar包nohup java -jar – & 启动就好
4、简化了maven的配置
4、自动配置spring添加对应的starter自动化配置
SpringBoot常用的starter：
1、spring-boot-starter-web(嵌入Tomcat和web开发需要的servlet和jsp支持)
2、spring-boot-starter-data-jpa(数据库支持)
3、spring-boot-starter-data-Redis(Redis支持)
4、spring-boot-starter-data-solr(solr搜索应用框架支持)
5、mybatis-spring-boot-starter(第三方mybatis集成starter)
SpringBoot自动配置原理：
1、@EnableAutoConfiguration这个注解会"猜"你将如何配置spring，前提是你已经添加了jar依赖项，如果spring-boot-starter-web已经添加Tomcat和SpringMVC，这个注释就会自动假设您在开发一个web应用程序并添加相应的spring配置，会自动去maven中读取每个starter中的spring.factories文件，该文件里配置了所有需要被创建spring容器中bean
2、在main方法中加上@SpringBootApplication和@EnableAutoConfiguration
SpringBoot starter工作原理：
1、SpringBoot在启动时扫描项目依赖的jar包，寻包含spring.factories文件的jar
2、根据spring.factories配置加载AutoConfigure
3、根据@Conditional注解的条件，进行自动配置并将bean注入到Spring Context
SpringBoot的优点：
1、减少开发、测试时间和努力
2、使用JavaConfig有助于避免使用XML
3、避免大量的maven导入和各种版本冲突
4、提供意见发展方法
5、通过提供默认值快速开始开发
6、没有单独的web服务器需要，这就意味着不再需要启动Tomcat、Glassfish或其他任何东西
7、需要更少的配置，因为没有l文件。只需添加用@Configuration注释的类，然后添加用@Bean注释的方法，Spring将自动加载对象并像以前一样对其进行管理。甚至可以将@Autowired添加到bean方法中，以使用Spring自动装入需要的依赖关系中
Springcloud解决那些问题：
配置管理、（注册中心eureka、zk）、服务发现、服务注册、断路器、路由策略、全局锁、分布式会话、客户端调用、接口网关（zuul）、服务管理系统
SpringBoot与Springcloud：
1>、SpringBoot简化了xml配置，快速整合框架
2>、Springcloud是一套微服务解决方案—RPC远程调用
3>、关系Springcloud依赖与SpringBoot（web组件用的SpringMVC），为什么Springcloud会依赖与SpringBoot？因为Springcloud写接口就是SpringMVC接口
4>、SpringBootproperties和yml中可以使用${random}设置一些随机值
服务的调用：
rest、feign（均使用httpclient技术），负载均衡ribbon
服务调用的原理：
服务首先注册到注册中心eureka中(注册一个名字通过名字调用)
负载均衡
ribbon，先去注册中心取到对应的服务，然后交给我ribbon
配置详解：
1>、ister-with-eureka：是否向注册中心注册自己，注册为true反之为false
2>、eureka.client.fetch-registry： 是否需要去检索服务，检索为true反之为false
3>、eureka.client.serviceUrl.defaultZone : 指定服务注册中心的地址
Eureka：
1>、eureka可分为三个角：服务发现者、服务注册者、注册发现中心，但是这三个角并不和实际部署的模型是一对一的关系
2>、所有的网络通信都是基于http(s)协议的
3>、Eureka和AWS是紧密结合的，无论是配置还是源码，比如Region、zone…，Region可以通过配置文件进行配置，如果不配置默认使用us-east-1。同样Zone也可以配置，若不配置默认使用defaultZone
高可用配置：
Eureka server 的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用效果。
微服务：
以前所有的代码都放在同一个工程中、部署在同一个服务器、同一项目的不同模块不同功能互相抢占资源，微服务就是将工程根据不同的业务规则拆分成微服务，部署在不同的服务器上，服务之间相互调用，java中有的微服务有dubbo(只能用来做微服务)、springcloud( 提供了服务的发现、断路器等)。
微服务的特点：
按业务划分为一个独立运行的程序，即服务单元
服务之间通过HTTP协议相互通信
自动化部署
可以用不同的编程语言
可以用不同的存储技术
服务集中化管理
微服务是一个分布式系统
微服务的优势：
1、将一个复杂的业务拆分为若干小的业务，将复杂的业务简单化，新人只需要了解他所接管的服务的代码，减少了新人的学习成本。
2、由于微服务是分布式服务，服务于服务之间没有任何耦合。微服务系统的微服务单元具
有很强的横向拓展能力。
3、服务于服务之间采用HTTP网络通信协议来通信，单个服务内部高度耦合，服务与服务之间完全独立，无耦合。这使得微服务可以采用任何的开发语言和技术来实现，提高开发效率、降低开发成本。
4、微服务是按照业务进行拆分的，并有坚实的服务边界，若要重写某一业务代码，不需了解所以业务，重写简单。
5、微服务的每个服务单元是独立部署的，即独立运行在某个进程中，微服务的修改和部署对其他服务没有影响。
6、微服务在CAP理论中采用的AP架构，具有高可用分区容错特点。高可用主要体现在系统7x24不间断服务，他要求系统有大量的服务器集，从而提高系统的负载能力。分区容错也使得系统更加健壮。
微服务的不足：
1、微服务的复杂度：构建一个微服务比较复杂，服务与服务之间通过HTTP协议或其他消息传递机制通信，开发者要选出最佳的通信机制，并解决网络服务差时带来的风险。
2、分布式事物：将事物分成多阶段提交，如果一阶段某一节点失败仍会导致数据不正确。如果事物涉及的节点很多，某一节点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。
3、服务划分：将一个完整的系统拆分成很多个服务，是一件非常困难的事，因为这涉及了具体的业务场景
4、服务部署：最佳部署容器Docker
微服务和SOA的关系：
微服务相对于和ESB联系在一起的SOA轻便敏捷的多，微服务将复杂的业务组件化，也是一种面向服务思想的体现。对于微服务来说，它是SOA的一种体现，但是它比ESB实现的SOA更加轻便、敏捷和简单。
springcloud如何实现服务注册与发现？
服务发布时指定对应的服务名(IP地址和端口号)，将服务注册到注册中心(eureka和zookeeper)，但是这一切是Springcloud自动实现的，只需要在SpringBoot的启动类上加上@EnableDisscoveryClient注解，同一服务修改端口就可以启动多个实例调用方法：传递服务名称通过注册中心获取所有的可用实例，通过负载均衡策略(Ribbon和Feign)调用对应的服务
Ribbon和Feign的区别：
Ribbon添加的maven依赖是spring-starter-ribbon，使用@RibbonClient(value=“服务名称”)使用RestTemplate调用远程服务对应的方法，
Feign添加的maven依赖是spring-starter-feign，服务提供方提供对外接口，调用方使用，在接口上使用FeignClient(“指定服务名”)，
具体区别：
分布式和微服务的关系
1、启动类使用的注解不同，Ribbon使用的是@RibbonClient，Feign使用的是@EnableFeignClients
2、服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明
3、调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。Feign则是在Ribbon的基础上进行了一次改进，采用接口调用的方式，将需要调用的其他服务的方法定义成抽象方法即可，不需要自己构建http请求，不过要注意的是抽象方法的注解、方法签名要和提供方的完全一致。
雪崩效应：
分布式系统中的服务通信依赖于网络，网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务之间出现了故障或者网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式系统必然要采取相应的措施，如熔断机制（Springcloud采用的是Hystrix）
熔断机制：
1、当一个服务出现故障时，请求失败次数超过设定的阀值（默认50）之后，该服务就会开启熔断器，之后该服务就不进行任何业务逻辑操作，执行快速失败，直接返回请求失败的信息。其他依赖于该服务的服务就不会因为得不到响应而造成线程阻塞，这是除了该服务和依赖于该服务的部分功能不可用外，其他功能正常。

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