SpringCloud学习一（回顾之前学的微服务知识点、springcloud入门概述、服务提供者和消费者）

一、回顾之前，如何学习springcloud

1. 回顾之前的知识？

• JavaSE
• 数据库
• 前端
• Servlet
• Http
• Mybatis
• Spring
• SpringMVC
• SpringBoot
• Dubbo、Zookeeper、分布式基础
• Maven、Git
• Ajax、Json
  …

2. 串一下自己会的东西？

• 数据库
• Mybatis
• Spring
• SpringMVC
• SpringBoot
• Dubbo、Zookeeper、分布式基础
• Maven、Git
• Ajax、Json

3. 这个阶段该如何学？

最早的：
三层架构 ： MVC
框架：
spring 两大核心：IOC AOP 目的：解决企业开发的复杂性
配置不简单
springboot，新一代的J2EE开发标准，核心特性：自动装配，特点：约定大于配置
（有本书叫做重构，专门用springboot重构之前的项目，所以说现在有很多公司在转型）
最早在学servlet的时候代码太多，框架帮忙简化了代码，框架配置太多了springboot帮忙简化了配置

springboot开发的应用如果随着公司体系越来越大，用户越来越多他还能支撑的住吗？

示例：
比如这五个业务模块集成在大的jar包里面或者war包里面，他是一个完整的项目。
那这个项目能支持的最大并发量是有上限的，
然后我们之前的解决方法是水平拆分负载均衡让用户去访问，
但是这时候有些业务的使用率并不高，有些业务的使用量（并发量）是非常大的，
这个时候把一个个模块提取出来
比如第一台服务器因为用户模块的使用量非常高那么就多放点用户业务，或者第二台服务器因为物流模块使用非常少放一个物流模块够用就行

总结：微服务拆分的核心：模块化~把一个个东西独立成一个个的模块
说白了就是人越来越多并发量太高了服务器解决不了了，横向扩展也发现了弊端，负载均衡没有用了

我们就要把all in one拆分成模块

模块化的开发和all in one对代码来说没有变化，只是拆成模块了

既然拆成一个个模块存在不同的电脑上就要通信
之前学了dubbo它是RPC通信，也可以通过HTTP

springcloud就是很经典的基于HttpRestFul风格进行通信的

微服务架构4个核心问题？

1. 服务很多，客户端该怎么访问？
   比如说你后面你有很多个服务，但是对用户只能从一个链接进来，访问完之后得根据一定得规则分发到这些服务器，不然的话用户就访问不到这些服务，这些服务肯定有一些规则比如负载均衡的一些逻辑算法，热备什么的
2. 这么多服务之间如何通信？
   比如订单模块和交易模块可能在不同的服务器上，可能是北美的服务器跟国内的服务器，传过来的话通信问题一般用http或者RPC去解决
3. 这么多服务之间如何治理？
   服务注册和发现的机制，会用到一些注册中心
4. 服务挂了怎么办？（重点难点）
   比如订单模块是好的，订单模块出现了问题，订单模块来连交易模块的时候交易模块崩了，然后后面就会引起了一系列服务雪崩（物流发货等）
   所以万一某个模块崩了我们要保证后面的一系列业务模块正常运行，
   可以把这个服务在创建之初给他备份一份，坏了可以用另外一份，多用些熔断的一些机制

---

对于这四个问题提出的解决方案可以称之为生态
spring cloud 生态！
并不是一门技术，是很多技术掺杂起来的生态，就是用来解决上面的四个问题

学springcloud之前要先学springboot，因为springboot是构建，springcloud是用来协调，springcloud是基于springboot的

loT：物联网
API Gateway：网关
三套解决方案：

1. Spring Cloud NetFlix（奈特菲力克斯） 一站式解决方案

第1个问题服务很多，客户端该怎么访问？：

物联网、移动端、浏览器都是通过网关

解决客户端通信使用的API网关，使用的是一个叫zuul组件的东西（其实就两句注解，但是还是要了解）

第2个问题：服务端之间怎么通信

之前学的RPC框架Dubbo，异步非阻塞
这里用的Feign（废因），也可能做一点负载均衡基于HttpClinet，也就是基于Http通信方式，同步并阻塞

第3个问题：如何治理
服务注册发现：Eureka

