建设银行河北省分行网站,如何给一个网站做定时的更新,成都网站建设交易,755权限 wordpressSpring Cloud
Spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发#xff0c;如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等#xff0c;都可以用 spring boot 的开发风格做到一键启动和部署。…Spring Cloud
Spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等都可以用 spring boot 的开发风格做到一键启动和部署。 SpringBoot是Spring推出用于解决传统框架配置文件冗余装配组件繁杂的基于Maven的解决方案旨在快速搭建单个微服务SpringCloud是依赖于SpringBoot的而SpringBoot并不是依赖与SpringCloud甚至还可以和Dubbo进行优秀的整合开发。
MartinFlower 提出的微服务之间是通过RestFulApi进行通信具体实现
RestTemplate基于HTTP协议。Feign封装了ribbon和Hystrix 、RestTemplate 简化了客户端开发工作量。RPC基于TCP协议序列化和传输效率提升明显。MQ异步解耦微服务之间的调用。
Spring Boot
Spring Boot 通过简单的步骤就可以创建一个 Spring 应用。Spring Boot 为 Spring 整合第三方框架提供了开箱即用功能。Spring Boot 的核心思想是约定大于配置。
SpringBoot解决的问题
搭建后端框架时需要手动添加 Maven 配置涉及很多 XML 配置文件增加了搭建难度和时间成本。将项目编译成 war 包部署到 Tomcat 中项目部署依赖 Tomcat这样非常不方便。应用监控做的比较简单通常都是通过一个没有任何逻辑的接口来判断应用的存活状态。
SpringBoot的优点
自动装配Spring Boot 会根据某些规则对所有配置的 Bean 进行初始化。可以减少了很多重复性的工作。比如使用 MongoDB 时只需加入 MongoDB 的 Starter 包然后配置 的连接信息就可以直接使用 MongoTemplate 自动装配来操作数据库了。简化了 Maven Jar 包的依赖降低了烦琐配置的出错几率。内嵌容器Spring Boot 应用程序可以不用部署到外部容器中比如 Tomcat。应用程序可以直接通过 Maven 命令编译成可执行的 jar 包通过 java-jar 命令启动即可非常方便。应用监控Spring Boot 中自带监控功能 Actuator可以实现对程序内部运行情况进行监控。比如 Bean 加载情况、环境变量、日志信息、线程信息等。当然也可以自定义跟业务相关的监控通过Actuator 的端点信息进行暴露。
自定义一个Starter 1、创建 Starter 项目定义 Starter 需要的配置Properties类比如数据库的连接信息。 2、编写自动配置类自动配置类就是获取配置根据配置来自动装配 Bean。 3、编写 spring.factories 文件加载自动配置类Spring 启动的时候会扫描 spring.factories 文件。 4、编写配置提示文件 spring-configuration-metadata.json不是必须的在添加配置的时候我们想要知道具体的配置项是什么作用可以通过编写提示文件来提示。 5、在项目中引入自定义 Starter 的 Maven 依赖增加配置值后即可使用。
Spring Boot Admin将 actuator 提供的数据进行可视化
显示应用程序的监控状态、查看 JVM 和线程信息。应用程序上下线监控 。可视化的查看日志、动态切换日志级别。HTTP 请求信息跟踪等实用功能。
GateWay / Zuul
GateWay⽬标是取代Netflflix Zuul它基于Spring5.0SpringBoot2.0WebFlux等技术开发提供统⼀的路由⽅式反向代理并且基于 Filter(定义过滤器对请求过滤完成⼀些功能) 链的⽅式提供了⽹关基本的功能例如鉴权、流量控制、熔断、路径重写、⽇志监控。
组成
路由route ⽹关最基础的⼯作单元。路由由⼀个ID、⼀个⽬标URL、⼀系列的断⾔匹配条件判断和Filter过滤器组成。如果断⾔为true则匹配该路由。断⾔predicates参考了Java8中的断⾔Predicate匹配Http请求中的所有内容类似于nginx中的location匹配⼀样如果断⾔与请求相匹配则路由。过滤器filter标准的Spring webFilter使⽤过滤器在请求之前或者之后执⾏业务逻辑。请求前pre类型过滤器做参数校验、权限校验、流量监控、⽇志输出、协议转换等请求前post类型的过滤器做响应内容、响应头的修改、⽇志的输出、流量监控等。 GateWayFilter 应⽤到单个路由路由上 、GlobalFilter 应⽤到所有的路由上。
Eureka / Zookeeper
服务注册中⼼本质上是为了解耦服务提供者和服务消费者为了⽀持弹性扩缩容特性⼀个微服务的提供者的数量和分布往往是动态变化的。
Eureka通过⼼跳检测、健康检查和客户端缓存等机制提⾼系统的灵活性、可伸缩性和可⽤性。 1、us-east-1c、us-east-1dus-east-1e代表不同的机房每⼀个Eureka Server都是⼀个集群。 2、Service作为服务提供者向Eureka中注册服务Eureka接受到注册事件会在集群和分区中进⾏数据同步Client作为消费端服务消费者可以从Eureka中获取到服务注册信息进⾏服务调⽤。 3、微服务启动后会周期性地向Eureka发送⼼跳默认周期为30秒以续约⾃⼰的信息Eureka在⼀定时间内默认90秒没有接收到某个微服务节点的⼼跳Eureka将会注销该微服务节点。 4、Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉服务消费者依然可以使⽤缓存中的信息找到服务提供者。
Eureka缓存 新服务上线后服务消费者不能立即访问到刚上线的新服务需要过⼀段时间后才能访问或是将服务下线后服务还是会被调⽤到⼀段时候后才彻底停⽌服务访问前期会导致频繁报错 服务注册到注册中⼼后服务实例信息是存储在Registry表中的也就是内存中。但Eureka为了提⾼响应速度在内部做了优化加⼊了两层的缓存结构将Client需要的实例信息直接缓存起来获取的时候直接从缓存中拿数据然后响应给 Client。
第⼀层缓存是readOnlyCacheMap采⽤ConcurrentHashMap来存储数据的主要负责定时与readWriteCacheMap进⾏数据同步默认同步时间为 30 秒⼀次。第⼆层缓存是readWriteCacheMap采⽤Guava来实现缓存。缓存过期时间默认为180秒当服务下线、过期、注册、状态变更等操作都会清除此缓存中的数据。如果两级缓存都无法查询会触发缓存的加载从存储层拉取数据到缓存中然后再返回给 Client。Eureka之所以设计⼆级缓存机制也是为了提⾼ Eureka Server 的响应速度缺点是缓存会导致 Client获取不到最新的服务实例信息然后导致⽆法快速发现新的服务和已下线的服务。
解决方案
我们可以缩短读缓存的更新时间让服务发现变得更加及时或者直接将只读缓存关闭同时可以缩短客户端如ribbon服务的定时刷新间隔多级缓存也导致C层⾯数据⼀致性很薄弱。Eureka Server 中会有定时任务去检测失效的服务将服务实例信息从注册表中移除也可以将这个失效检测的时间缩短这样服务下线后就能够及时从注册表中清除。
自我保护机制开启条件
期望最小每分钟能够续租的次数实例* 频率 * 比例10* 2 *0.85。期望的服务实例数量10。
健康检查
Eureka Client 会定时发送心跳给 Eureka Server 来证明自己处于健康的状态。集成SBA以后可以把所有健康状态信息一并返回给eureka。
Feign / Ribbon
Feign 可以与 Eureka 和 Ribbon 组合使用以支持负载均衡。Feign 可以与 Hystrix 组合使用支持熔断回退。Feign 可以与ProtoBuf实现快速的RPC调用。 InvocationHandlerFactory 代理采用 JDK 的动态代理方式生成代理对象当我们调用这个接口实际上是要去调用远程的 HTTP API。Contract 契约组件比如请求类型是 GET 还是 POST请求的 URI 是什么。Encoder 编码组件 \ Decoder 解码组件通过该组件我们可以将请求信息采用指定的编码方式进行编解码后传输。Logger 日志记录负责 Feign 中记录日志的可以指定 Logger 的级别以及自定义日志的输出。Client 请求执行组件负责 HTTP 请求执行的组件Feign 中默认的 Client 是通过 JDK 的 HttpURLConnection 来发起请求的在每次发送请求的时候都会创建新的 HttpURLConnection 链接Feign 的性能会很差可以通过扩展该接口使用 Apache HttpClient 等基于连接池的高性能 HTTP 客户端。Retryer 重试组件负责重试的组件Feign 内置了重试器当 HTTP 请求出现 IO 异常时Feign 会限定一个最大重试次数来进行重试操作。RequestInterceptor 请求拦截器可以为 Feign 添加多个拦截器在请求执行前设置一些扩展的参数信息。
Feign最佳使用技巧
继承特性。拦截器 比如添加指定的请求头信息这个可以用在服务间传递某些信息的时候。GET请求多参数传递。日志配置 FULL 会输出全部完整的请求信息。异常解码器 异常解码器中可以获取异常信息而不是简单的一个code然后转换成对应的异常对象返回。源码查看是如何继承HystrixHystrix Feign.builder 中可以看到继承了 Feign 的 Builder增加了 Hystrix的SetterFactory build 方法里对 invocationHandlerFactory 进行了重写 create 的时候返回HystrixInvocationHandler 在 invoke 的时候会将请求包装成 HystrixCommand 去执行这里就自然的集成了 Hystrix。
Ribbon 使用方式
原生 APIRibbon 是 Netflix 开源的没有使用 Spring Cloud需要使用 Ribbon 的原生 AP。Ribbon RestTemplate整合Spring Cloud 后可以基于 RestTemplate 提供负载均衡的服务。Ribbon Feign。 负载均衡算法
RoundRobinRule 是轮询的算法A和B轮流选择。RandomRule 是随机算法这个就比较简单了在服务列表中随机选取。BestAvailableRule 选择一个最小的并发请求 server。
自定义负载均衡算法
实现 Irule 接口。继承 AbtractLoadBalancerRule 类。
自定义负载均衡使用场景核心
灰度发布 灰度发布是能够平滑过渡的一种发布方式在发布过程中先发布一部分应用让指定的用户使用刚发布的应用等到测试没有问题后再将其他的全部应用发布。如果新发布的有问题只需要将这部分恢复即可不用恢复所有的应用。多版本隔离 多版本隔离跟灰度发布类似为了兼容或者过度某些应用会有多个版本这个时候如何保证 1.0 版本的客户端不会调用到 1.1 版本的服务就是我们需要考虑的问题。故障隔离 当线上某个实例发生故障后为了不影响用户我们一般都会先留存证据比如线程信息、JVM 信息等然后将这个实例重启或直接停止。然后线下根据一些信息分析故障原因如果我能做到故障隔离就可以直接将出问题的实例隔离不让正常的用户请求访问到这个出问题的实例只让指定的用户访问这样就可以单独用特定的用户来对这个出问题的实例进行测试、故障分析等。
Hystrix / Sentinel
服务雪崩场景 自己即是服务消费者同时也是服务提供者同步调用等待结果导致资源耗尽。
解决方案 服务方扩容、限流排查代码问题增加硬件监控。 消费方使用Hystrix资源隔离熔断降级快速失败。 Hystrix断路保护器的作用
封装请求会将用户的操作进行统一封装统一封装的目的在于进行统一控制。资源隔离限流会将对应的资源按照指定的类型进行隔离比如线程池和信号量。 计数器限流例如5秒内技术1000请求超数后限流未超数重新计数。滑动窗口限流解决计数器不够精确的问题把一个窗口拆分多滚动窗口。令牌桶限流类似景区售票售票的速度是固定的拿到令牌才能去处理请求。漏桶限流生产者消费者模型实现了恒定速度处理请求能够绝对防止突发流量。 失败回退其实是一个备用的方案就是说当请求失败后有没有备用方案来满足这个请求的需求。断路器这个是最核心的如果断路器处于打开的状态那么所有请求都将失败执行回退逻辑。如果断路器处于关闭状态那么请求将会被正常执行。有些场景我们需要手动打开断路器强制降级。指标监控会对请求的生命周期进行监控请求成功、失败、超时、拒绝等状态都会被监控起来。
Sentinel Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。替代Hystrix针对问题服务雪崩、服务降级、服务熔断、服务限流。 Hystrix区别
独⽴可部署Dashboard基于 Spring Boot 开发控制台组件。不依赖任何框架/库减少代码开发通过UI界⾯配置即可完成细粒度控制。 丰富的应⽤场景Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景例如秒杀、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。完备的实时监控可以看到500 台以下规模的集群的汇总也可以看到单机的秒级数据。⼴泛的开源⽣态与 SpringCloud、Dubbo的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊ Sentinel。 区别Sentinel不会像Hystrix那样放过⼀个请求尝试⾃我修复就是明明确确按照时间窗⼝来熔断触发后时间窗⼝内拒绝请求时间窗⼝后就恢复。Sentinel Dashboard中添加的规则数据存储在内存微服务停掉规则数据就消失在⽣产环境下不合适。可以将Sentinel规则数据持久化到Nacos配置中⼼让微服务从Nacos获取。 Config / Nacos
Nacos是阿⾥巴巴开源的⼀个针对微服务架构中服务发现、配置管理和服务管理平台。Nacos就是注册中⼼配置中⼼的组合NacosEurekaConfifigBus。 Nacos功能特性
服务发现与健康检查。动态配置管理。动态DNS服务。服务和元数据管理。
保护阈值 当服务A健康实例数/总实例数 保护阈值 的时候说明健康实例真的不多了这个时候保护阈值会被触发状态truenacos将会把该服务所有的实例信息健康的不健康的全部提供给消费者消费者可能访问到不健康的实例请求失败但这样也⽐造成雪崩要好牺牲了⼀些请求保证了整个系统的⼀个可⽤。
Nacos 数据模型领域模型
Namespace 代表不同的环境如开发dev、测试test、⽣产环境prod。Group 代表某项⽬⽐如xx云项⽬。Service 某个项⽬中具体xxx服务。DataId 某个项⽬中具体的xxx配置⽂件。
可以通过 Spring Cloud 原⽣注解 RefreshScope 实现配置⾃动更新。
Bus / Stream
Spring Cloud Stream 消息驱动组件帮助我们更快速更⽅便的去构建消息驱动微服务的本质屏蔽掉了底层不同MQ消息中间件之间的差异统⼀了MQ的编程模型降低了学习、开发、维护MQ的成本⽬前⽀持Rabbit、Kafka两种消息。
Sleuth / Zipkin Trace ID当请求发送到分布式系统的⼊⼝端点时Sleuth为该请求创建⼀个唯⼀的跟踪标识Trace ID在分布式系统内部流转的时候框架始终保持该唯⼀标识直到返回给请求⽅。Span ID为了统计各处理单元的时间延迟当请求到达各个服务组件时也是通过⼀个唯⼀标识SpanID来标记它的开始具体过程以及结束。
Spring Cloud Sleuth 追踪服务框架可以追踪服务之间的调⽤Sleuth可以记录⼀个服务请求经过哪些服务、服务处理时⻓等根据这些我们能够理清各微服务间的调⽤关系及进⾏问题追踪分析。 耗时分析通过 Sleuth 了解采样请求的耗时分析服务性能问题哪些服务调⽤⽐较耗时。 链路优化发现频繁调⽤的服务针对性优化等。 聚合展示数据信息发送给 Zipkin 进⾏聚合利⽤ Zipkin 存储并展示数据。
安全认证
Session 认证中最常用的一种方式也是最简单的。存在多节点session丢失的情况可通过nginx粘性Cookie和Redis集中式Session存储解决。HTTP Basic Authentication HTTP Basic AuthenticationToken Session 只是一个 key会话信息存储在后端。而 Token 中会存储用户的信息然后通过加密算法进行加密只有服务端才能解密服务端拿到 Token 后进行解密获取用户信息。JWT认证 JWTJSON Web Token用户提供用户名和密码给认证服务器服务器验证用户提交信息的合法性如果验证成功会产生并返回一个 Token用户可以使用这个 Token 访问服务器上受保护的资源。 1、认证服务提供认证的 API校验用户信息返回认证结果。 2、通过JWTUtils中的RSA算法生成JWT tokentoken里封装用户id和有效期。 3、服务间参数通过请求头进行传递服务内部通过 ThreadLocal 进行上下文传递。 4、Hystrix导致ThreadLocal失效的问题可以通过重写 Hystrix 的 Callable 方法传递需要的数据。
Token最佳实践
设置较短合理的过期时间。注销的 Token 及时清除放入 Redis 中做一层过滤。虽然不能修改 Token 的信息但是能在验证层面做一层过滤来进行处理。监控 Token 的使用频率。为了防止数据被别人爬取最常见的就是监控使用频率程序写出来的爬虫程序访问频率是有迹可循的。核心功能敏感操作可以使用动态验证验证码。比如提现的功能要求在提现时再次进行验证码的验证防止不是本人操作。网络环境、浏览器信息等识别。银行 APP 对环境有很高的要求使用时如果断网APP 会自动退出重新登录因为网络环境跟之前使用的不一样了还有一些浏览器的信息之类的判断这些都是可以用来保证后端 API 的安全。加密密钥支持动态修改。如果 Token 的加密密钥泄露了也就意味着别人可以伪造你的 Token可以将密钥存储在配置中心以支持动态修改刷新需要注意的是建议在流量低峰的时候去做更换的操作否则 Token 全部失效所有在线的请求都会重新申请 Token并发量会比较大。
灰度发布
痛点
服务数量多业务变动频繁一周一发布。灰度发布能降低发布失败风险减少影响范围。通过灰度发布先让一部分用户体验新的服务或者只让测试人员进行测试等功能正常后再全部发布这样能降低发布失败带来的影响范围。当发布出现故障时可以快速回滚不影响用户。灰度后如果发现这个节点有问题那么只需回滚这个节点即可当然不回滚也没关系通过灰度策略隔离也不会影响正常用户。
可以通过Ribbon的负载均衡策略进行灰度发布可以使用更可靠的Discovery。
Discovery 基于Discovery 服务注册发现、Ribbon 负载均衡、Feign 和 RestTemplate 调用等组件的企业级微服务开源解决方案包括灰度发布、灰度路由、服务隔离等功能。 1、首先将需要发布的服务从转发过程中移除等流量剔除之后再发布。 2、部分机器中的版本进行升级用户默认还是请求老的服务通过版本来支持测试请求。 3、测试完成之后让新的版本接收正常流量然后部署下一个节点以此类推。
