slf4j

一、介绍 　　SpringBoot有两种方法与数据库建立连接，一种是集成Mybatis，另一种用JdbcTemplate，本文主要讨论集成Mybatis方式。 　　SpringBoot整合Mybatis也有两种方式，分别为XML配置方式和注解方式，主要优势点如下： XML配置方式：隔离sql和业务代码，清晰表达sql，尤其对于较长的sql。 注解方式：代码更加精简，方便。 本文主要讨论XML配置方式，后续文章讨论注解方式。 二、SpringBoot整合Mybatis连接Mysql数据库 1、添加MySQL 连接驱动依赖、SpringBoot Mybatis 依赖，完整pom文件如下： <? xml version="1.0" encoding="UTF-8" ?> < project xmlns ="http://maven.apache.org/POM/4.0.0" xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation ="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" > < modelVersion > 4.0.0 </ modelVersion > < groupId >

今天带来的是框架的学习，从今天开始，将会和以前的项目有所不同，从分层和实现类上更加的规范，在将框架之前，首先要了解一下crm系统技术架构： CRM即客户关系管理，是指企业用CRM技术来管理与客户之间的关系。 1、应用业务集成。将独立的市场管理， 销售管理 与售后服务进行集成，提供统一的运作平台。将多渠道来源的数据进行整合，实现 业务 数据的集成与共享。 这一环节的实现， 使系统使用者可以在系统内得到各类数据的忠实记录，代表真实发生的业务状况。 CRM功能 2、业务数据分析。对 CRM系统 中的数据进行加工、处理与分析将使企业受益匪浅。对数据的分析可以采用OLAP的方式进行，生成各类报告；也可以采用业务数据仓库（Business Information Warehouse）的处理手段，对数据做进一步的加工与 数据挖掘 ，分析各数据指标间的关联关系，建立关联性的数据模型用于模拟和预测。这一步所取得的结果将是非常重要的，它不单反映业务现实状况同时也对未来业务计划的调整起到指导作用。 3、决策执行。依据数据分析所提供的可预见性的分析报告，企业可以将在业务过程中所学到的知识加以总结利用，对业务过程和业务 计划 等做出调整。通过调整达到增强与客户之间的联系，使业务运作更适应市场要求的目的。 在实施CRM时，企业应根据CRM实施失败的原因，将CRM实施过程分成进入学习、熟悉应用和熟练改进三个阶段

转： https://blog.csdn.net/jeikerxiao/article/details/68064145 概述 接入微信公众平台开发，开发者需要按照如下步骤完成： 在自己服务器上，开发验证微信验证服务器地址的有效性逻辑 在微信平台上，填写自己服务器地址信息 在自己服务器上，依据微信接口文档实现业务逻辑 第一步：实现验证服务器地址的有效性逻辑 开发者提交信息后，微信服务器将发送GET请求到填写的服务器地址URL上，GET请求携带四个参数： 参数 描述 signature 微信加密签名，signature结合了开发者填写的token参数和请求中的timestamp参数、nonce参数。 timestamp 时间戳 nonce 随机数 echostr 随机字符串 开发者通过检验signature对请求进行校验（下面有校验方式）。 若确认此次GET请求来自微信服务器，请原样返回echostr参数内容，则接入生效，成为开发者成功，否则接入失败。 加密/校验流程如下： 将token、timestamp、nonce三个参数进行字典序排序 将三个参数字符串拼接成一个字符串进行sha1加密 开发者获得加密后的字符串可与signature对比，标识该请求来源于微信 java代码： 1 package com.jeiker.demo.controller; 2 3 import org

