回到目录
整个系统走向微服务架构
网关
服务注册与发现
配置中心
熔断器
链路跟踪
授权与鉴权
服务间的通讯 - 同步 feign
服务间的通讯 - 异步消息
日志收集
个系统走向微服务架构
公司系统比较多, 耦合度比较大, 将这些模块进行拆分, 各个负责自己的模块, 减少相互之间的直接依赖, 版本迭代互不影响, 做到最小粒度的部署, 这就是微服务, 也是未来软件架构与设计的一个趋势!
典型的微服务架构图
- graph TD
- client-->gateway
- gateway-->gateway1
- gateway-->gateway2
- gateway1-->user
- gateway1-->product
- gateway1-->order
网关
网关作为整个系统的门面存在, 当然一个超级大系统可能出现多个网关, 而把关系比较紧密的系统通过一个网关对外提供服务, 这是一种比较好的作法, 对前端和用户来说, 它还是一个系统, 而对于后端来说, 它是由多个子服务组成, 我们选择的网关产品是比较流行的 zuul, 而 springcloud2.0 出来后, 也推出了新的 gateway 组件, 当然无论是使用哪个网关产品, 功能都是相同的!
网关主要起到了路由, 请求过滤, 统一授权, 限流等功能
- zuul.routes.userinfo.path=/getuser/**
- zuul.routes.userinfo.serviceId=userinfo-consumer
- zuul.ratelimit.enabled=true
- zuul.ratelimit.policies.userinfo.limit=3
- zuul.ratelimit.policies.userinfo.refresh-interval=60
- zuul.ratelimit.policies.userinfo.type=origin
- # 测试客户端如果 60s 内请求超过三次, 服务端就抛出异常, 一分钟后又可以正常请求
- # 某个 IP 的客户端被限流并不影响其他客户端, 即 API 网关对每个客户端限流是相互独立的
服务注册与发现
让多个子服务进行通讯, 要求这些服务在一个网络里, 它们之间是可以互通的, 而当服务越来越多, 每个服务的端口, IP 地址也会越来越繁琐, 而这时服务注册组件就派上用场了, 它将服务的 IP 和端口与一个服务名称进行映射, 让开发人员只关注名称, application.name 即可, 而名称与真实服务的链路过程由服务注册组件实现, 我们在选择服务注册组件时, 选择了 eureka. eureka 服务端
- server:
- port: ${PORT:8761}
- management:
- port: ${BG_PORT:8762}
- application:
- name: ${NAME:eurekaserver}
- spring:
- profiles:
- active: dev
- ---
- eureka:
- profile: dev
- instance:
- hostname: ${application.name}
- perferIpAddress: true #基于 IP 地址注册
- client:
- registerWithEureka: false #false 表示不向注册中心注册自己.
- fetchRegistry: false #false 表示自己端就是注册中心, 我的职责就是维护服务实例, 并不需要去检索服务
- serviceUrl:
- defaultZone: ${URL:http://${eureka.instance.hostname}:${server.port}/eureka/}
eureka 客户端注册到服务端
- spring:
- application:
- name: gateway
- profiles:
- active: ${SPRING_PROFILES_ACTIVE:dev}
- server:
- port: 8003
- eureka:
- client:
- service-url:
- defaultZone: http://${eureka.host:localhost}:${eureka.port:6761}/eureka/,
- http://${eureka.host:localhost}:${eureka.port:5761}/eureka/
配置中心
将所有服务的配置都集中管理, 这是一个不错的想法, 当配置更新后, 不需要启动服务, 而通过消息广播的方法通讯服务即可, 这就是配置中心的作用. 之前的单体应用时, 每个应用都有自己的配置文件, 而当项目多了之后, 这些配置文件不容易管理, 要修改其中一些配置时, 需要分别进入对应的服务里, 而且这些配置也无法实现继承, 重复的代码很多, 比如很多服务都用了 rabbitmq,Redis 等, 单体应用里, 你需要复制这些配置到每个服务里, 而有了配置中心, 你只需要在 application.YAML 里进行公用配置即可, 而其它服务的配置会自动继承.
配置中心使用了加密算法保存了配置文件中的敏感信息
- server.port: ${PORT:8888}
- management.port: ${BG_PORT:8889}
- spring:
- application.name: lind-configserver
- profiles.active: development
- encrypt:
- key-store:
- location: file:///Users/lind.zhang/GitHub/dockerDeploy/swarm/server.jks
- password: changeit
- alias: config-server-key
- secret: changeit
- ---
- spring:
- profiles: svt
- cloud:
- config:
- server:
- Git:
- uri: /config_repo
- ---
- spring:
- profiles: development
- cloud:
- config:
- server:
- Git:
- uri: /config_repo
熔断器
熔断在微服务中表现非常突出, 在多个服务进行并行式调用时, 这个熔断功能就显得非常重要了, 比如 A 调用 B,A 再调用 C,A 再调用 D, 而在这个并行调用过程中, 当 B 出现问题时, 后面的 C,D 将不会执行, 而默认情况下 A 会等到 B 达到超时后才会做出响应, 而影响 A 调用其它服务, 从而导致 A 这个接口整体变慢; 而有了熔断之后, 当请求 B 接口出现问题时, 你可以有很多能策略, 如重试机制, 快速返回等.
hystrix 的基本配置, 主要是对请求超时时间的配置
- hystrix:
- command:
- default:
- execution:
- timeout:
- enabled: true
- isolation:
- strategy: SEMAPHORE #hystrix 策略为 thread 时, threadlocal 为空
- thread:
- #目前有两个容器实例, 单个请求超时 5s,+ 重试 > 10s, 超 15s 则熔断
- timeoutInMilliseconds: 15000
链路跟踪
当一个服务 A 调用服务 B 时, 服务 B 也可能会调用服务 C, 这就形成了一个链表, 在响应时的顺序是相反的, 所以这是一个双向的链表, 在这个链表里, 我们希望对它进行跟踪, 因为在一个请求出现问题时, 你很难找到问题出现在哪个环节, 所以我们的请求需要有一个 traceId 在各个服务链表间进行传递, 这就是链路跟踪的原理.
下面是链路跟踪组件 sleuth 和日志收集分析工具 zipkin 的配置
- spring:
- application:
- name: user
- sleuth:
- web:
- client:
- enabled: true
- sampler:
- probability: 1.0 # 将采样比例设置为 1.0, 也就是全部都需要. 默认是 0.1
- zipkin:
- base-url: http://localhost:9411/ # 指定了 Zipkin 服务器的地址
下次有时间再说一下剩下的内容
授权与鉴权
服务间的通讯 - 同步 feign
服务间的通讯 - 异步消息
日志收集 回到目录
来源: https://www.cnblogs.com/lori/p/11199473.html