第4个问题：服务挂了怎么办
熔断机制：Hystrix（嘿死追可丝）
。。。。

2. Apache Dubbo Zookeeper 半自动，需要整合别人的

API网关：没有，找第三方组件，或者自己实现
服务通信：Dubbo（高性能基于Java开源的RPC通信框架，比Feign强）
服务注册：Zookeeper
熔断机制：没有，借助Hystrix

可见Dubbo这个方案并不完善，不完善的原因有很多，Dubbo并不想跟springcloud竞争，只是想单一的做一个RPC框架

3. Spring Cloud Alibaba 一站式解决方案

一站式意思是对上面得四个问题都有自己的一套解决方案
成本更低，更简单
跟上面的NetFilx几乎一样，界面简化了
NetFilx停止维护了，Alibaba的刚刚出来不久2019年出来的

扩展：
新概念：服务网格（下一代微服务的标准）Server Mesh
代表的解决方案是：istio

万变不离其宗

1. API网关（解决路由问题）
2. Http，RPC（解决通信问题）
3. 注册和发现（解决高可用问题）
4. 熔断机制（服务降级（挂了）的问题，防止服务雪崩）

为什么要解决这几个问题原因是：网络不可靠！
如果网络可靠不会出现上面的问题，无论访问什么资源就跟访问本地的一样就跟all in one一样，由于分布式网络是不可靠的，所以网络会丢包会丢帧可能数据呗拦截可能数据被丢失，这一切都会导致出现上述四个问题

常见面试题

1、什么是微服务？
2、微服务之间是如何独立通讯的？
3、Springcloud和dubbo有哪些区别？
4、SpringBoot和SpringCloud，请你谈谈对他们的理解
5、什么是服务熔断？什么是服务降级
6、微服务的优缺点分别是什么？说下你在项目开发中遇到的坑
7、你所知道的微服务技术栈有哪些？轻列举一二
8、eureka和zookeeper都可以提供服务注册于发现的功能，请说说两个的区别？
。。。。

要知道这个原因为什么要这么去用，如果使用就那么几个注解一配置就自动化实现了。

二、回顾微服务和微服务架构

2.1、什么是微服务？

微服务(Microservice Architecture)是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。
究竟什么是微服务呢？我们在此引用ThoughtWorks公司的首席科学家Martin Fowler于2014年提出的关于微服务的文章：
原文
汉化

• 就目前而言,对于微服务,业界并没有一个统一的,标准的定义（所以上面那篇文章才火，算是业界认可度最高的微服务定义文章了）
• 但通常而言,微服务架构是一种架构模式,或者说是一种架构风格，
  它提倡将单一的应用程序划分成一组小的服务（模块化），每个服务运行在其独立的自己的进程内（模块化后可以拼装），服务之间互相协调,互相配置,为用户提供最终价值。
  服务之间采用轻量级的通信机制互相沟通（也就是Http或者RPC），
  每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中（相当于每个服务都是一个端口，都是一个进程而不是线程），
  另外，应尽量避免统一的，集中式的服务管理机制，（所以我们有了一些分布式的服务注册和发现的机制）
  对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建，（一般用maven进行构建）
  可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务（最后都可以用一个轻量级的通讯机制进行沟通），也可以使用不同的数据库（可以在关系型数据库存东西也可以在非关系型数据库）；

可能有的人觉得官方的话太过生涩，我们从技术维度来理解下：
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

2.2、微服务与微服务架构

微服务
强调的是服务的大小,他关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的以看做是IDEA中的一个个微服务工程，或者Moudel。（只要带了一个application去启动的服务带有一个端口）

IDEA工具里面使用Maven开发的一个个独立的小Moudle,它具体是使用springboot开发的一个小模块,专业的事情交给专业的模块来做,一个模块就做着一件事情
强调的是一个个的个体,每个个体完成一个具体的任务或者功能!

微服务强调的是个体，而微服务架构不同，这是两个概念不要搞混

微服务架构
一种新的架构形式, Martin Fowler, 2014提出

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务于服务间采用轻量级的通信机制互相协作,每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境中,另外,应尽量避免统一的,集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言,工具对其进行构建。

简而言之微服务架构是要去解决上面的四个问题的，而微服务只是其中的一个组件而已

