标签：中心 创建 ble 语言 不同 article limit uil 场景
中文文档：https://springcloud.cc/spring-cloud-dalston.html
1.与dubbo对比
2.服务架构
Eureka:服务注册中心,完成服务注册、发现、调用
访问https://start.spring.io 出现一直失败时,可改成http形式
Eureka Server：作为注册中心,提供给服务注册，mvn clean package后可到对应eureka项目目录下打成jar包,通过java -jar eureka.jar启动作为服务
Eureka Client:服务提供者和消费者
@EnableEurekaClient
Ribbon:完成负载均衡；RestTemplate、Feign、Zuul都使用到了Ribbon，@LoadBalanced
a.服务发现 b.服务选择 c.服务监听
ServerList获取服务列表,再通过ServerListFilter过滤部分服务,最后通过IRule选择一个实例作为最终目标
Zuul:实现网关作用,反爬虫等作用
Hystrix:实现服务熔断、降级(资源紧张时,下调非必要服务)、限流
Hystrix Dashboard:服务流量管控台
Config Server:管理配置
Sleuth：请求日志、服务请求时长等
3.请求耗时比较
4.Eureka架构：
Application Service:向Eureka Server完成服务提供
Application Client:从Eureka Server调用服务
Eureka Server:服务注册中心
分布式系统中为什么需要服务发现？
微服务的特点：异构
1.不同语言
2.不同类型的数据库
服务拆分理论：如何拆"数据"
1.每个服务都有单独的数据存储
2.依据服务特点选择不同的结构选择的数据库类型
3.难点在于边界
服务注册到eureka后,不重启无法清理服务列表？
两个提供者，分别8100和8200
6.服务如何拆分：
起点：既有架构的形态
终点：好的架构不是设计出来的，而是进化(演化)而来的
适不适合微服务？
业务形态不适合的：
1.系统中包含很多强事务场景 2.业务想对稳定、迭代周期长 3.访问压力不大，可用性要求不高
康威定律:任何组织在设计一套系统(广义概念上的系统)时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
微服务的特点：
1.一系列的微小的服务共同组成 2.单独部署，跑在自己的进程里 3.每个服务为独立的业务开发 4.分布式的管理
服务拆分的方法论：
如何拆分功能：
1.单一职责、松耦合、高内聚
2.关注点分离(职责(订单)、通用性(消息)、粒度)
服务和数据的关系：
1.先考虑业务功能，再考虑数据
2.无状态服务(有->无)
启动两个client,需要配置不同的端口，否则都会去使用8080,后启动的会报错
server配置了server.port，client如果也要配置server.port，两者端口不能一样。
7.服务间调用：
RestTemplate:
第一种：
第二种：
第三种：
Feign:注意pom依赖版本,伪RPC，声明式加注解式RPC
当无参、@RequestParam、 @PathVariable可使用GetMapping
服务调用方：
服务提供方：
应用间通信：通过客户端负载均衡器 Ribbon
1.ServerList->IRule->ServerListFilter
2.RestTemplate, Feign Zuul都用到了Ribbon(@LoadBalance)
8.配置中心：远端git->config server->本地git
a.为什么要用配置中心：不方便维护，配置内容安全与权限，更新配置项目需要重启
b.当做eureka客户端，注册到eureka，增加@EnableDiscoveryClient和@EnableConfigServer
c.git仓库创建config.yml，启动配置中心后浏览器访问：http://localhost:8080/config-a.yml(-a的a可随意,但一定要写一个)
d.客户端读取配置中心数据：配置中心config.yml可作为config-dev.yml的通用配置，不然每次都会被加载过来,但不能自动刷新
e.spring cloud bus能支持自动刷新，增加完spring-cloud-bus组件后，在rabbitmq上会相应多一个队列
config项目上增加就能暴露 /bus-refresh；客户端增加@RefreshScope
9.异步：客户端请求不会阻塞进程，服务端的响应可以是非即时的
常见形式：1.通知 2.请求/异步响应 3.消息(MQ)
MQ应用场景：1.异步处理：用户注册后发短信、加积分等 2.流量削峰：秒杀 3.日志处理(最常见kafka) 4.应用解耦：订单系统完成下单,发消息到商品服务扣库存等
rabbitMq:需管控台新建队列myQueue，增加queuesToDeclare可自动创建队列
10.maven依赖自动补全：File->setting->maven->repositories，选择本地仓库，点击右上角更新，更新maven仓库索引
springCloud对消息中间件进行封装，代码层面做到对中间件无感知，目前Binder支持rabbitmq(项目启动时会管控台会多一个myMessage队列)和kafka；
发送方：
@RestController
public class MessageProductController {
@Autowired
private StreamClient streamClient;
@GetMapping("/sendMessage")
public void process(){
streamClient.output().send(MessageBuilder.withPayload("aa").build());
}
}
接收方：以上对多台服务器接收消息会每台都收到消息，yml对一台机器增加spring.stream.bindings.myMessage.group:order防止重复消费消息
rabbitmq中的消息是base64转码过的数据，不直观，yml增加spring.stream.bindings.myMessage.content-type:application/json实现mq中json数据展示 
异步扣库存：
11.网关方案：
a.nginx(负载均衡)+lua-->Kong(扩展,商业)
b.Tyk：开源,支持认证,多用户多组织分析,go语言
c.zuul(路由+过滤器)：java+微服务,认证，协作单点压测等，快速上手,性能比nginx稍差;cookie无法传到后端；也可使用Hystrix超时配置
1.增加@EnableZuulProxy作为网关代理，访问http://ip:zuul端口/目标eureka实例/url可完成跳转；RefreshSocpe是动态加载配置中心数据
zuul.
sensitive-headers: 设置为null，所有服务都可传cookie等信息 
可实现访问全部路由：http://localhost:9000/application/routes
前置过滤器：限流、鉴权
后置过滤器：统计
高可用：多台注册
自定义token的pre过滤器：
自定义post的过滤器：
令牌桶限流：
1.在被调用的类或方法上增加@CrossOrigin注解(@CrossOrigin(allowCredentials = "true")cookie跨域传)，缺点：只针对加了注解的类或方法有效
2.在Zuul中增加ZuulFilter过滤器或者nginx中解决跨域问题
12.服务容错与Hystrix：
a.雪崩效应：a->b->c,c崩溃后，最终导致ab都不可用
b.Hystrix：
1.服务降级：网络开小差等提示，优先核心服务，非核心服务不可用或弱可用，通过HystrixCommand注解指定，fallbackMethod中实现降级逻辑
默认处理：
2.依赖隔离：
a.线程池隔离：Hstrix自动实现了依赖隔离
hystrix管控台：
有引入cloud-stream的话，就不需要再引入
yml增加management.context-path:/
最终视图：
13.服务追踪：
1.SpringCloud Sleuth：
调整Feign的日志级别：
springcloud
标签：中心 创建 ble 语言 不同 article limit uil 场景
原文地址：https://www.cnblogs.com/linzx2015/p/10888903.html
