首页 文章 精选 留言 我的

精选列表

搜索[b2b2c],共231篇文章
优秀的个人博客,低调大师

Java版Spring Cloud B2B2C o2o社交电商- zuul网关实现

一、简介 在Springcloud中用zuul来实现网关功能,客户端的请求首先经过负载均衡Ngnix,再到达服务网关(zuul集群),然后再到具体的服务。Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分,比如/api/server1转发到到server1服务。zuul默认和Ribbon结合实现了负载均衡的功能。 二、搭建 首先是POM文件 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> 然后在applicaton类加上注解@EnableZuulProxy,开启zuul的功能 @SpringBootApplication @EnableZuulProxy @EnableEurekaClient @RefreshScope public class HfzZuulApplication { public static void main(String[] args) { SpringApplication.run(HfzZuulApplication.class, args); } } yml配置如下 eureka: client: serviceUrl: defaultZone: http://name:pass@IP/eureka/ instance: ip-address: Ip地址 prefer-ip-address: true server: port: 8769 spring: application: name: service-zuul sleuth: sampler: percentage: 1.0 cloud: config: discovery: enabled: true service-id: CONFIG-SERVER label: master profile: dev name: hfz-zuul username: name password: pass 以上是在项目中配置的,为了使项目更加灵活,所以将路由的配置放在github上,这样可以动态读取 zuul: routes: api-a: path: /api-a/** serviceId: service-ribbon api-b: path: /api-b/** serviceId: service-feign 以/api-a/ 开头的请求都转发给service-ribbon服务;以/api-b/开头的请求都转发给service-feign服务; 三、服务过滤 zuul不仅可以路由,并且还能通过过滤来拦截一些服务,可以用来做安全验证。 public class MyFilter extends ZuulFilter{ private static Logger log = LoggerFactory.getLogger(MyFilter.class); @Override public String filterType() { return "pre"; } @Override public int filterOrder() { return 0; } @Override public boolean shouldFilter() { return true; } @Override public Object run() { RequestContext ctx = RequestContext.getCurrentContext(); HttpServletRequest request = ctx.getRequest(); log.info(String.format("%s >>> %s", request.getMethod(), request.getRequestURL().toString())); Object accessToken = request.getParameter("token"); if(accessToken == null) { log.warn("token is empty"); ctx.setSendZuulResponse(false); ctx.setResponseStatusCode(401); try { ctx.getResponse().getWriter().write("token is empty"); }catch (Exception e){} return null; } log.info("ok"); return null; } } filterType:返回一个字符串代表过滤器的类型,在zuul中定义了四种不同生命周期的过滤器类型,具体如下: pre:路由之前 routing:路由之时 post: 路由之后 error:发送错误调用 filterOrder:过滤的顺序 shouldFilter:逻辑判断,是否要过滤 run:过滤器的具体逻辑控制 接下来就可以测试访问了。

优秀的个人博客,低调大师