微服务要把很多服务组合起来才变成一个真正的服务

2.3、微服务优缺点优点

优点：

• 单一职责原则
• 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求
• 开发简单，开发效率提高，一个服务可能就是专一的只干一件事
• 微服务能够被小团队单独开发，这个小团队是2-5人的开发人员组成
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins， Hudsonbamboo
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML， css或其他界面混合
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库
  

缺点：

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度，随着服务的增加，运维的压力也在增大（本来all in one就水平的负载均衡就好了，现在可能要几十个上百个服务一个一个包去发布）
• 系统部署依赖
• 服务间通信成本
• 数据一致性
• 系统集成测试
• 性能监控…

2.4、微服务的技术栈有哪些

一部分：

微服务条目	落地技术
服务开发	SpringBoot，Spring，SpringMVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka， Consul， Zookeeper等
服务调用	Rest（RestFul风格）， RPC， gRPC（谷歌的RPC）
服务熔断器	Hystrix. Envoy等
负载均衡	Ribbon， Nginx等
服务接口调用(客户端调用服务的简化工具)	Feign、dubbo等
消息队列	Kafka， RabbitMQ ActiveMQ等
服务配置中心管理	SpringCloudConfig， Chef等（远程配置，配置可以放在github上，从而让本地发生变化）
服务路由(API网关)	Zuul等
服务监控	Zabbix. Nagios， Metrics， Specatator等
全链路追踪	Zipkin. Brave， Dapper等
服务部署	Docker（主要学这个）. OpenStack， Kubernetes等
数据流操作开发包	SpringCloud Stream(封装与Redis， Rabbit， Kafka等发送接收消息)
事件消息总线	SpringCloud Bus

2.5、为什么要选择SpringCloud作为微服务的架构

1、选型依据

• 整体解决方案和框架成熟度
• 社区热度（比如GitHub更新频率高）
• 可维护性
• 学习曲线（学习使用难度并不高，只需要几个注解就行了，但是要精通还可以更加深入学习）
  2、当前各大IT公司用的微服务架构有哪些
• 阿里： dubbo+HFS
• 京东： JSF
• 新浪： Motan
• 当当网：Dubbox
  3、各微服务架构对比

功能点/服务框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/Dubbox
功能定位	完整的微服务框架	RPC框架,但整合了ZK或Consul,实现集群环境的基本服务注册/发现	RPC框架	RPC框架	服务框架
支持Rest	是, Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否（但可以跟dubbo兼容）	是(Hession2)	是	是	是
支持多语言	是(Rest形式)	否	是	是	否
负债均衡	是(服务端2uul+客户端负载 Ribbon) , zul-服务,动态路由,云端负载均衡Eureka (针对中间层服务器)	是(客户端)	否	否	是(客户端)
配置服务	Netfix Archaius, SpringCloud Config Server集中配置	是（zookeeper提供）	否	否	否
服务调用链监控	是(zuul) , zuul提供边缘服务, API网关	否	否	否	否
高可用/容错	是(服务端Hystrix+客户端 Ribbon)	是(客户端)	否	否	是(客户端)
典型应用案例	Netflix	sina	Google	Facebook
社区活跃程度	高	一般	高	一般	2017年后重新开始维护,之前中断了5年
学习难度	中断	低	高	高	低
文档丰富程度	高	一般	一般	一般	高
其他	Spring Cloud Bus为我们的应用程序带来了更多管理端点	支持降级	Netflix内部在开发集成gRPC	IDL定义	实践的公司比较多

dubbo为什么断了5年后面再说

一般现在公司做技术选型一般用NetFlix，第二套就是Dubbo+Zookeeper因为他是RPC的，然后现在尝试着想转alibaba万一他做的特别稳定而且实践性和口碑特别好就会转

三、SpringCloud入门概述

3.1、SpringCloud是什么

spring官网
现代化的Java开发，构建微服务SpringBooot，协调治理微服务架构SpringCloud
Data Flow是跟物联网相关的

分析一下官网这个图
API Gateway：API网关，所有请求进来经过这个网关，网关负责你该怎么调用怎么处理
dashboard：服务出现问题了之后该怎么办
micoservices：微服务，一个个服务都是放在中间的
service registry：服务注册中心
distributed tracing：分布式跟踪
message brokers：消息队列
databasees：数据库

