SpringBoot 和SpringCould 还有一些技术点

springboot简介

Spring Boot是一个框架，主要理念就是消除项目中大量的配置文件，使项目更加短小精悍。我们知道 java 的开发显得很笨重：繁多的配置、开发效率低下、复杂的布署流程以及第三方技术集成难度大。所以说，spring boot就是在此环境下产生的。

Springboot的特有的实践

1. 使用自定义BOM来维护第三方依赖
2. 使用自动配置
3. 使用Spring Initializr来开始一个新的Spring Boot项目
4. 围绕业务功能构建@Service
5. 使数据库独立于核心业务逻辑之外
6. 保持业务逻辑不受Spring Boot代码的影响
7. 推荐使用构造函数注入
8. 熟悉并发模型
9. 加强配置管理的外部化
10. 提供全局异常处理
11. 使用日志框架
12. 测试你的代码
13. 使用测试切片让测试更容易，并且更专注
14. Spring Boot，编写基于Spring的微服务正变得前所未有的简单
15. 保持@Controller的简洁和专注
16. 正确设计代码目录结构
17. 考虑为常见的组织问题创建自己的自动配置

Springboot的特点

1. 创建独立的Spring应用程序
2. 嵌入的Tomcat，无需部署WAR文件
3. 简化Maven配置
4. 自动配置Spring
5. 提供生产就绪型功能，如指标，健康检查和外部配置
6. 绝对没有代码生成和对XML没有要求配置

Springboot的核心功能

1.独立运行的Spring项目
2.里面自动配置服务器
3.提供starter简化maven配置
4.自动配置spring
5.准生产的应用监控
6.无代码生成和Xml配置

微服务架构的优势

1. 服务的独立部署
2. 服务的快速启动
3. 更新适合敏捷开发
4. 职责专一，由专门的团队负责专门的服务
5. 服务可以动态按需扩容
6. 代码地复用

微服务架构的劣势

1. 分布式部署
2. 独立的数据库分布式事务的挑战
3. 测试的难度提升
4. 运维难度的提升

为什么要学习SpringBoot

java一直被人诟病的一点就是臃肿、麻烦。当我们还在辛苦的搭建项目时，可能Python程序员已经把功能写好了，究其原因主要是两点
复杂的配置
项目各种配置其实是开发时的损耗， 因为在思考 Spring 特性配置和解决业务问题之间需要进行思维切换，所以写配置挤占了写应用程序逻辑的时间
混乱的依赖管理
项目的依赖管理也是件吃力不讨好的事情。决定项目里要用哪些库就已经够让人头痛的了，你还要知道这些库的哪个版本和其他库不会有冲突，这也是件棘手的问题。并且，依赖管理也是一种损耗，添加依赖不是写应用程序代码。一旦选错了依赖的版本，随之而来的不兼容问题毫无疑问会是生产力杀手。

而SpringBoot让这一切成为过去！

什么是springCloud

spring提供的微服务架构，类似于dubbo。http协议
eureka：注册中心 ribbon hystrix zuul feign

eureka

eureka-server：1.引入依赖 2.添加配置：spring.application.name=服务名 eureka.client.service-url.defaultZone= 3.在引导类上添加@EnableEurekaServer
eureka-client：1.引入依赖 2.添加配置 3.@EnableDiscoveryClient DiscoveryClient.getInstances

系统架构演变

1.集中式架构
2.垂直拆分
3.分布式服务
4.流动计算架构（SOA）
5.微服务=SpringCould

服务调用方式

1.RPC和HTTP
2.Http客户端工具
3.Spring的RestTemplate

为什么要学习SpringCloud

不论是商业应用还是用户应用，在业务初期都很简单，我们通常会把它实现为单体结构的应用。但是，随着业务逐渐发展，产品思想会变得越来越复杂，单体结构的应用也会越来越复杂。这就会给应用带来如下的几个问题：

代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。同时，这也会给业务的快速迭代带来巨大挑战；