java spring cloud版b2b2c社交电商--服务网关 Spring Cloud GateWay 入门

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目,该项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。 Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关,目标是替代 Netflix Zuul,其不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。 相关概念: Route(路由):这是网关的基本构建块。它由一个 ID,一个目标 URI,一组断言和一组过滤器定义。如果断言为真,则路由匹配。 Predicate(断言):这是一个 Java 8 的 Predicate。输入类型是一个 ServerWebExchange。我们可以使用它来匹配来自 HTTP 请求的任何内容,例如 headers 或参数。 Filter(过滤器):这是org.springframework.cloud.gateway.filter.GatewayFilter的实例,我们可以使用它修改请求和响应。 工作流程: 客户端向 Spring Cloud Gateway 发出请求。如果 Gateway Handler Mapping 中找到与请求相匹配的路由,将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑,然后返回。 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前(“pre”)或之后(“post”)执行业务逻辑。 Spring Cloud Gateway 的特征: 基于 Spring Framework 5,Project Reactor 和 Spring Boot 2.0 动态路由 Predicates 和 Filters 作用于特定路由 集成 Hystrix 断路器 集成 Spring Cloud DiscoveryClient 易于编写的 Predicates 和 Filters 限流 路径重写 Spring Cloud Gateway 与 Zuul的区别: 1、Zuul 1.x,是一个基于阻塞 I/ O 的 API Gateway 2、Zuul 1.x 基于Servlet 2. 5,使用阻塞架构,它不支持任何长连接,如 WebSocket。 Zuul 的设计模式和Nginx较像,每次 I/ O 操作都是从工作线程中选择一个执行,请求线程被阻塞到工作线程完成,但是差别是Nginx 用C++ 实现,Zuul 用 Java 实现,而 JVM 本身会有第一次加载较慢的情况,使得Zuul 的性能相对较差。 3、Zuul 2.x,基于 Netty 非阻塞、支持长连接,但 Spring Cloud 目前还没有整合。 Zuul 2.x的性能较 Zuul 1.x 有较大提升。在性能方面,根据官方提供的基准测试, Spring Cloud Gateway 的 RPS(每秒请求数)是Zuul 的 1. 6 倍。 4、Spring Cloud Gateway 建立 在 Spring Framework 5、 Project Reactor 和 Spring Boot 2 之上, 使用非阻塞 API。 5、Spring Cloud Gateway 还 支持 WebSocket, 并且 与 Spring 紧密集成, 拥有更好的开发体验。

优秀的个人博客,低调大师

java B2B2C 源码 springmvc mybatis多租户电子商城系统- Stream重新入队(RabbitMQ)

本文将介绍RabbitMQ的binder提供的重试功能:重新入队 准备一个会消费失败的例子,可以直接沿用前文的工程,也可以新建一个,然后创建如下代码的逻辑: @EnableBinding(TestApplication.TestTopic.class) @SpringBootApplication public class TestApplication { public static void main(String[] args) { SpringApplication.run(TestApplication.class, args); } @RestController static class TestController { @Autowired private TestTopic testTopic; /** * 消息生产接口 * * @param message * @return */ @GetMapping("/sendMessage") public String messageWithMQ(@RequestParam String message) { testTopic.output().send(MessageBuilder.withPayload(message).build()); return "ok"; } } /** * 消息消费逻辑 */ @Slf4j @Component static class TestListener { private int count = 1; @StreamListener(TestTopic.INPUT) public void receive(String payload) { log.info("Received payload : " + payload + ", " + count); throw new RuntimeException("Message consumer failed!"); } } interface TestTopic { String OUTPUT = "example-topic-output"; String INPUT = "example-topic-input"; @Output(OUTPUT) MessageChannel output(); @Input(INPUT) SubscribableChannel input(); } } 内容很简单,既包含了消息的生产,也包含了消息消费。消息消费的时候主动抛出了一个异常来模拟消息的消费失败。 在启动应用之前,还要记得配置一下输入输出通道对应的物理目标(exchange或topic名)、并设置一下分组,比如: spring.cloud.stream.bindings.example-topic-input.destination=test-topic spring.cloud.stream.bindings.example-topic-input.group=stream-exception-handler spring.cloud.stream.bindings.example-topic-input.consumer.max-attempts=1 spring.cloud.stream.rabbit.bindings.example-topic-input.consumer.requeue-rejected=true spring.cloud.stream.bindings.example-topic-output.destination=test-topic 完成了上面配置之后,启动应用并访问localhost:8080/sendMessage?message=hello接口来发送一个消息到MQ中了,此时可以看到程序不断的抛出了消息消费异常。这是由于这里我们多加了一个配置:spring.cloud.stream.rabbit.bindings.example-topic-input.consumer.requeue-rejected=true。在该配置作用之下,消息消费失败之后,并不会将该消息抛弃,而是将消息重新放入队列,所以消息的消费逻辑会被重复执行,直到这条消息消费成功为止。