SpringCloud，基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

SpringCloud利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发， SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等，他们都可以用SpringBoot的开发风格做到一键启动和部署。

SpringBoot并没有重复造轮子，它只是将目前各家公司开发的比较成熟，经得起实际考研的服务框架组合起来，通过SpringBoot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包（离原理越来越远了，排错能力很重要）

Springcloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

3.2、SpringCloud和SpringBoot关系

• SpringBoot专注于快速方便的开发单个个体微服务。 （说白了就是一个个jar包，然后到服务器上运行）
• SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供:配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。
• SpringBoot可以离开SpringCloud独立使用，开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系
• SpringBoot专注于快速、方便的开发单个个体微服务， SpringCloud关注全局的服务治理框架

3.3、Dubbo和SpringCloud技术选型

1、分布式+服务治理Dubbo

人去访问一个网站中间有一个网关，网关中间可能还有CDN（加速器）

负载均衡有很多层比如Lvs等然后才到Nginx

Nginx也可以水平拆分

服务一般是微服务他是以集群的形式运行在机器上

分布式文件系统，服务器要跟文件打交道

tomcat（服务消费者）会去注册中心获取服务

服务提供者：Dubbo-admin 需要去注册中心注册

数据库水平拆分（读，多个节点具有一致的功能）跟竖着拆分（写）不一样的，竖着拆分可以读写分离
读数据只要水平扩展就行了
读写分离的原因是因为写是要占用io资源的，读是非常快的

MyCat：同步，保证数据库之间数据的一致性

假设有些数据是高频的比如说一些微博热搜，服务提供者在连接数据库之前中间肯定还会有缓存机制，不会所有的读的数据都放在数据库里面

缓存到服务器之间可能还会有MQ：消息中间件，队列机制让请求排队，异步处理。

目前成熟的互联网架构：应用服务化拆分+消息中间件

2、Dubbo和SpringCloud对比

可以看一下社区活跃度
https://github.com/dubbo
https://github.com/spring-cloud
可以看到dubbo活跃度更新很低，跟springcloud刚好成反比
结果：

	Dubbo	Spring
服务注册中心	Zookeeper	Spring Cloud Netfilx Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

Http的RestFul通信方式，在springboot就有大量的resttemplate类
最大区别： SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。
严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约（链接），不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

品牌机与组装机的区别
很明显， Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的明星项目，它也能够与SpringFramework. Spring Boot， Spring Data， Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题;而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。
（springcloud更简单稳定全面，Dubbo各环节选型自由度高但是需要是高手才能玩得溜）

社区支持与更新力度
最为重要的是， DUBBO停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级(比如当当网弄出了DubboX) ，这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。

设计模式 + 微服务拆分思想
总结：
曾风靡国内的开源RPC服务框架Dubbo在重启维护后，令许多用户为之雀跃，但同时，也迎来了一些质疑的声音。互联网技术发展迅速， Dubbo是否还能跟上时代？ Dubbo与Spring Cloud相比又有何优势和差异？是否会有相关举措保证Dubbo的后续更新频率？

解决的问题域不一样：Dubbo的定位是一款RPC框架，Spring Cloud的目标是微服务架构下的一站式解决方案

3.4、特征（Spring Cloud能干什么）

Spring Cloud致力于为典型的用例和扩展机制提供良好的开箱即用体验，以涵盖其他用例。

• Distributed/versioned configuration（分布式/版本化配置）

• Service registration and discovery（服务注册和发现）

• Routing（路由）

• Service-to-service calls（服务到服务的通话）

• Load balancing（负载均衡）

• Circuit Breakers（断路器）

• Global locks（全局锁）

• Leadership election and cluster state（领导选举和集群状态）

• Distributed messaging（分布式消息传递）

Spring Cloud采用了一种非常声明性的方法，通常只需更改类路径和/或注释即可获得许多功能。作为发现客户端的示例应用程序：

@SpringBootApplication
@EnableDiscoveryClient
public class Application {
	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}
}

其实就在springboot的启动类上加了个注解

@EnableDiscoveryClient

3.5、SpringCloud在哪下

