SpringBoot-01

Spring Boot+SpringCloud

---

目录：

day01:SpringBoot01

day02:SpringBoot02

---

day01:SpringBoot01

Spring Boot+SpringCloud 微服务框架

2018年重点兴起两个核心技术之一

1. docker容器化技术，替代vm虚拟机
2. SpringCloud微服务

课程安排：

构建项目Maven缺点：

1. 大型项目jt-parent父项目，统一管理jar版本。 D ubbo微服务jar版本冲突漫天飞。

S pringBoot出品父工程boot-starter，以后所有的工程都是这个工程的子项目。

 2.基于SSM编程，有不方便的？最爱出错的地方。Xml配置，没有ide丰富错误提示。

直到运行时，才出错提示。配置文件还很多，springmvc-config.xml、applicationContext*.xml（数据源、事务、redis、httpclient、。。。。）、mybatis-config.xml

X ml零配置，开发习惯：约定大于配置。三大配置文件消失，公用通用都消失，相当于约定。但是有很少一部分配置还需要用户自己解决。例如：数据源，

application.yml(yaml) Hadoop离线分析，类似properties属性配置文件。 K ey树形结构,value

约定+注解

 3.部署运行一个项目，tomcat插件，运行web.xml（spring侦听，DispatcherServlet）

M ain入口函数，不许配置tomcat，默认引入！jdk1.8

创建第一个SpringBoot项目

需求： http://localhost:8080/hello/tony     RESTFul形式

HelloController返回，页面上返回json， “ hello springboot tony ”

1、创建Maven工程，简单骨架

2、pom.xml 引入父工程（统一管理jar） 标识web项目？

 

org.springframework.boot
spring-boot-starter-parent
2.1.0.RELEASE
 



UTF-8
UTF-8
1.8





org.springframework.boot
spring-boot-starter-web






org.springframework.boot
spring-boot-maven-plugin

3、实现HelloController，解析/hello/tony，返回json字符串部署，运行，引入启动类，两句话：run方法，注解springboot程序

@Controller
public class HelloController {

@RequestMapping("/hello/{name}")
@ResponseBody
public String hello(@PathVariable String  name) {
return "hello springboot"+name;
}
}

4、部署生产环境

package cn.tedu;
import  org.springframework.boot.SpringApplication;
import  org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class RunApp {
public static void main(String[] args) {
SpringApplication.run(RunApp.class,  args);
}
}

5、效果

1. 外部tomcat，war
2. 微服务，直接运行jar包+SpringBoot（微缩版tomcat，微服务） 运行jar包？

java -jar jar包文件

java -jar hello-0.0.1-SNAPSHOT.jar

SpringBoot

1. 写项目无需自己去配置父工程，它提供spring-boot-starter-parent项目，以后所有的springboot项目都是子工程
2. 所有SpringBoot工程一般都是jar类型工程，如果需求web支撑，引入spring-boot-starter-web
3. 启动方式，启动类，实现xml近似零配置run方法，注解@SpringBootApplication
4. 部署运行，内嵌tomcat，运行java – jar hello.jar

敏捷开发，SpringBoot快速，简易构建项目工具

所以的技术都要和SpringBoot整合。

SpringCloud不是自己去完成所有的技术，把业界最优秀产品集成起来，为我们普通开发者来使用。俗语：不重复发明轮子！拿来主义！

Eureka注册中心

Ribbon负载均衡

Feign REST封装支持

Zuul API网关

SpringCloudConfig配置中心

Sidecar 异构系统的支持

SpringBoot或者SpringCloud全家桶

SpringBoot实现user表CRUD操作

查询所有：