优秀的个人博客,低调大师

java springboot b2b2c shop 多用户商城系统源码-Spring Cloud Hystrix依赖隔离

依赖隔离 “舱壁模式”对于熟悉Docker的读者一定不陌生,Docker通过“舱壁模式”实现进程的隔离,使得容器与容器之间不会互相影响。而Hystrix则使用该模式实现线程池的隔离,它会为每一个Hystrix命令创建一个独立的线程池,这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况,也只是对该依赖服务的调用产生影响,而不会拖慢其他的服务。 通过对依赖服务的线程池隔离实现,可以带来如下优势: 应用自身得到完全的保护,不会受不可控的依赖服务影响。即便给依赖服务分配的线程池被填满,也不会影响应用自身的额其余部分。可以有效的降低接入新服务的风险。如果新服务接入后运行不稳定或存在问题,完全不会影响到应用其他的请求。当依赖的服务从失效恢复正常后,它的线程池会被清理并且能够马上恢复健康的服务,相比之下容器级别的清理恢复速度要慢得多。当依赖的服务出现配置错误的时候,线程池会快速的反应出此问题(通过失败次数、延迟、超时、拒绝等指标的增加情况)。同时,我们可以在不影响应用功能的情况下通过实时的动态属性刷新(后续会通过Spring Cloud Config与Spring Cloud Bus的联合使用来介绍)来处理它。当依赖的服务因实现机制调整等原因造成其性能出现很大变化的时候,此时线程池的监控指标信息会反映出这样的变化。同时,我们也可以通过实时动态刷新自身应用对依赖服务的阈值进行调整以适应依赖方的改变。除了上面通过线程池隔离服务发挥的优点之外,每个专有线程池都提供了内置的并发实现,可以利用它为同步的依赖服务构建异步的访问。总之,通过对依赖服务实现线程池隔离,让我们的应用更加健壮,不会因为个别依赖服务出现问题而引起非相关服务的异常。同时,也使得我们的应用变得更加灵活,可以在不停止服务的情况下,配合动态配置刷新实现性能配置上的调整。 虽然线程池隔离的方案带了如此多的好处,但是很多使用者可能会担心为每一个依赖服务都分配一个线程池是否会过多地增加系统的负载和开销。对于这一点,使用者不用过于担心,因为这些顾虑也是大部分工程师们会考虑到的,Netflix在设计Hystrix的时候,认为线程池上的开销相对于隔离所带来的好处是无法比拟的。同时,Netflix也针对线程池的开销做了相关的测试,以证明和打消Hystrix实现对性能影响的顾虑。 下图是Netflix Hystrix官方提供的一个Hystrix命令的性能监控,该命令以每秒60个请求的速度(QPS)向一个单服务实例进行访问,该服务实例每秒运行的线程数峰值为350个。 从图中的统计我们可以看到,使用线程池隔离与不使用线程池隔离的耗时差异如下表所示: 在99%的情况下,使用线程池隔离的延迟有9ms,对于大多数需求来说这样的消耗是微乎其微的,更何况为系统在稳定性和灵活性上所带来的巨大提升。虽然对于大部分的请求我们可以忽略线程池的额外开销,而对于小部分延迟本身就非常小的请求(可能只需要1ms),那么9ms的延迟开销还是非常昂贵的。实际上Hystrix也为此设计了另外的一个解决方案:信号量。 Hystrix中除了使用线程池之外,还可以使用信号量来控制单个依赖服务的并发度,信号量的开销要远比线程池的开销小得多,但是它不能设置超时和实现异步访问。所以,只有在依赖服务是足够可靠的情况下才使用信号量。在HystrixCommand和HystrixObservableCommand中2处支持信号量的使用: 命令执行:如果隔离策略参数execution.isolation.strategy设置为SEMAPHORE,Hystrix会使用信号量替代线程池来控制依赖服务的并发控制。降级逻辑:当Hystrix尝试降级逻辑时候,它会在调用线程中使用信号量。信号量的默认值为10,我们也可以通过动态刷新配置的方式来控制并发线程的数量。对于信号量大小的估算方法与线程池并发度的估算类似。仅访问内存数据的请求一般耗时在1ms以内,性能可以达到5000rps,这样级别的请求我们可以将信号量设置为1或者2,我们可以按此标准并根据实际请求耗时来设置信号量。 springboot微服务多用户商城系统java_代码开源_B2B电商系统_B2C电商系统

