qq_31279701的博客

基于Zookeeper和简单的平均分配算法实现了一个简单的分布式分片服务，该分片服务目前满足公司需求，因为其简单，所以不一定满足其他场景，针对其他场景还需考虑其他因素，该示例供参考。

Java使用gRPC完成的服务间的调用可以通过`io.grpc.ClientInterceptor`和`io.grpc.ServerInterceptor`定义客户端和服务端的拦截器实现分布式链路追踪。

Dubbo服务端线程模型

`AsyncContext`是`Servlet 3.0`使Servlet 线程不再需要一直阻塞，直到业务处理完毕才能再输出响应，最后才结束该Servlet线程。在接收到请求之后，Servlet线程可以将耗时的操作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高并发处理速度.........

系统架构切换背景    公司系统既有架构是传统的微服务架构，服务的部署方式也是传统的系统部署方式，并没有进行容器化部署；使用Dubbo作为微服务中间件，Zookeeper为系统的注册中心，同时使用Elastic JOB分布式定时任务中间件进行分布式任务处理；    随着云原生技术的快速发展，公司系统架构也开始着手进行调整，从技术上看云原生架构可以使系统拥有更好的伸缩性，更好的观测性，更灵活的发布策略，更精细的流量控制等等，可以让开发人员更专注于业务逻辑的开发，让开

Skywalking简介    Skywalking是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s）架构而设计。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。Docker部署Skywalking步骤部署Elasticsearch部署Skywalking OAP部署Skywalking UI应用程序配合Skywalking Agent部署部署Elasticsearch    这里基于Do

最近在做一些应用程序内部的一些组件的监控工作，比如线程池的监控，我这里要把监控线程池的指标暴露出去，能够让Prometheus抓取到，然后修改Prometheus的配置文件，监控的服务信息配置好，重启Prometheus，Prometheus就能够抓取数据了；这就存在一个问题，就是每次我新增监控的实例时都需要修改Prometheus配置，并且重启Prometheus，非常不方便。所以就引出了一个概念服务发现

dynamic-tp是一个轻量级的动态线程池插件，它是一个基于配置中心的动态线程池，线程池的参数可以通过配置中心配置进行动态的修改，目前支持的配置中心有Apollo,Nacos和Zookeeper

    Dubbo调用失败时提供了容错方案；当存在多个provider实例时Dubbo提供了路由和负载均衡的能力，下面时来自Dubbo官网的一张图，图片中展示了Dubbo集群容错的模型。各节点关系这里的 Invoker 是 Provider 的一个可调用 Service 的抽象，Invoker 封装了 Provider 地址及 Service 接口信息Directory 代表多个 Invoker，可以把它看成 List ，但与 List 不同的是，它的值可能是动态变化的，比

生产环境因WebService调用无响应导致线程阻塞问题排查

Dubbo Bean加载    我们使用dubbo都是和Spring进行结合使用，并且常用的方式就是通过在xml中配置dubbo来实现的，我们结合这种方式来看一下，spring是如何加载dubbo的bean的，下面我们来看一下一个最基本的dubbo的配置，结合配置来分析：以下示例来自于官方例子<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.

起因    公司的APP后台服务有一个接口在压测时，接口的吞吐量极低，观察接口处理日志发现接口耗时很长，达到秒级的响应时间。接口中主要影响接口的处理时间初步分析时数据库查询和RPC调用，因为RPC调用时使用的以前的接口，以前的接口已经经过了压测，确认没问题，所以极有可能就是数据库操作导致的，但是接口中业务逻辑比较多，数据库的操作比较多，没办法直观的确认某一行代码某一个sql的执行速度，针对此问题，我是用Arthas来进行分析，Arthas的trace命令可以分析具体某行代码的耗时，这样

目标生产环境ActiveMQ消费慢问题始末第一次代码优化后服务线程阻塞问题排查最终问题解决生产环境ActiveMQ消费慢问题始末   公司一个系统生产环境应用ActiveMQ进行通信，由于上下层系统的特殊性，消息的对接使用的P2P的模式，上送服务需要对接上百个ActiveMQ的消息队列，下层服务的每一个实例都对接一个消息队列，并且消息量不大，所以消息生产者是一个单线程的程序，并且生产者使用同步的方式发送消息，就是说只有当消息发到达broker并刷盘成功才会发下一条数据。   突然在某一个时间

本文参考官方文档：https://activemq.apache.org/persistence博客：https://blog.youkuaiyun.com/weixin_42796626/article/details/98206384持久化方式支持目前最新版本支持的消息持久化方式有以下几种，其他版本的持久化支持情况请参考官方文档kahaDB文件持久化jdbc持久化levelDB存储levelDB主从复制AMQ持久化；（不推荐，可以用kahaDB替代）Memory内存持久化；（不推荐，容易丢失数

Docker搭建redis主从复制一.安装Redis1.搜索redis镜像 docker search redis2.拉取镜像 docker pull redis二.主从复制1.运行docker镜像，首先使用docker启动3个redis容器服务，分别使用到6379、6380、6381端口docker run --name redis-6379 -p 6379:6379 -d redis redis-serverdocker run --name redis-6380 -p

SpringBoot快速集成KafkaMaven依赖<!-- 启动springbootstarter支持 --><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId></dependency><dependency> <gr

ActiveMQActiveMQ介绍ActiveMQ是Apache软件基金下的一个开源软件，它遵循JMS1.1规范（Java Message Service），是消息驱动中间件软件（MOM）。它为企业消息传递提供高可用，出色性能，可扩展，稳定和安全保障。ActiveMQ的消息传递模式P2P （点对点）消息域使用 queue 作为 Destination，消息可以被同步或异步的发送和接收，每个消息只会给一个 Consumer 传送一次。Pub/Sub（发布/订阅，Publish/Subscri