开发效率变低：开发人员同时开发一套代码，很难避免代码冲突。开发过程会伴随着不断解决冲突的过程，这会严重的影响开发效率；

排查解决问题成本高：线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，需要重新编译、打包、上线，成本很高。

由于单体结构的应用随着系统复杂度的增高，会暴露出各种各样的问题。近些年来，微服务架构逐渐取代了单体架构，且这种趋势将会越来越流行。Spring Cloud是目前最常用的微服务开发框架，已经在企业级开发中大量的应用。

什么是SpringCould

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
设计目标与优缺点

设计目标

协调各个微服务，简化分布式系统开发

微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring Cloud的呢？

优点：
产出于Spring大家族，Spring在企业级开发框架中无人能敌，来头很大，可以保证后续的更新、完善组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、配置管理、服务发现、断路器、微服务网关等；Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于提高开发效率可以更精准的制定优化服务方案，提高系统的可维护性减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发微服务可以是跨平台的，可以用任何一种语言开发适于互联网时代，产品迭代周期更短
缺点：
微服务过多，治理成本高，不利于维护系统分布式系统开发的成本高（容错，分布式事务等）对团队挑战大总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。

Spring Cloud发展前景

Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年微服务架构和Docker容器概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

主要项目

Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架Spring Boot化的封装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。

Eureka的高可用

Eureka实例的互相注册，高并发
启动多个实例，实例与实例之互相持有对象的端口号

服务的失效与自我保护
心跳时间：每过一段时间，Eureka会连接一次实例服务
过期时间：当某一个服务心跳之后，没有响应，N秒之后会将此服务从Eureka服务列表中剔除
关闭自我保护：不在设置心跳时间，到了过期时间就直接关闭剔除

面试题

什么是Eureka和Eureka的作用

服务的发现与注册中心，用来管理所有服务的信息，服务的名称，服务是否可用

Eureka怎么用

先导入依赖，Eureka是分为服务端和客户端的。服务端的作用就是用来保存服务列表的。客户端的作用就是我们普通的功能性服务。
在使用的时候服务端需要开启服务@EnableEurekaServer。服务端使用的@EnableDiscoveryClient。
服务端还需要再yml配置文件中，指定路径
客户端也需要在yml配置文件中，指定Eureka的路径

Ribbon

概念
用于负载均衡，在Eureka中已经被封装了
使用
flowchat
导入依赖，只有需要在RestTemplate对象上，使用注解@LoadBalanced，在使用连接的时候，通过服务的ID来完成连接
负载均衡的规则
默认是轮询，可选随即，在yml中进行设置
service-provider:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

使用的工具是ribbon，通过对请求的拦截，而进行的url路径分析，通过得到url中，服务名ID。进行默认的轮询规则的服务实例的选择，系统提供的规则有两种，一个是轮询，一个是随即，其实最好的我认为是能者多劳，但是，我不会。最终生成，对应服务的url http://localhost:808X。

hystrix

概念
用于服务的自我保护，类似于保险丝和空气开关，当服务被多次访问，并都发生等待，就必须进行熔断或降级操作。
雪崩
由于电脑的内存和cpu等原因，导致的服务的等待时间过长，而造成的内存压力，最终导致服务整个崩溃。
服务降级
治标不治本，只是将对应的服务，单独拎出来进行隔离。
服务熔断
治本，当访问失败的次数超过默认20次阈（yu）值警戒线，彻底不允许访问此服务
close，熔断关闭，可正常访问，当失败的访问次数过多，会进入open开启状态
open，熔断开启，无法方法，当5秒内，没有请求进入，则进入半开状态
half open，半开状态，允许部分请求进行正常访问，如果访问都是健康的，则进行close关闭状态，反之，则继续进入open打开状态
使用
导入依赖，并在主类上添加注解，@EnableCircuitBreaker。在对应的需要进行管理的url方法上，添加依赖@HystrixCommand，还需要设置回调方法fallbackMethod