优秀的个人博客,低调大师

java B2B2C电子商务平台分析之十五-----EureKa服务注册与发现

什么是服务发现与服务注册 简单的来说就是一个微服务要调用另一个微服务,就必须知道这个微服务的地址及端口信息。采用一张注册表,注册上线可用的微服务及相关信息,微服务则从注册表上查找所需的其它微服务的相关信息。有两种主要的服务发现模式:客户端服务发现(client-side discovery)和服务器端服务发现(server-side discovery)愿意了解源码的朋友直接求求交流分享技术:二一四七七七五六三三 客户端发现 服务端服务发现 当发送请求到一个service的时候,客户端发送请求到一个router,这个router是在一个已知的地址上运行的。router查询service registry(可能在这个router中实现), 然后把请求发送到可用的service实例。如下所示: 服务发现组件的功能 服务注册表服务注册表是一个记录当前可用服务实例的网络信息的数据库,是服务发现机制的核心。服务注册表提供查询API和管理API,使用查询API获得可用的服务实例,使用管理API实现注册和注销;服务注册服务注册:服务启动时,将服务的网络地址注册到服务注册表中;健康检查服务发现组件会通过一些机制定时检测已注册的服务,如果发现某服务无法访问了(可能是某几个心跳周期后),就将该服务从服务注册表中移除。服务发现组件:Eureka Eureka是客户端发现类型的服务发现模式Eureka来自生产环境Spring Cloud对Eureka支持很好 上图是来自Eureka官方的架构图,大致描述了Eureka集群的工作过程。Eureka有两个概念,区域(Region)与可用区(Zone),不太理解,先抄过来占个位置。 区域(Region): AWS云服务在全球不同的地方都有数据中心,比如北美、南美、欧洲和亚洲等。与此对应,根据地理位置我们把某个地区的基础设施服务集合称为一个区域。通过AWS的区域,一方面可以使得AWS云服务在地理位置上更加靠近我们的用户,另一方面使得用户可以选择不同的区域存储他们的数据以满足法规遵循方面的要求。美东(北佛吉尼亚)、美西(俄勒冈)、美西(北加利佛尼亚)、欧洲(爱尔兰)、亚太(新加坡)、亚太(东京)等。每个区域都有自己对应的编码,如:编码对应可用区(Zone): AWS的每个区域一般由多个可用区(AZ)组成,而一个可用区一般是由多个数据中心组成。AWS引入可用区设计主要是为了提升用户应用程序的高可用性。因为可用区与可用区之间在设计上是相互独立的,也就是说它们会有独立的供电、独立的网络等,这样假如一个可用区出现问题时也不会影响另外的可用区。在一个区域内,可用区与可用区之间是通过高速网络连接,从而保证有很低的延时。AWS的区域与可用区的关系示意如下图所示:可用区每次当用户需要使用EC2相关资源的时候,他需要首先选择目标区域,如美东(北佛杰尼亚)us-east-1。然后在创建EC2实例的时候,用户可以选择实例所在的可用区,比如可以是us-east-1a或us-east-1b等。可用区的编码就是区域后面顺序添加不同的英文字母。Eureka在springcloud中的使用 Eureka包含两个组件:Eureka Server 和 Eureka Client。 Eureka Server提供服务注册服务,各个节点启动后,会在Eureka Server中进行注册,这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。Eureka Client是一个Java客户端,用于简化与Eureka Server的交互,客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后,将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。Eureka Server之间将会通过复制的方式完成数据的同步。Eureka还提供了客户端缓存的机制,即使所有的Eureka Server都挂掉,客户端依然可以利用缓存中的信息消费其他服务的API。综上,Eureka通过心跳检测、健康检查、客户端缓存等机制,确保了系统的高可用性、灵活性和可伸缩性。 整体代码结构如下: 资料和源码来源

