AlbenXie的博客

先少后多（微服务数量）、先粗后细(粒度)基于业务逻辑进行拆分（用户群体、业务领域等模型）基于可靠性（核心模块独立化、主次链路隔离）基于性能拆分（独立拆分高性能场景）接口需保证幂等接口数据定义严禁内嵌，透传规范化工程结构，符合微服务风格不止对计算服务记性拆分，服务层 -> 缓存层 -> 数据层 的逐步拆解，才能发挥最大功效。

使用线程池时，如果没有给线程池一个有意义的名称，将不好排查回溯问题。这不算一个坑吧，只能说给以后排查埋坑，哈哈。我还是单独把它放出来算一个点，因为个人觉得这个还是比较重要的。/*** 关注公众号：捡田螺的小男孩*/System.out.println("关注公众号：捡田螺的小男孩");});关注公众号：捡田螺的小男孩可以发现，默认打印的线程池名字是，如果排查问题起来，并不友好。因此建议大家给自己线程池自定义个容易识别的名字。其实用。

最近在进行全链路压测，实际负责订单相关接口。

【代码】RedisConfig。

负载均衡这个概念，几乎在所有支持高可用的技术栈中都存在，例如微服务、分库分表、各大中间件（MQ、Redis、MyCat、Nginx、ES）等，也包括云计算、云调度、大数据中也是炙手可热的词汇。指配置后只会依据配置好的策略进行请求分发的算法。指配置后会根据线上情况（网络/CPU 负载/磁盘 IO 等）来分发请求。但负载均衡算法数量并不少，本篇主要对于一些常用且高效的负载策略进行剖析。

我们在项目中经常要用到定时任务，当有天服务器压力过大，我们就会增加服务器的数量，这时每台服务器的定时任务都在同一时间运行，导致我们需要同一时间运行一次的定时任务跑了多次，这时就需要解决这个问题，就用到了shedlock下面这是我项目里写的定时任务，里面的方法没有写出来。......

固定窗口算法实现简单，性能高，但是会有临界突发流量问题，瞬时流量最大可以达到阈值的2倍。为了解决临界突发流量，可以将窗口划分为多个更细粒度的单元，每次窗口向右移动一个单元，于是便有了滑动窗口算法。滑动窗口当流量到达阈值时会瞬间掐断流量，所以导致流量不够平滑。想要达到限流的目的，又不会掐断流量，使得流量更加平滑？可以考虑漏桶算法！需要注意的是，漏桶算法通常配置一个FIFO的队列使用以达到允许限流的作用。由于速率固定，即使在某个时刻下游处理能力过剩，也不能得到很好的利用，这是漏桶算法的一个短板。，，......

限流是对某一时间窗口内的请求数进行限制，保持系统的可用性和稳定性，防止因流量暴增而导致的系统运行缓慢或宕机。

代码】springboot令牌桶限流。

Sentinel是阿里巴巴开源的限流器熔断器，并且带有可视化操作界面。在日常开发中，限流功能时常被使用，用于对某些接口进行限流熔断，譬如限制单位时间内接口访问次数；或者按照某种规则进行限流，如限制ip的单位时间访问次数等。之前我们已经讲过接口限流的工具类ratelimter可以实现令牌桶的限流，很明显sentinel的功能更为全面和完善。来看一下sentinel的简介https随着微服务的流行，服务和服务之间的稳定性变得越来越重要。丰富的应用场景来简单使用一下Sentinel。https。......

前言假设你正在开发一个电商网站，那么这里会涉及到很多后端的微服务，比如会员、商品、推荐服务等等。那么这里就会遇到一个问题，APP/Browser 怎么去访问这些后端的服务？如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题：每个业务都会需要鉴权、限流、权限校验等逻辑，如果每个业务都各自为战，自己造轮子实现一遍，会很蛋疼，完全可以抽出来，放到一个统一的地方去做。 如果业务量比较简单的话，这种方式前期不会

