carl.zhao的专栏

之前在一个技术微信群看到一个伙伴提了一个问题。那就是 Spring Cloud 项目在标注了 @RefreshScope 与 @Configuration 类中 @Scheduled 的方法。当配置中心修改了配置时，这个定时调度会失效。下面我们来看一下案方现场。...

在大多数应用程序场景中，容器中的大多数 bean 都是单例的。当一个单例 bean 需要与另一个单例 bean 协作，或者一个非单例 bean 需要与另一个非单例 bean 协作时，您通常通过将一个bean 定义为另一个 bean 的属性来处理依赖关系。当 bean 的生命周期不同时，问题就出现了。假设单例 bean A 需要使用非单例(原型) bean B，可能是在 A 上的每个方法调用上。容器只创建一次单例 bean A，因此只有一次机会设置属性。容器不能在每次需要 bean B 的新实例时为 bean

最近公司正在服务化，因为公司是建筑行业的产业互联网。所以对于工人进出场考勤或者核心链路上都是需要用户进行证明“我是我”这个问题。那么就涉及到调用 ``实名认证``、``人脸比对``、``人脸质量``、``身份证OCR`` 等第三方服务。

上一篇文章分析了一下 RocketMQ 的基本架构、概念、安装以及使用方式。现在大多数项目都是基于 Spring Boot。因为它很方便的自动装配机制，所以现在构建项目都是基于 Spring Boot。下面我们来分析一下 RocketMQ 是如何集成 Spring Boot 的。RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器