优秀的个人博客,低调大师

java B2B2C电子商务平台分析之十一------配置中心和消息总线

Spring Cloud Bus Spring cloud bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化(例如配置变化)或者其他的消息指令。Spring bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展,也可以用来建立一个多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道,同样特性的设置(有些取决于通道的设置)在更多通道的文档中。愿意了解源码的朋友直接求求交流分享技术:二一四七七七五六三三 Spring cloud bus被国内很多都翻译为消息总线,也挺形象的。大家可以将它理解为管理和传播所有分布式项目中的消息既可,其实本质是利用了MQ的广播机制在分布式的系统中传播消息,目前常用的有Kafka和RabbitMQ。利用bus的机制可以做很多的事情,其中配置中心客户端刷新就是典型的应用场景之一,我们用一张图来描述bus在配置中心使用的机制。根据此图我们可以看出利用Spring Cloud Bus做配置更新的步骤: 1、提交代码触发post给客户端A发送bus/refresh2、客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus3、Spring Cloud bus接到消息并通知给其它客户端4、其它客户端接收到通知,请求Server端获取最新配置5、全部客户端均获取到最新的配置项目示例客户端spring-cloud-config-client改造 1、添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency> 需要多引入spring-cloud-starter-bus-amqp包,增加对消息总线的支持 2、配置文件 ## 刷新时,关闭安全验证 management.security.enabled=false ## 开启消息跟踪 spring.cloud.bus.trace.enabled=true spring.rabbitmq.host=192.168.9.89 spring.rabbitmq.port=5672 spring.rabbitmq.username=admin spring.rabbitmq.password=123456 配置文件需要增加RebbitMq的相关配置,这样客户端代码就改造完成了。 3、测试依次启动spring-cloud-eureka、spring-cloud-config-server、spring-cloud-config-client项目,在启动spring-cloud-config-client项目的时候我们会发现启动日志会输出这样的一条记录。 2017-05-26 17:05:38.568 INFO 21924 --- [ main] o.s.b.a.e.mvc.EndpointHandlerMapping : Mapped "{[/bus/refresh],methods=[POST]}" onto public void org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh(java.lang.String) 说明客户端已经具备了消息总线通知的能力了,为了更好的模拟消息总线的效果,我们更改客户端spring-cloud-config-client项目的端口为8003、8004依次启动,这样测试环境就准备好了。启动后eureka后台效果图如下:我们先分别测试一下服务端和客户端是否正确运行,访问:htt p://localhost:8001/neo-config/dev,返回信息: { "name": "neo-config", "profiles": [ "dev" ], "label": null, "version": null, "state": null, "propertySources": [ { "name": "https://github.com/ityouknow/spring-cloud-starter/config-repo/neo-config-dev.properties", "source": { "neo.hello": "hello im dev" } } ] } 说明server端都正常读取到了配置信息。 依次访问:htt p:/ /localhost:8002/hello、ht tp:/ /localhost:8003/hello、htt p:/ /localhost:8004/hello,返回:hello im dev。说明客户端都已经读取到了server端的内容。 现在我们更新neo-config-dev.properties中neo.hello的值为hello im dev update并提交到代码库中,访问:ht tp:/ /localhost:8002/hello依然返回hello im dev。我们对端口为8002的客户端发送一个/bus/refresh的post请求。在win下使用下面命令来模拟webhook. curl -X POST h ttp:/ /localhost:8002/bus/refresh执行完成后,依次访问:htt p:/ /localhost:8002/hello、ht tp:/ /localhost:8003/hello、h ttp:/ /localhost:8004/hello,返回:hello im dev update。说明三个客户端均已经拿到了最新配置文件的信息,这样我们就实现了图一中的示例。 技术架构图如下: 资料和源码来源