优化spring bootUndertow是Wildfly的web服务器，性能不必多说，在嵌入微服务方面比tomcat更小。gradle环境configurations { compile.exclude module: 'spring-boot-starter-tomcat'}dependencies { compile('org.springframework.boot:spring-boot-starter-web') compile('org.springfra

1、Undertow使用spring boot内嵌容器默认为tomcat，想要换成undertow，非常容易，只需修改spring-boot-starter-web依赖，移除tomcat的依赖：<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exc

一、简介Kafka是一个分布式消息队列。★Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。无论是kafka集群，还是consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性。二、优点（相比较于Flume）在企业中必须要清楚流式数据采集框架flume和kafka的定位是什么：flume：★ 适合多个生产者；适合下游数据消

ribbon其他负载均衡算法说明，和算法切换

导读：在SpringCloud体系架构中，我们需要部署一个单独的网关服务对外提供访问入口，然后网关服务根据配置好的规则将请求转发至具体的后端服务，本章内容主要是给我们的微服务加上网关SpringCloud Gateway。前言我们有了三个服务account-service，product-service，order-service。现在有客户端WEB应用或APP应用需要访问后端服务获取数据那么就需要在客户端维护好三个服务的访问路径。这样的架构会有如下几个典型的问题：每个微服务都需要配置单

导读：在SpringCloud体系架构中，我们需要部署一个单独的网关服务对外提供访问入口，然后网关服务根据配置好的规则将请求转发至具体的后端服务，本章内容主要是给我们的微服务加上网关SpringCloud Gateway。前言我们有了三个服务account-service，product-service，order-service。现在有客户端WEB应用或APP应用需要访问后端服务获取数据那么就需要在客户端维护好三个服务的访问路径。这样的架构会有如下几个典型的问题：每个微服务都需要配置单

上篇文章中我们使用的是Seata的file配置实现分布式事务，既然本系列文章用的是Springcloud alibaba全家桶而Seata又恰好支持Naocs，那么我们肯定也将选择Nacos作为Seata的注册配置中心。本篇文章我们将一步一步把Seata整合上Nacos，大家伙跟我一起动手试试吧~本篇文章依赖于上篇文章SpringCloud Alibaba微服务实战七 - 分布式事务配置调整服务端配置修改服务端主要是修改\seata\conf\registry.conf文件，让Seata使用Na

导读：本篇作为SpringCloud Alibaba微服务实战系列的第七篇，主要内容是使用Seata解决分布式事务问题。系列文章，欢迎持续关注。场景说明订单服务order-service需要对外提供创建订单的接口，创建订单的业务逻辑如下：先调用本地的orderService保存订单操作，然后通过feign调用远程的accout-service进行账户余额扣减，最后再通过feign调用远程的product-service进行库存扣减操作。关键的逻辑代码如下：OrderController对

导读：本篇作为SpringCloud Alibaba微服务实战系列的第六篇，主要内容是将所有的微服务接入Nacos配置中心并按环境进行隔离。系列文章，欢迎持续关注。配置中心集成在SpringCloud Alibaba体系中是使用Nacos作为配置中心，这样Nacos既可以作为注册中心也可以作为配置中心，相当于SpringCloud中的Eureka + Config。要接入Nacos的配置中心也很简单，只需要如下几步：引入配置中心组件spring-cloud-starter-alibaba-nac

导读：本篇作为SpringCloud Alibaba微服务实战系列的第五篇，主要内容是使用Sentinel给微服务加上限流熔断功能，防止异常情况拖垮应用服务。系列文章，欢迎持续关注。简介Sentinel是面向分布式服务框架的轻量级流量控制框架,主要以流量为切入点,从流量控制,熔断降级,系统负载保护等多个维度来维护系统的稳定性。在SpringCloud体系中，sentinel主要是为了替换原Hystrix的功能，与Hystrix相比，sentinel的隔离级别更加精细，提供的Dashboard可以在

导读：本篇作为SpringCloud Alibaba微服务实战系列的第四篇，我们对之前的微服务框架进行优化，通过Maven bom机制管理所有组件的版本。BOM 简介BOM（Bill of Materials）是由Maven提供的功能,它通过定义一整套相互兼容的jar包版本集合，使用时只需要依赖该BOM文件，即可放心的使用需要的依赖jar包，且无需再指定版本号。BOM的维护方负责版本升级，并保证BOM中定义的jar包版本之间的兼容性。为什么要使用BOM使用BOM除了可以方便使用者在声明依赖的

导读：通过前面两篇文章我们准备好了微服务的基础环境并让accout-service 和 product-service对外提供了增删改查的能力，本篇我们的内容是让order-service作为消费者远程调用accout-service和product-service的服务接口。统一接口返回结构在开始今天的正餐之前我们先把上篇文章中那个丑陋的接口返回给优化掉，让所有的接口都有统一的返回结构。建立公共模块cloud-common其他模块都引入cloud-common,修改pom文件，加入依赖

导读：在之前一篇文章中我们准备好了基于SpringCloud Alibaba的基础组件，本期主要内容是将所有的服务注册进 Nacos，并让account-service和product-service能对外提供基础的增删改查能力。基础框架搭建在你的 IDEA 中建立一个多模块的项目（过程略...），项目整体截图如下：在主 pom 中定义基础组件版本，使用dependencyManagement引入版本依赖。<properties> <java.version&g

Springcloud Aibaba现在这么火，我一直想写个基于Springcloud Alibaba一步一步构建微服务架构的系列博客，终于下定决心从今天开始本系列文章的第一篇 - 基础环境准备。该系列文章内容主要基于三个微服务：用户服务AccountService，订单服务OrderService，产品服务ProductService用到的组件有：注册中心、配置中心 Nacos 限流 Sentinel 分布式事务 Seata 网关 SpringCloud Gateway 认证授权 Sp

写在前面：各位看到此博客的小伙伴，如有不对的地方请及时通过私信我或者评论此博客的方式指出，以免误人子弟。多谢！由于Kafka的写性能非常高，因此肯定会碰到Kafka消息队列拥堵的情况。遇到这种情况，我们可以通过并发消费、批量消费的方法进行解决。之前配置生产者我没有在yml文件中直接配置，而是新建了一个配置类，在配置类中配置生产者，这样确实有点麻烦了，所以消费者就直接在yml进行配置了。1、先看下批量消费，想要批量消费，首先要开启批量消费，通过listener.type属性设置为batch即可开启

从应用程序架构的变迁过程可以发现，随着业务多变性、灵活性的不断提高，应用程序需要以更加灵活的组合来应对。

我经常听到很多人讨论，关于「把 Redis 当作队列来用是否合适」的问题。有些人表示赞成，他们认为 Redis 很轻量，用作队列很方便。也些人则反对，认为 Redis 会「丢」数据，最好还是用「专业」的队列中间件更稳妥。究竟哪种方案更好呢？这篇文章，我就和你聊一聊把 Redis 当作队列，究竟是否合适这个问题。我会从简单到复杂，一步步带你梳理其中的细节，把这个问题真正的讲清楚。看完这篇文章后，我希望你对这个问题你会有全新的认识。在文章的最后，我还会告诉你关于「技术选型」的思路，文

市面上有非常多的消息中间件，rabbitMQ、kafka、rocketMQ、pulsar、 redis等等，多得令人眼花缭乱。它们到底有什么异同，你应该选哪个？本文尝试通过技术演进的方式，以redis、kafka和 pulsar为例，逐步深入，讲讲它们架构和原理，帮助你更好地理解和学习消息队列。文章作者：刘德恩，腾讯IEG研发工程师。...

本周是在家办公的一周，上面的图就是我在家的工位。工欲善其事，必先利其器。在家办公，我是认真的。在家里开发的时候有需求是这样的：一个如果接口调用失败，需要自动进行重试。虽然关系不大，但是我还是想到了Dubbo的集群容错策略：Failover Cluster，即失败自动切换。（这个转折是不是有点生硬.......）所以借本文对于Dubbo的Cluster集群和Failover Cluster(失败自动切换)策略进行一个详细分析。本文如果没有特别说明的地方，源码均是来自最新的2.7.5版本

1. 概述本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径2. 基本概念在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署

概念：多线程在并发环境中的正常执行顺序是随机无序的，并不能按照期盼的结果输出。因为启动一个线程时，线程并不会立即执行，而是等待CPU的资源调度，CPU能调度哪个线程，是通过多种复杂的算法计算而来。一、Thread的join()方法来解决这个问题一般在多线程编程时，需要控制线程的先后执行顺序，比如：主线程中写了子线程t1，想要的效果是需要t1先执行，然后再执行接下来的主线程操作，但是默认的是主线程先执行，所以问题就出现了，执行结果与预期结果不一致。有两个线程t1和t2，现在让t1比t2先执.

前言：我们在日常的多线程开发中，可能有时会想让每个线程都按照我们指定的顺序来运行，而不是让CPU随机调度，这样可能会让我们在日常的开发工作中带来不必要的麻烦。既然有了这个需求，也就引入了本文的标题，让线程按照自己指定的顺序来运行。多线程执行顺序按照正常的理解思路，上面代码的执行顺序依次应该为：t1 → t2 → t3，而实际效果则不是理想的状态。运行效果：认识Joinjoin可能对于一些同学来说并不陌生，此处我就不详细介绍Join是什么了，有疑问的同学可以自行baidu和go

Kafka producer拦截器(interceptor)一、拦截器原理Producer拦截器(interceptor)是在Kafka 0.10版本被引入的，主要用于实现clients端的定制化控制逻辑。对于producer而言，interceptor使得用户在消息发送前以及producer回调逻辑前有机会对消息做一些定制化需求，比如修改消息等。同时，producer允许用户指定多个interceptor按序作用于同一条消息从而形成一个拦截链(interceptor chain)。Interc

Kafka API实战一、环境准备1）启动zk和kafka集群，在kafka集群中打开一个消费者[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh \--zookeeper hadoop102:2181 --topic first2）导入pom依赖<dependencies> <!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka

一、kafka核心组成二、Kafka工作流程分析1、Kafka生产过程分析写入方式producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。分区（Partition）消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成，其组织结构如下图所示：我们可以看到，每个Pa

一、消息队列消息队列内部实现原理：图例说明：（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。（2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者）发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消

前言和设计模式一样，打算花三个月的时间，结合《Java并发编程实战》一书，来总结下并发方面的知识。第一章从线程池的原理开始总结，希望自己能坚持下来，加油！1. 如何实现一个线程池？线程池的概念这里不多说，在讲它的原理前，我们先自己想一下，如果我来写，那如何实现一个线程池？1.1 线程池的重要变量首先要定义一个存放所有线程的集合；另外，每有一个任务分配给线程池，我们就从线程池中分配一个线程处理它。但当线程池中的线程都在运行状态，没有空闲线程时，我们还需要一个队列来存储提交给线程池的任务。

简介：阿里妹导读：好的系统架构离不开好的接口设计，因此，真正懂接口设计的人往往是软件设计队伍中的稀缺型人才。为什么在接口制定标准中说：一流的企业做标准，二流的企业做品牌，三流的企业做产品？依赖倒置到底是什么意思？什么时候使用接口才算合理？今天，阿里匠人——张建飞将为你详细解读。接口有什么好处（Why）在我看来，接口在软件设计中主要有两大好处：1. 制定标准标准规范的制定离不开接口，制定标准的目的就是为了让定义和实现分离，而接口作为完全的抽象，是标准制定的不二之选。这个世界的运转离不..