我们系统当中地理信息使用高德的 城市编码表。项目的新需求就是输入地址能够返回找到对应的城市，其实高德开放 API 提供了一个 地理/逆地理编码 接口是满足这个需求的。但是它我们使用这个接口的时候遇到了一个问题。就是一个属性如果有值就会返回字符串，如果没有值就会返回空数据。比如：{ "status": "1", "info": "OK", "infocode": "10000", "count": "1", "geocodes": [ {

请问Spring加载bean的时候构造函数什么时候调用、@PostConstruct什么时候调用、实现了BeanPostProcessor接口的bean中的postProcessAfterInitialization和postProcessBeforeInitialization什么时候调用？你是否清楚呢？如果清楚的话可以直接忽略该篇文章！！！最近来了几个新人，被问了一个和bean生命周期相关的一个知识点，解决新人的问题后自己再写了一个demo，目的是为了清晰的描述整个bean的生命周期。注意注意.

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。1、基本架构及概念Nacos 支持服务发现与服务的配置管理，这里我们只是来讨论 Nacos 作为配置中心。命名空间用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或

大型系统一般都是进行前后端分享，但是我对于系统刚刚从零开始或者一些项目、内部项目都没有进行前后端分离。使用的都是模板技术，今天就来分享一下 Spring Boot WebFlux 整合模板引擎 Thymeleaf 的例子。

Spring Cloud为开发人员提供了工具来快速构建分布式系统中的一些常见模式(例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态)。分布式系统的协调导致了锅板模式，使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们将在任何分布式环境下都能很好地工作，包括开发者自己的笔记本电脑、裸金属数据中心和云计算等托管平台。1、特性Spring Cloud着重于为典型用例提供良好的开箱即用体验，以及覆盖其他用例的扩展机制。

在进行微服务调用的时候，不管是服务之间(A 服务调用 B 服务)还是服务内部调用(服务 A 某个方法进行里有异步)都存在异步调用。但是 ``Nepxion Discovery`` 在进行参数传递的时候很多情况是使用的是基于 ``ThreadLocal``。

在之前的文章中讲过，用户可以通过 URL 请求以及配置中心进行灰度发布的操作，而且支持配置中心的灰度发布参数的动态变更。如果用户不希望使用上面的两种方式，Nepxion Discovery 框架还支持图形化进行灰度化配置。支持...

``Nepxion Discovery`` 对于服务灰度发布参数支持：外置``Header``、 ``Parameter``、``Cookie``、``域名``规则策略驱动。并且还内置本地和远程、局部和全局规则策略驱动。并且还支持正则表达式以及通配表达式支持。并且``Nepxion Discovery``支持``Spring Cloud Gateway``、``Zuul网关``和``微服务``三大模式的灰度发布和路由等一系列功能。 所以``Nepxion Discovery`` 对于灰度发布的支持场景还是很

``Nepxion Discovery`` 对于服务灰度发布参数支持：外置``Header``、 ``Parameter``、``Cookie``、``域名``规则策略驱动。并且还内置本地和远程、局部和全局规则策略驱动。并且还支持正则表达式以及通配表达式支持。并且``Nepxion Discovery``支持``Spring Cloud Gateway``、``Zuul网关``和``微服务``三大模式的灰度发布和路由等一系列功能。 所以``Nepxion Discovery`` 对于灰度发布的支持场景还是很

``Nepxion Discovery`` 对于服务灰度发布参数支持：外置``Header``、 ``Parameter``、``Cookie``、``域名``规则策略驱动。并且还内置本地和远程、局部和全局规则策略驱动。并且还支持正则表达式以及通配表达式支持。并且``Nepxion Discovery``支持``Spring Cloud Gateway``、``Zuul网关``和``微服务``三大模式的灰度发布和路由等一系列功能。 所以``Nepxion Discovery`` 对于灰度发布的支持场景还是很

在之前的文章之中我们解析了一下 Spring Cloud 只需要在 ``RestTemplate`` 类型的 Spring Bean 上面添加一个 ``@LoadBalanced`` 注解，并且通过 ``RestTemplate`` 以 ``http://serviceId/访问路径`` 就可以访问真实服务的地址 ``http://lolcahost:端口/访问路径``。同样的 ``Nepxion Discovery`` 需要实现服务的灰度发布，也对 Spring Cloud 的负载均衡进行了扩展。

在之前的文章中只是简单的讲解了一下 Nepxion Discovery 服务注册添加元数据到注册中心里面以及服务注册与发现 Listener 的扩展。其实在服务发现的时候 Nepxion Discovery 进行了自己的扩展才能做到通过 restful header 传入以及配置中心配置的灰度参数再获取到某个服务的列表的时候，才能够选择灰度合适的服务实例。要理解 Nepxion Discovery 框架是如何进行灰度服务中进行服务实例选择的，我们先来理解一下 Spring Cloud 是如何对负载均衡进行抽

随着公司业务的增长，系统的调用量也越来越多。对于第三方公司的我们，如何提高系统的稳定性是摆在我们面前的一个问题。为了解决系统稳定性问题，决定把整个服务的日志通过日志跟踪号(traceNo) 以及一次调用链中每一个单个服务的调用时间打印到每个服务特定的目录中。 单个服务打印的数据运维会记录到 ES 里面，提供大盘给各个业务系统 owner 优化服务。分析这个需求，里面包含以下几个需求：解析上游传递过来的跟踪号，添加到 MDC 中记录整个日志，并且记录在当前服务当中调用的整个耗时把上游传递过来的跟踪号

Nepxion Discovery 在进行灰度发布的时候其实就是通过请求接口时的传入参数(或者在配置中心配置的参数)以及注册在注册中心的服务进行匹配找到合适的服务进行调用。在前面的文章 4、Nepxion Discovery 之 Spring Cloud 服务注册抽象 Spring Cloud 对于不同的注册中心都会有统一进行抽象。

在 Spring Cloud 微服务架构体系里面我们的服务如果需要暴露被其它服务发现并调用，只需要在启动类上面添加注解 @EnableDiscoveryClient 就可以了。因为 Nepxion Discovery 这个灰服务框架是基于 Spring Cloud 微服务架构体系，所以我们就有必要知道 Spring Cloud 的服务注册发现的原理。所以在这里就分析一下 Spring Cloud 服务是如何自动注册的。首先要讨论的就是启动类上面的 @EnableDiscoveryClient 这个注解。

Nepxion Discovery 项目的 github 地址为：https://github.com/Nepxion/Discovery。Discovery【探索】微服务框架，基于Spring Cloud Discovery服务注册发现、Ribbon负载均衡、Feign和RestTemplate调用等组件全方位增强的企业级微服务开源解决方案，更贴近企业级需求，更具有企业级的插件引入、开箱即用特征。它的功能在官网上面介绍得非常清楚，在这里就不在赘述了。下面我们来分析一下 Nepxion Discovery

上一篇博客 Nepxion Discovery：Spring Cloud灰度发布神器 介绍了 Nepxion Discovery 框架在灰度发布里面可以帮我们做哪些事情，下面我们就通过一个简单的小例子来体验一下它的魅力。1、环境搭建下载代码，Git clone https://github.com/Nepxion/DiscoveryGuide.git，分支为simple代码导入IDE，并切换到 simple 分支，编译好的项目结构如下所示：3. 下载Nacos服务器从https:/

原文地址：http://dockone.io/article/8149Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增强中间件，其功能包括灰度发布（包括切换发布和平滑发布），黑/白名单的IP地址过滤，限制注册，限制发现等，支持Eureka、Consul和Zookeeper，支持Spring Cloud Api Gateway（Finchley版）、Zuul网关和微服务的灰度发布，支持用户自定义和编程灰度路由策略，支持多数据源的数据库灰度发布等客户特色化灰度发布，

Spring Boot 使得创建可以“直接运行”的独立的、生产级的基于 Spring 的应用程序变得很容易。当我们直接使用 Spring Framework 集成第三方框架时，使用过的朋友都知道需要繁琐的配置。如果我们使用 Spring Boot 时，如果需要集成缓存框架 Redis 时，只需要在开发的项目中引入 Redis 相关的配置就可以 RedisTempalte 操作本地早已启动好的 Redis 服务。

在互网企业当中网关的重要性我就不再赘述了，相信大家都比较清楚。我们公司网关采用的是 Spring Cloud Gateway。并且是通过自定义 RouteLocator 来实现动态路由的。路由规则是请求参数里面的 bizType，比如接收 JSON 格式体的请求对象并且业务方请求的是创建支付订单接口，下面就是业务方需要传递的参数：{ "bizType" : "createOrder", .... 其它业务参数 }下面就是读取 requestBody 里面的主动参数，然后解析请求对象里面的 biz

如下是8月18日 系统报错502 Bad GateWay问题定位、追踪、方案确认等：一、现象：1点25分左右系统报警5xx错误；二、定位：排查过程查看ELB日志确认错误来源于（商户API：查询支付结果及创建跨境支付单）；查询Pinpoint、Grafana及日志系统各项指标正常；三、跟踪及分析：查看ELB监控面板发现，502错误一直都存在，分布比较零散（大概的发生概率：万分之一（一万个请求约1次502错误）]）；确认调用链路确认错误区域：商户 —> ELB —> 业务系统；

Spring cloud gateway是spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式，Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，其不仅提供统一的路由方式，并且还基于Filer链的方式提供了网关基本的功能，例如：安全、监控/埋点、限流等。网关提供API全托管

因为公司是做境外第三方支付，所以涉及到国际化问题。页面不变的值可以由前端进行处理，对于后端如果遇到异常信息需要产品经理提供对应的显示信息。这个显示信息可以根据不同的异常定义不同的异常码，然异常信息显示国际化信息保存到数据库。根据用户不同的国家请求动态的去数据库获取这个值。

当前系统是使用 spring boot + spring cloud feign 作为系统间的调用。使用 amazon 的 aws 的负载均衡调用。不能够做到服务调用的治理以及监控。基于以上缺点所以决定引用 dubbo 来做服务间的调用。1、Why Dubbo比较流行的有 spring cloud 和 dubbo，为什么选择 dubbo。功能特性Spring Cloud Netfi...

今天在遇到一个有意思的问题，那就是我们可以在Spring的xml配置文件里面可以定义bean的全局的init和destroy方法。如下图所示：我们可以看到在beans这个标签里面可以定义一些bean的全局属性，其中包括default-init-method与default-destroy-method方法。

转载地址：Intellij IDEA 使用Spring-boot-devTools无效解决办法相信大部分使用Intellij的同学都会遇到这个问题，即使项目使用了spring-boot-devtools，修改了类或者html、js等，idea还是不会自动重启，非要手动去make一下或者重启就更没有使用热部署一样。