前言看过 应用限流的朋友应该知道，限流的根本目的就是为了保障服务的高可用。 本次再借助SpringCloud中的集成的Hystrix组件来谈谈服务容错。 其实产生某项需求的原因都是为了解决某个需求。当我们将应用进行分布式模块部署之后,各个模块之间通过远程调用的方式进行交互(RPC)。拿我们平时最常见的下单买商品来说，点击下单按钮的一瞬间可能会向发送的请求包含： 请求订单系统创建订单。 请求库存

前言最近线上遇到一个问题:在消费kafka消息的时候如果长时间(大概半天到一天的时间)队列里没有消息就可能再也消费不了。针对这个问题我们反复调试多次。线下模拟，调整代码，但貌似还是没有找到原因。但是只要重启消费进程就又可以继续消费。 解决方案由于线上业务非常依赖kafka的消费，但一时半会也没有找到原因，所以最后只能想一个临时的替换方案： 基于重启就可以消费这个特点，我们在每次消费的时候都记下

前言 在一个高并发系统中对流量的把控是非常重要的，当巨大的流量直接请求到我们的服务器上没多久就可能造成接口不可用，不处理的话甚至会造成整个应用不可用。 比如最近就有个这样的需求，我作为客户端要向kafka生产数据，而kafka的消费者则再源源不断的消费数据，并将消费的数据全部请求到web服务器，虽说做了负载(有4台web服务器)但业务数据的量也是巨大的，每秒钟可能有上万条数据产生。如果生产者直

前言之前看过SSM(十四) 基于annotation的http防重插件的朋友应该记得我后文说过之后要用SpringBoot来进行重构。 这次采用自定义的starter的方式来进行重构。 关于starter(起步依赖)其实在第一次使用SpringBoot的时候就已经用到了，比如其中的: 1234<dependency> <groupId>org.springframe

前言 上一篇简单入门了SpringBoot+SpringCloud 构建微服务。但只能算是一个demo级别的应用。这次会按照实际生产要求来搭建这套服务。 Swagger应用上次提到我们调用自己的http接口的时候采用的是PostMan来模拟请求，这个在平时调试时自然没有什么问题，但当我们需要和前端联调开发的时候效率就比较低了。 通常来说现在前后端分离的项目一般都是后端接口先行。 后端大大们先把

前言随着互联网的兴起，现在三高(高可用、高性能、高并发)项目是越来越流行。 本次来谈谈高并发。首先假设一个业务场景：数据库中有一条数据，需要获取到当前的值，在当前值的基础上+10，然后再更新回去。如果此时有两个线程同时并发处理，第一个线程拿到数据是10，+10=20更新回去。第二个线程原本是要在第一个线程的基础上再+20=40,结果由于并发访问取到更新前的数据为10，+20=30。 这

前言 有看过我之前的SSM系列的朋友应该有一点印象是非常深刻的。 那就是需要配置的配置文件非常多，什么Spring、mybatis、redis、mq之类的配置文件非常多，并且还存在各种版本，甚至有些版本还互不兼容。其中有很多可能就是刚开始整合的时候需要配置，之后压根就不会再动了。 鉴于此，Spring又推出了又一神器SpringBoot. 它可以让我们更加快速的开发Spring应用，甚至做到了

前言针对于我们现在常用的RESTful API通常我们需要对请求进行唯一标识，也就是每次都要带上一个请求号,如reqNO。 对于入库这种操作数据库的请求我们一般要保证他的唯一性，一个请求号通常只能用一次，所以需要我们对这种请求加上校验机制。 该需求的实现思路是通过自定义annotation，只给需要进行校验的接口加上注解。然后通过切面使用了注解的接口将每次请求号存进Redis，每次都进行判断是

前言通常来说一个dubbo服务都是对内给内部调用的，但也有可能一个服务就是需要提供给外部使用，并且还不能有使用语言的局限性。 比较标准的做法是对外的服务我们统一提供一个openAPI，这样的调用方需要按照标准提供相应的appID以及密钥来进行验签才能使用。这样固然是比较规范和安全，但复杂度也不亚于开发一个单独的系统了。 这里所讲到的没有那么复杂，就只是把一个不需要各种权限检验的dubbo服务对外

在如今的HTTPS大当其道的情况下自己的博客要是还没有用上。作为互联网的螺丝钉(码农)岂不是很没面子。 使用CLOUDFLARE这里使用CLOUDFLARE来提供HTTPS服务。 在其官网进行注册，按照提示添加好自己的域名即可。 之后需要在自己域名的提供商处修改DNS服务器，我是在万网购买的修改后如下图：其中的DNS服务器地址由CLOUDFLARE是提供的。修改完成之后通常需要等待一段时间才能