1. 创建工程Maven，pom.xml
2. 创建POJO对象User.java
3. 创建映射文件 UserMapper.xml，资源目录mappers/*.xml
4. UserMapper.java接口（扫描）
5. UserServiceImpl.java实现类
6. UserService.java接口
7. UserController.java
8. SpringBoot核心配置文件：application.yml（k树形v）
9. 启动类RunApp.class

动态代理（设计模式）

1. jdk动态代理（有接口）       $ProxyN
2. cglib动态代理（无接口）     cglib

三个扫描：

1. UserMapper接口扫描 @MapperScan("cn.tedu.ssm.mapper")
2. UserService，SpringBoot约定路径和注解@Service
3. UserController，SpringBoot约定路径和注解@Controller

Y ml配置文件

1. 树形结构，表现力强，本质kv
2. 不允许tab键
3. 日志路径如果错误，无法打印SQL

练习：15分钟

1. 实现新增、修改、删除方法

元数据metadata

WebService  JWS（j2ee规范）JAX-RS（REST Service）

天生异构系统支持

WSDL WebService描述语言，XML

SOAP 轻量级封装HTTP协议，加的信封，简单对象访问协议

基于XML，标签太多

被json

WebService转换不同语言对象慢，xml传输，标签太多，浪费传输内容太多。

Apache CXF

WebService已经被淘汰，我们项目也不使用Apache CXF。

我们项目中使用RESTFul+json方式通讯。早期时我们项目httpclient，现在主要使用springmvc Controller，支持RESTFul形式访问，json返回。后期我们又使用SpringCloud，Feign来封装REST形式，本质是一个接口文件。

小结：

1. SpringBoot创建工程，本质是Maven工程
2. 无需自己构建父工程spring-boot-starter-parent
3. 它内部对应SpringBoot会依赖一些提前写好的公用的jar
4. 包类型不是war包，是jar包，增加一个依赖spring-boot-starter-web，标识是一个web项目，它会自动嵌入web中间件tomcat。直接发布。
5. 启动类，2句话。SpringApplication.run()，@SpringBootApplication
6. Controller引入新的注解@RestController，Dubbo基于RPC，SpringCloud基于RESTFul+json天生异构。
7. SpringBoot还是基于SSM三大框架的，但是三大框架的配置文件，实现XML零配置（hibernate）web.xml消失。有个别个性配置还需要有地方来设计。application.yml/application.properties/bootstrap.yml
8. SpringBoot使用约定大于配置（约定+注解），xxxAutoconfigure，配置类，如果需要个性配置，自己要写配置类，配置类就覆盖约定。

---

day02:SpringBoot02

知识回顾：

1. 构建SpringCloud微服务项目时，全新开发方式，采用SpringBoot开发。
2. SpringBoot快速构建一个项目工具
3. 特点：

a. 构建大型项目，需要自己去构建父工程jt-parent，很大难度，jar版本冲突（高级程序员、架构师）不需要自己构建，spring-boot-starter-parent父工程（少部分公用）

b. Spring Boot主推项目的包类型：jar，全新运行方式配置java -jar xxx.jar

c. c)大多数软件都是跟数据库交互，基于SSM三大框架实现。传统方式需要大量配置文件，配置文件中基于xml，没有语法检查，没有大小写检查，没有正确调用检查，开发者粗心，增加我们调试时间，而这个时间浪费毫不值得。SpringBoot就消灭这些配置文件，约定+注解（反射+动态代理。。。）实现夙愿，xml零配置。近似0，还有项目个性化配置（数据库连接）出现新的配置文件：application.yml（推荐）/application.properties，bootstrap.yml，bootstrap.properties。启动时加载很多配置文件，有优先级，bootstrap>application（配置中间）

d. 启动方式，部署方式。新的方式就是一个启动类，两句话。@SpringCloudApplication

4. 业界都会使用SpringBoot，必由之路

今日任务：

1. SpringCloud微服务
2. Eureka注册中心
3. Ribbon负载均衡
4. Feign REST形式支持（接口）

微服务是必由之路吗？

微服务特点：

1. 实际就是业务垂直拆分再次细分。换一句话，微服务和业务垂直拆分系统的差异，划分服务粒度更细。
2. 优点：每个子项目功能单一，结构清晰，代码易维护；错误大量减少，出现BUG几率也小，方便调试，加快调试时间。开发效率高。代码量小。数据库分开。（优化：分库分表）数据库访问压力急剧降低。程序性能，数据库性能就提高。
3. 缺点：系统多了，系统之间调用变复杂，代码在不同的服务器，原本单体架构中，在同一个jvm中互相调用，跨服务器，代表跨网络，TCP/IP二进制字节，java转换成二进制字节流（序列化、反序列化），耗费时间。网络涌动！影响程序的稳定性。（Hadoop）。实际开发中微服务拆分，随意！（凭经验）

微服务最核心地方就在于服务拆分。

并不是必由之路，微服务80%，业务垂直拆分20%。

2018年微服务落地

1. SSM，一室一厅
2. 阿里Dubbo，一室两厅；基于RPC远程过程调用
3. SpringCloud，别墅，基于RESTFul+json（天然异构支撑）内涵非常丰富

Dubbo官宣：Dubbo框架只是SpringCloud的微服务一个子集，专注于RPC解决方案

SpringCloud

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems

java23中设计模式

(e.g.

configuration management,      配置中心

service discovery,               服务发现（注册中心）

circuit breakers,                断路器，熔断器

intelligent routing,              智能路由，GateWay API网关

micro-proxy,                  微代理

control bus,                   控制总线

one-time tokens,               一次令牌

global locks,                   分布式锁

leadership election,             选举机制

distributed sessions,             分布式session管理

cluster state).             集群状态

Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer's own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

面向：

1. 面向过程，日常函数思考方式，遇到什么解决什么，几乎不多想
2. 面向对象，万物皆对象，首先考虑不是你的业务，而是对象的属性和方法（行为）
3. 面向切面，AOP，面向对象有益补充
4. 面向服务，万物皆服务
5. 面向架构，和业务不太相关，整体框架

SOA面向服务架构，核心ESB（中心化）企业服务总线（信息共享），参加计算机组成原理。

过气！

Dubbo称为SOA思想最佳实践，微服务，服务治理

BIO阻塞IO，大数据，互联网架构NIO，非阻塞IO。

N etty框架，java NIO concureent包，API晦涩难懂，netty把它封装。非常简单，易学。

J ava培优微服务学习内容：

1. Eureka注册中心，服务提供者，服务消费者
2. Ribbon负载均衡，类似nginx
3. Feign REST封装，接口，bug很多
4. Hystrix 断路器
5. Zuul API网关
6. Sidecar异构语言支持，NodeJS
7. SpringCloudConfig配置中心，数据存在Git，版本控制

都很简单，都是几个注解就搞定。

CAP定理，原则，分布式系统设计的定理

C consistency 一致性

A availablility 可用性

P partitionTolerance 分区容错性

数据库设计规范：

1. 必须遵守三范式3NF（1.表必须有主键；2.表不能有重复的列； 3.表的字段内容不能加工而来）。如果按三范式设计保证数据唯一出处， 数据的一致性
2. 反三范式，冗余设计。短暂时间数据不一致。 最终一致性 。

注册中心：ZooKeeper和Eureka有什么不同？谁更适合注册中心的业务

1）ZK主从设计，在zk集群选举时，还有节点宕机超过一半时。它担心此时已经不能保证数据一致性，不推荐使用。设计目标CP

2）Eureka 点对点的设计。peer to peer。每个节点互相备份数据。即使所有节点宕机，还可以用。客户端，保留服务列表。设计目标AP

在分布式系统设计中，P必须的（网络）

总结：zk基于CP，侧重一致性；Eureka基于AP，侧重可用性。

谁更适合做注册中心？

注册中心，维护服务列表，动态维护服务列表

服务地址会频繁发生变化吗？不会！更加适合AP设计，死都要试试！

SpringCloud中服务消费者调用服务提供者，两种方式

1. RestTemplate
2. Feign

如果再有一个提供者，提供的是相同服务。

如果实现负载均衡？

Ribbon完成负载均衡，基于RestTemplate对象实现

1）Eureka中已经含有Ribbon，自动依赖jar

2）访问路径中就要使用提供者的application.name=PROVIDER-HELLO，修改端口

3） @LoadBalanced 利用注解实现负载均衡

EurekaClient它有心跳机制，每个1s去访问EurekaServer，如果服务列表变化，它就会更新本地服务列表缓存。如果没有变化，什么也不干。

Nginx，我们先发起请求，请求经过很多很多的路由，找到服务；可能访问服务已经宕机了。但是Nginx没有感知，它去访问，经过很多路由，访问失败！

Ribbon动态同步Eureka服务列表，如果客户端老不访问Eureka服务端，Eureka判定这个客户端死亡，它把这个服务连接从动态列表中移除。消费者客户端心跳时，发现EurekaServer列表发生变化，同步它的信息。发现h1不能访问，因为列表中只有h2,h3，只遍历它们即可。实现如果服务宕机，根本不去访问。

Eureka并不是马上删除异常服务

如果出现一行红字，它也不会删除，保护模式！

F eign 在Eureka+Ribbon基础实现REST请求封装

1. RestTemplate
2. Feign自定义接口

Feign is a declarative web service client.

Feign是声明式的webService客户端。

WebService WDSL WebService描述语言xml文件/SOAP简单对象访问协议/XML异构系统支持

Apache CXF ，被淘汰，原因：底层基于xml传输数据，轻量级封装HTTP协议，形成SOAP。传输标签过多，浪费带宽，被RESTFul+json。httpClient/Dubbo/SpringCloud

JAX-RS WS规范WebService，提出RESTFul，RestService。

Dubbo封装RPC访问形式

Feign封装REST+JSON访问形式

It makes writing web service clients easier.

创建WebSerivce微服务调用非常容易。 “ 假的 ”

To use Feign create an interface and annotate it. It has pluggable annotation support including Feign annotations and JAX-RS annotations. Feign also supports pluggable encoders and decoders. Spring Cloud adds support for Spring MVC annotations and for using the same HttpMessageConverters used by default in Spring Web.

Spring Cloud integrates Ribbon and Eureka to

provide a load balanced http client when using Feign.

Feign完全 ” 兼容 ” SpringMVC

Feign基于Eureka、Ribbon、Hystrix（断路器、熔断器）

SpringCloud提供两种访问提供者方式

1. RestTemplate API晦涩难懂，学习成本高
2. Feign 非常简洁，只要避过坑，非常容易学习。

Nginx负载均衡算法：

1. 默认，轮询
2. 权重，一般开发中都使用权重
3. IP_HASH 解决session共享，ip一般固定，hash算法结果，还是固定位置，问题：hash（key）%n，key业务，n机器个数。 H ash值偏移，不够平均。
4. url_hash hash(url)%n，url相对ip而言变化量多，偏移少，尽量平均分配
5. fair第三方，安装插件，统计机器访问频繁度，

编程lua，黑名单（爬虫） 临时 加入黑名单，一会把你放出来。

Feign调用过程？

小结：

1. 1）SpringCloud和Dubbo，Dubbo基于java写的，不支持异构，SpringCloud天生异构REST+json。从性能上Dubbo快，基于RPC，二进制，支持压缩。而且更安全。
2. SpringCloud全家桶，Eureka注册中心，Ribbon负载均衡，Feign声明式WebServiceClient
3. SpringBoot和S p ringCloud关系？都是Spring家族，目的不同，SpringBoot快速构建项目工具，SpringCloud目标形成一个大企业级框架，解决公用一些问题。注册中心，松耦合，无需硬编码。动态Eureka。Ribbon前端负载均衡。Feign接口调用REST更加简洁。。。。公用问题。 C ommon pattern。类似23种设计模式
4. 微服务能否解决所有问题？不能！，微服务之间部署到不同项目中，甚至不同机器，不同网络。增加调用复杂度，稳定性变差，服务分拆凭经验，不同人，经验不同，结果就不同。实际开发混合架构，主要依托微服务架构。故障隔离！
5. CAP定理，原则，分布式系统设计定理。C一致性，A可用性，P分区容错性。在分布式系统中P必须实现，以为网络涌动不确定性。ZooKeeper侧重一致性，保证数据可用。当zk集群选举时，当宕机节点超过一半时，不推荐使用。Eureka侧重是可用性，Eureka点对点设计，即使所有的节点宕机，还仍然能访问，本地客户端还有缓存，还维护服务列表，那就可以试试！ZK基于CP设计，Eureka基于AP设计。
6. Eureka注册中心，含心跳，动态服务列表
7. Ribbon负载均衡

a.RestTemplate对象

b.Feign方式，@SpringCloudApplication

---

作者：Darren

QQ：603026148

以上内容归Darren所有，如果有什么错误或者不足的地方请联系我，希望我们共同进步。

---