官网：https://spring.io/projects/spring-cloud#learn
这玩意的版本号有点特别

spring cloud是一个由众多独立子项目组成的大型综合项目，每个子项目有不同的发行节奏，都维护着自己的发布版本号。spring cloud通过一个资源清单BOM (Bi71 of Materials)来管理每个版本的子项目清单。为避免与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。

这些版本名称的命名方式采用了伦敦地铁站的名称，同时根据字母表的顺序来对应版本时间顺序，比如:最早的Release版本: Ange7，第二个Release版本: Brixton，然后是camden、Dalston、Edgware， 目前最新的是Finchley版本。

参考书：

• NetFilx中文文档：https://springcloud.cc/spring-cloud-netflix.html

• 中文API文档:：https://springcloud.cc/spring-cloud-dalston.html

• 中国社区：http://springcloud.cn/

• 中文网：https://springcloud.cc

上面和大家聊了这么多，希望大家能够认真吸收，这就是大家能够在面试中和别人的谈资。而且好像我也没说什么废话，之后的代码都会和上面的理论挂钩!所以需要认真掌握哈

3.6、SpringCloud版本选择

大版本说明
. 1.5.x.x兼容Spring Boot 1.5.x,不兼容Spring Boot 2.0.x.x1

Spring Boot	Spring Cloud	关系
1.2.x	Angel版本(天使)	兼容Spring Boot 1.2
1.3.x	Brixton版本(布里克斯顿)	兼容Spring Boot 1.3.x,也兼容Spring Boot 1.4.x
1.4.x	Camden版本(卡姆登)	兼容Spring Boot 1.4.x,也兼容Spring Boot 1.5.x
1.5.x	Dalston版本(多尔斯顿)	兼容Spring Boot 1.5.x,不兼容Spring Boot 2.0.x
1.5.x	Edgware版本(埃奇韦尔)	兼容Spring Boot 1.5.x,不兼容Spring Boot 2.0.x
2.0.x	Finchley版本(芬奇利)	兼容Spring Boot 2.0.x,不兼容Spring Boot 1.5
2.1.x	Greenwich版本(格林威治)
2.2.x	Hoxton版本(霍斯顿)

实际开发版本关系

建议两者都用最新的吧，用最新的几乎不会错版本问题

四、服务提供者

4.1、创建一个父项目

• 新建父工程项目springcloud，切记Packageing是pom模式
• 主要是定义POM文件，将后续各个子模块公用的jar包等统一提取出来，类似一个抽象父类
  1、创建一个maven项目
  

既然是父项目就不需要src包，删掉

pom.xml
正常的打包方式是jar包

其他配置可以到SpringCloud中文文档里面找

因为是总项目所以是最外层是dependencyManagment
里面的依赖都以pom和import的方式导进来


配置参数版本号：

4.2、创建实体类api子项目

就直接用普通的maven项目即可

pom文件的父配置是是之前创建的springcloud的pom文件
然后可以在子模板里面配置自己需要的依赖，如果父依赖中已经配置了版本，这里就不用写了。

然后父项目的pom文件就会出来一个module

4.3、连接数据库

idea连接mysql数据库，首先测试是否连接成功，因为可能出现时区问题

如果出现Server returns invalid timezone. Go to ‘Advanced’ tab and set 'serverTimezone’的错误
可以到数据库里面执行以下sql语句

//查看mysql安装地址
show VARIABLES like '%char%'
//查看时区
show variables like '%time_zone%';
//修改时区为东8区
set global time_zone='+8:00';

创建一个数据库：

创表的话可以直接在idea里面创比较快


创建表

插入数据

查询

4.4 实体类编写

分布式两个问题：
第一步网络，第二部序列化，如果没有实现序列化到时候传输肯定会报一个错误

这个数据存在那个数据库的字段，微服务架构一个服务对应一个数据库，也可以同一个信息存入不同数据库

链式写法：

dept.setDeptNo(11).setDname("sss");

等于

dept.setDeptNo(11);
dept.setDname('ssss');

4.5 创建一个服务提供者8001

创建一个部门服务提供者，端口号设置为8001

maven约定大于配置大于编码，所以接下来我们继续配置一些依赖

首先导入一下这个类需要的模块
1、我们需要拿到实体类，所以要配置刚刚写的api module
2、在父依赖里面不需要写版本号可以直接继承