优秀的个人博客,低调大师

java版spring cloud微服务架构b2b2c电子商务平台-Spring Cloud Sleuth

在微服务框架中,一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果,每一个前段请求都会形成一条复杂的分布式服务调用链路,链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。 Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。 Span:工作的基本单位。例如,发送RPC是一个新的跨度,就像发送响应到RPC一样。Span是由一个唯一的64位ID来标识的,而另一个64位ID用于跟踪。span还具有其他数据,如描述、时间戳事件、键值标注(标记)、导致它们的span的ID和进程ID(通常是IP地址)。 可以启动和停止跨度,并跟踪其时间信息。 创建跨度后,必须在将来的某个时刻停止它。 启动跟踪的初始范围称为根跨度。 该范围的ID值等于跟踪ID。 Trace:一组span形成树状结构。 例如,如果运行分布式大数据存储,则可能由PUT请求形成跟踪。 注解:用于及时记录事件的存在。 使用Brave工具,我们不再需要为Zipkin设置特殊事件,以了解客户端和服务器是谁,请求开始的位置以及结束位置。 cs:客户已发送。 客户提出了请求。 此注释表示跨度的开始。 sr:Server Received:服务器端获得请求并开始处理它。 从此时间戳中减去cs时间戳会显示网络延迟。 ss:服务器已发送。 在完成请求处理时(当响应被发送回客户端时)注释。 从此时间戳中减去sr时间戳会显示服务器端处理请求所需的时间。 cr:客户收到了。 表示跨度的结束。 客户端已成功收到服务器端的响应。 从此时间戳中减去cs时间戳会显示客户端从服务器接收响应所需的全部时间。下图显示了Span和Trace在系统中的外观以及Zipkin注解: 注释的每种颜色表示跨度(有七个跨度 - 从A到G)。 请考虑以下注释: 此注释表示当前跨度的Trace Id设置为X,Span Id设置为D.此外,还发生了Client Sent事件。 Trace Id = X Span Id = D Client Sent 下图显示了跨度的父子关系:

优秀的个人博客,低调大师

Java版Spring Cloud B2B2C o2o社交电商-Hystrix的缓存使用

