前言看过之前SBC系列的小伙伴应该都可以搭建一个高可用、分布式的微服务了。 目前的结构图应该如下所示: 各个微服务之间都不存在单点，并且都注册于 Eureka ，基于此进行服务的注册于发现，再通过 Ribbon 进行服务调用，并具有客户端负载功能。 一切看起来都比较美好，但这里却忘了一个重要的细节： 当我们需要对外提供服务时怎么处理？ 这当然也能实现，无非就是将我们具体的微服务地址加端口暴露

原文链接1 在 GitHub.com 编辑代码我将从我认为大家都知道的一件事情开始(尽管我是直到一周前才知道)。 当你在 GitHub 查看文件时(任何文本文件，任何仓库中)，右上角会有一个小铅笔图标，点击它就可以编辑文件了。完成之后点击 Propose file change 按钮 GitHub 将会自动帮你 fork 该项目并且创建一个 pull request 。 很厉害吧！他自动帮你 f

前言写这篇文章的起因是由于之前的一篇关于Kafka异常消费，当时为了解决问题不得不使用临时的方案。 总结起来归根结底还是对Kafka不熟悉导致的，加上平时工作的需要，之后就花些时间看了Kafka相关的资料。 何时使用MQ谈到Kafka就不得不提到MQ，是属于消息队列的一种。作为一种基础中间件在互联网项目中有着大量的使用。 一种技术的产生自然是为了解决某种需求，通常来说是以下场景： 需要跨进程

前言看过 应用限流的朋友应该知道，限流的根本目的就是为了保障服务的高可用。 本次再借助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应用，甚至做到了