springboot/springcloud

面向架构（思维方式） java 面向对象 ESB总线 config config配置中心 api网关 zuul怪兽网关
cloud的核心技术都是netflix出品 springcloud作为大平台出处
eureka（收费的趋势）
hystrix刺猬断路器
ribbon 负载均衡 类似nginx
sidecar 支撑异构语言 nodejs大前端
nginx c语言+lua
rabbitmq erlang 最早的并发语言
docker go 最新的并发语言
java不是天生支持多核的语言 91年 go四核
feign REST方式 接口体现
java生态链

plugins能自动起web服务的jar

旧方式 打war包
springboot 自动启动服务（不可能把编译器带到服务器里去） plugin插件 在dos下直接运行jar

敏捷开发。
和ssm整合。
继承springboot的父工程
mybatis注解，访问数据库，添加依赖，pom.xml
Spring，service层，和启动类同级扫描。无需配置
SpringMVC
yml文件 首行缩进不能用Tab 冒号后面用空格

MapperScan 注明映射路径

pom里常用的工具有默认的标准版本号，部分不常用需要手动指定。

SpringCloud：
Eureka和ZooKeeper分布式设计定理：CAP
Ribboon 负载均衡器 nginx；前端
Feign 封装REST 接口

为什么需要SpringCloud？
dubbo阿里出品的微服务框架；三室两厅：基于RPC+ZK+dubbox
SpingCloud Spring出品；别墅：Eureka、Ribbon、Feign支持REST、Zuul API网关，Hystrix断路器，Sidecar异构语言

选择了springCloud；开源。
dubbo基于RPC，优点底层是二进制，安全性，性能，可压缩。官宣：SpringCloud的子集专注于RPC解决方案。

微服务
业务垂直拆分的更细，数据库也拆分，故障隔离。
微服务不同服务器，服务器之前的调用，要走网络传输，安全性和性能都打折扣。也有缺陷。
服务之间互相调用频繁还不如不拆，结合。需要在整体间找平衡感。

Eureka
Consistency（一致性） 一处修改了全都修改了
数据库是强一致性的产品，三范式（3NF）主键、不允许重复列、列不能是加工而成。
设计了主键，主键不能重复（比如身份证号）。
重复的列。

主流数据库表的设计方式，反三范式，冗余设计（为了保证查询的效率，单表查询比连表查询效率高，
数据多处同步数据有时间差，短暂时间数据不一致）。

强一致性，一处修改了全部都同步改了。

Availability
Zk（可用性）
一半节点宕机或者正在有节点在选举，那么zk集群都不可用。业务没倒，zk倒了，也不能用。主从设计。
leader和follower 重新选举
Eureka
点对点设计，每个点都有信息备份，信息变化内部都会自动同步所有的数据。即使所有的节点都宕机，仍然能提供服务。
客户端会缓存所有的数据信息，也能找到服务提供者。业务上宕机了，也有备份缓存，可用性更高。

心跳机制，动态维护。
注册中心的信息不会频繁发生变化。

Partition分区容错性
并发下短暂时间内允许错误，过了时间自动恢复。（消息队列消化，支付宝支付2小时后到账）
最终一致性。

ZK是基于CP，侧重于一致性
Eureka基于AP，侧重于可用性

创建cloud的maven工程
添加cloud依赖，版本号，法国地名，按字母的顺序作为高低，对应springboot的版本号

Netty NIO 非阻塞（性能快） IO，javax.concurernt并发包 api
封装了concurernt包，简洁好用。hadoop基于此做。

Ribbon负载均衡
轮询访问
1）支持能通用访问，用一个服务名字注册两个服务提供者
2）Bean初始化，LoanBalanced 激活效果

首先构建EurekaServer的服务端，即服务者
额外springcloud依赖管理
@EnableEurekaServer

在provider里启动一个EurekaClient客户端服务。