1、Java监听器 监听器用于监听web应用中某些对象、信息的创建、销毁、增加，修改，删除等动作的发生，然后作出相应的响应处理。当范围对象的状态发生变化的时候，服务器自动调用监听器对象中的方法。 2、Java中的事件 Java事件由事件类和监听接口组成，自定义一个事件前，必须提供一个事件的监听接口以及一个事件类。 Java中监听接口是继承java.util.EventListener的类，事件类继承java.util.EventObject的类。 因此Java监听器的组成有三部分：事件源、事件监听器、事件对象。当事件源发生操作时，它会调用事件监听器的一个方法，并且调用这个方法时，会传递事件对象过来。事件监听器是由开发人员编写，开发人员在事件监听器中，通过事件对象可以拿到事件源，从而对事件源上的操作进行处理。 事件监听器接口： package java.util; /** * A tagging interface that all event listener interfaces must extend. * @since JDK1.1 */ public interface EventListener { } 事件类： package java.util; /** * <p> * The root class from which all event state objects

一、Lombok简介 　　 　　（1）Lombok官网（ https://projectlombok.org/ ）对lombok的介绍 　　（2）GitHub项目地址： https://github.com/rzwitserloot/lombok 　　虽然是生硬的翻译，大家也大致可以看到Lombok存在的价值和意义，Lombok主要是可以提高开发效率，让我们这些小码农们工作时可以偷懒，让我们不再编写很多臃肿而定式的代码，虽然现在我们使用IDE工具可以生成很多，但是频繁的生成也会让我们的实体类看起来非常的臃肿。Lombok正是我们这些处于水深火热中的小码农的福音。 二、Lombok存在的意义： 　　（1）简化冗余的JavaBean代码，使得实体文件很简洁； 　　（2）便捷的生成比较复杂的代码，例如一个POJO要转化成构建器模式的形式，只需要一个注解。 三、Lombok有哪些注解，他们的作用分别是什么？ 　　a）Lombok的注解概览 　　b）下面对每个注解进行一一总结，如下： 　　　　1、@NotNull 　　　　①详细介绍：这个注解可以用在 成员方法或者构造方法的参数 前面，会自动产生一个关于此参数的非空检查，如果参数为空，则抛出一个空指针异常。 　　　　②栗子： 　　　　编译前： //成员方法参数加上@NonNull注解 public String getName(

Sleuth+Zipkin用来实现分布式系统的链路追踪。 Sleuth组件用于日志埋点、记录链路数据，Zipkin组件用于展示链路数据。 Sleuth的使用 （1）创建消费者、提供者时勾选Spring Cloud Tracing -> Sleuth 也可以手动添加依赖： < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-sleuth </ artifactId > </ dependency > （2）在消费者、提供者处理业务的类中添加成员变量 //使用的是 slf4j的日志，不要导错了 private final Logger logger = LoggerFactory.getLogger( this .getClass()); 在处理业务的方法中（消费者调用提供者、提供者处理业务的方法中），输出日志 logger.info("正在执行user-service的findOrdersByUserId方法，调用服务order-service"); 内容根据需要修改。 Sleuth输出的日志往往是空的，只输出服务名：[order-service,,,] 第（2）步是为了解决此问题，使Sleuth输出的日志有内容。 [order

springcloud线上发布超时系列文章： springcloud线上发布超时之feign（ribbon饥饿加载） springcloud线上发布超时之grpc springcloud线上发布超时方案之终极杀招：预热（测试用例） 前言 经过上面两章的优化，超时报错有所减少，但是只是得到了缓解但是当流量切换时还是会有大量超时。 方案 这里又增加了一个启动后预热，即在程序启动后执行测试用例n次，让hystrix、web容器线程池等资源初始化。在测试用例执行完成之前，为了保证服务不对外提供服务，这里可以分两种。 延迟注册到注册中心 如果时使用注册中心来进行服务发现等，这里可以采用延迟注册来保证测试用例的成功执行， 如果时eureka为注册中心可以配置initial-instance-info-replication-interval-seconds参数，默认是40s，可以将其改为1分钟 如果是consul或者zk，可以修改响应的延时注册时间，或者修改服务端有效时间 kubernetes中增加服务ready延时时间 这里再deploy.yml中配置如下： spec: replicas: 1 template: spec: containers: - args: livenessProbe: failureThreshold: 5 httpGet: path: /health port:

上一篇 Zipkin+Sleuth 链路追踪整合 增加基于 MQ 向 Zipkin 埋点功能 1.rabbitmq docker run --name rabbitmq -d -p 5672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=spring -e RABBITMQ_DEFAULT_PASS=spring rabbitmq:management 2.启动 Zipkin绑定 rabbitmq docker run --name rabbit-zipkin -d -p 9411 : 9411 --link rabbitmq -e RABBIT_ADDRESSES=rabbitmq: 5672 -e RABBIT_USER=spring -e RABBIT_PASSWORD=spring openzipkin/zipkin 3.添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream-binder-rabbit</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId

　　以前写过读写分离，今天完善成文档。 一：概述 1.结构文档 　　 2.思路 　　组装好各个数据源，然后通过注解选择使用读或者写的数据源，将其使用AbstractRoutingDataSource中的方法determineCurrentLookuoKey进行选择datasource的key。 　　然后，通过key，就找到了要使用的数据源。 　　在数据源的这里，最后配置上连接池。 3.说明 　　本配置直接使用一个公共的连接池配置，如果需要，自己进行配置 二：程序说明 1.连接池配置 package com.jun.webpro.common.config.dataSource.properties; import lombok.Data; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.stereotype.Component; import java.util.List; import java.util.Map; /** * 数据库连接池配置 */ @ConfigurationProperties(prefix = "spring.druid") @Component @Data public class

　　现在记录话单的时候想加一个参数：每秒接口调用的并发量，也就是所谓的QPS（ Queries per second ）。QPS即每秒请求数，是对一个特定的接口在规定时间内请求流量的衡量标准。那么如何实现QPS的计算呢？我想到的是两种方案： 　　1、一定时间内（比如一分钟）的请求总量/统计时间段（比如一分钟），最终得出就是每秒的并发量，它是基于某一段时间来统计的 　　2、直接统计一秒钟内的请求总量，就是按每秒的时间段来统计，简单粗暴 　　方案一的适用场景应该是报表、运维统计之类的，只关心QPS曲线；如果用来做并发量校验，明显只能用方案二，需要实时获取QPS。那么如何统计一秒内的并发量？假设某一个时间点有接口到来，那么就开始统计该接口，在一秒之内，来多少个累加多少次。一秒之后，统计数清零。之后的某一个时间点，又有接口到来，又开始统计一秒之内的接口调用量，如此循环往复。 　　那么如何维护一个一秒之内的接口计数器呢？我觉得失效缓存是一个合适的选择，缓存的键即为接口名，值就是接口统计数，过期时间一秒。为了避免引入第三方中间件，我们自己实现该过期缓存，需要维护一个定时器和一个优先级队列，每秒清理一次队列中已过期的缓存。 　　废话说完了，看代码： 　　1、缓存的值 import lombok.Getter; import lombok.Setter; import java.util