一介绍 在高并发的场景之下,Hystrix中提供了请求缓存的功能,可以方便地开启和使用请求缓存来优化系统,达到减轻高并发时请求线程的消耗、降低请求响应时间的效果。 二开启请求缓存功能 在实现HystrixCommand或HystrixObservableCommand时,通过重载getCacheKey()方法来开启请求缓存。 例如: public class CommandUsingRequestCache extends HystrixCommand<Boolean> { private final int value; protected CommandUsingRequestCache(int value) { super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")); this.value = value; } @Override protected Boolean run() { return value == 0 || value % 2 == 0; } //通过getCacheKey方法中返回的请求缓存key值,就能让该请求命令具备缓存功能。此时当不同的外部请求 //处理逻辑调用了同一个依赖服务时,Hystrix会根据getCacheKey方法返回的值区分是否是重复请求, //如果它们的cachekey相同时候,那么该依赖服务值会在第一个请求达到时被真实的调用一次,另外一个 //请求则直接从请求缓存中返回结果,所以开启缓存有以下好处: //减少重复请求数,降低依赖服务的并发度 //在同一用户请求的上下文中,相同依赖服务的返回数据始终保持一致。 //请求缓存在run()和construct()执行之前生效,所以可以有效减少不必要的线程开销。 @Override protected String getCacheKey() { return String.valueOf(value); } } 三清理失效缓存功能 使用请求缓存时,如果只是读操作,那么不需要考虑缓存内容是否正确的问题,但是如果请求命令中还有更新数据的操作,那么缓存中的数据就需要我们在进行写操作时进行及时处理,以防止读操作的请求命令获取到失效的数据。 在Hystrix中,可以通过HystrixRequestCache.clear()方法来进行缓存的清理。 例如: //当我们对GetterCommand命令实现了请求缓存之后,那么势必需要为SetterCommand命令实现清理缓存,以保证 //prefixStoredOnRemoteDataStore被更新之后,Hystrix请求缓存中相同的缓存的结果被移除,这样下一次根据id //获取prefixStoredOnRemoteDataStore时,不会从缓存去获取数据 public class CommandUsingRequestCacheInvalidation { /* represents a remote data store */ private static volatile String prefixStoredOnRemoteDataStore = "ValueBeforeSet_"; //根据id获取数据 public static class GetterCommand extends HystrixCommand<String> { private static final HystrixCommandKey GETTER_KEY = HystrixCommandKey.Factory.asKey("GetterCommand"); private final int id; public GetterCommand(int id) { super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("GetSetGet")) .andCommandKey(GETTER_KEY)); this.id = id; } @Override protected String run() { return prefixStoredOnRemoteDataStore + id; } @Override protected String getCacheKey() { return String.valueOf(id); } //该方法从默认的Hystrix并发策略中根据GETTER_KEY获取命令的请求缓存对象HystrixRequestCache的实例 //然后再调用该请求缓存对象的clear方法,对Key为id值的缓存内容进行清理。 public static void flushCache(int id) { HystrixRequestCache.getInstance(GETTER_KEY, HystrixConcurrencyStrategyDefault.getInstance()).clear(String.valueOf(id)); } } //用于更新prefixStoredOnRemoteDataStore的值 public static class SetterCommand extends HystrixCommand<Void> { private final int id; private final String prefix; public SetterCommand(int id, String prefix) { super(HystrixCommandGroupKey.Factory.asKey("GetSetGet")); this.id = id; this.prefix = prefix; } @Override protected Void run() { // persist the value against the datastore prefixStoredOnRemoteDataStore = prefix; //在调用了写prefixStoredOnRemoteDataStore之后,增加了对GetterCommand //中静态方法flushCache的调用,以实现对时效缓存的清理工作。 GetterCommand.flushCache(id); // no return value return null; } } }

优秀的个人博客,低调大师

Java版Spring Cloud B2B2C o2o社交电商-搭建Eureka注册中心

一创建一个SpringBoot工程,命名为eureka-server,并在pom.xml中引入必要的依赖,代码如下。 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.7.RELEASE</version> <relativePath/> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka-server</artifactId> </dependency> <!--<dependency>--> <!--<groupId>org.springframework.boot</groupId>--> <!--<artifactId>spring-boot-starter-actuator</artifactId>--> <!--</dependency>--> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Brixton.SR5</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> 二 通过@EnableEurekaServer注解启动一个服务注册中心提供给其他应用程序进行对话,只需要在SpringBoot应用中添加下面这个注解就能开启此功能。 @EnableEurekaServer @SpringBootApplication public class Application { public static void main(String[] args) { new SpringApplicationBuilder(Application.class).web(true).run(args); } } 三在默认情况下,服务注册中也会将自己作为客户端来尝试注册它自己,所以需要禁用它的客户端行为。 application.properties中增加如下配置。 spring.application.name=eureka-server server.port=1111 eureka.instance.hostname=localhost # 关闭保护机制 #eureka.server.enable-self-preservation=false eureka.client.register-with-eureka=false eureka.client.fetch-registry=false eureka.client.serviceUrl.defaultZone=http://${eureka.instance.hostname}:${server.port}/eureka/ logging.file=${spring.application.name}.log 说明:eureka.client.register-with-eureka:由于该应用为注册中心,所以设置为false,代表不向注册中心注册自己。 eureka.client.fetch-registry:由于注册中心的职责就是维护服务实例,它并不需要去检索服务,所以也设置为false。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册