3、除此之外，还可以加一些依赖比如springboot的test，或者jetty，也可以不用写在idea快速生成springboot项目直接勾选亦可
版本号在引入的时候也可以不写，因为父项目有指定springboot的版本号，如果右侧maven projects显示unnull再自己指定版本号
jetty可以作位应用服务器启动可以代替tomcat
web项目还需要一个web启动器
springboot热部署工具，推荐使用idea插件JRebel

依赖写完了接下来写配置
创建一个yml文件

• 设置一个端口号8001
• mybatis别名包配置之前api module的pojo路径即可
• mybatis mapper配置的地址，首先在resources下创建一个包mybatis.mapper，路径指定为是类路径下的mybatis.mapper
• mybaits配置地址，在resources.mybatis下面创建一个mybaits-config.xml的文件然后配置类路径下面的指定路径即可
• 接下来配置spring的配置：
• 项目名字
• 数据源类型
  
• 数据源驱动类
• url：jdbc:mysql://localhost:3306/db01后面至少配上useUnicode=true&characterEncoding=utf-8
• 接下来配置好数据库用户名和密码即可
  

配置mybatis-config.xml


然后开启二级缓存


首先创建一个包com.kuang.spring.cloud，文件DeptDao
其中Dept这个实体类是在另一个服务模块的，是通过pom依赖导入进来的

写好持久层接口接下来要去写对应的mapper文件，在mapper包下面
创建一个文件，把mybatis-config.xml里面的东西粘过来然后把configuration改成mapper删除中间的settings即可


然后在mapper里面绑定一下namespace，就是对应的持久层接口的全限定类名，接下来写sql语句

dao层写完了接下来写service层，跟dao层同级
先写接口，跟dao层是长得一样的，直接把dao层内容粘过来即可

然后可以创建一个impl实现类的包，也可以直接写在service同包下面
实现刚刚的接口，重写他的三个方法，然后调dao层加注解@Autowired
类上面加个@Service注解，然后上层调下层

接下来写controller控制层的东西
在同级的包下面创建一个controller包
controller提供Restful服务
类注解@RestController，因为都是以json格式传输没有前端页面
controller层调用service层
addDept提交请求用post提交，因为用get不安全
查询可以用get提交

接下来写个启动类，直接用springboot创建项目的不用写，这里用的是maven创建的项目

测试：
list的时候因为还是post请求所以报错，改成get请求正常

五、服务消费者

创建一个消费者模块springcloud-consumer-dept-80

消费者首先pom导包
思考：
1、不需要连数据库
2、只需要一些实体类+web

然后加上热部署什么的从刚刚的提供者模块pom文件里面拷贝就行了

配置yml文件
配置一个端口号：80即可

然后创建一个根目录com.kuang.springcloud
在这下面创建一个controller包

理解：消费者，不应该有service层，那么service该怎么拿呢？

springboot支持RestFul风格

搜索RestTemplate类查看一下源代码
在springboot里面模板就有对应的请求基本上相当于底层工具类，比如jdbctemplate、mybatistemplate等，供我们直接调用

要使用这个template要把它注入到spring中

创建一个config包和类
@Configuration相当于之前的spring的applicationContext.xml原来是在这里配bean
@Bean注解

我们需要用restful风格去请求他
注入使用RestTemplate 使用注解@Autowired
我们现在没有service层，但是我们要调用远程的服务

请求提供者的地址前缀都是固定的，那么设置成一个常量写死
getForObject和返回一个Entity是差不多的只是object是通用的

post比get多一个请求数据的参数

@Controller可以改成RestController

RestTemplate，提供多种便捷访问远程http的方法，简单的RestFul服务模板，是spring提供的一个模板

然后写个启动类测试一下：
启动8001服务提供模块和80消费端模块

这边用的是消费者模块的查询全部，不用写端口号因为80端口是默认的

这就是RestFul http基于RPC的一个本质的区别
以前dubbo+zookeeper操作比较复杂，现在只需要知道远程的一个url地址即可

dubbo+zookeeper，需求前提：1、我们需要消费者和提供者有相同的接口 2、我们的消费者去远程Reference引用，需要去注册中心拿服务