RabbitMQ

1.Windows下安装RabbitMQ需要以下几个步骤 (1)：下载erlang，原因在于RabbitMQ服务端代码是使用并发式语言erlang编写的，下载地址： http://www.erlang.org/downloads ，双击.exe文件进行安装就好，安装完成之后创建一个名为ERLANG_HOME的环境变量，其值指向erlang的安装目录，同时将%ERLANG_HOME%\bin加入到Path中，最后打开命令行（ 注意坑：window10需要用管理员身份打开 ），输入erl，如果出现erlang的版本信息就表示erlang语言环境安装成功； (2)：下载RabbitMQ，下载地址： http://www.rabbitmq.com/ ，同样双击.exe进行安装就好( 注意坑：默认的安装目录是C:/Program Files/....，这个目录中是存在空格符的，我们需要改变安装目录，貌似RabbitMQ安装目录中是不允许有空格的，我的安装路径为D:\RabbitMQ )； (3)：安装RabbitMQ-Plugins，这个相当于是一个管理界面，方便我们在浏览器界面查看RabbitMQ各个消息队列以及exchange的工作情况，安装方法是：打开命令行cd进入rabbitmq的sbin目录，输入：rabbitmq-plugins enable rabbitmq

消息中间件 1.采用异步处理模式 消息发送者可以发送一个消息而且不用等待相应。 消息接收者订阅或监听该通道。 一条消息最终可以转发给一个或多个消息接收者。 2.应用按程序和应用程序调用关系为松耦合关系 发送者和接收者不必了解对方，只需要确认消息。 发送者和接收者不必同时在线。 1 点对点模型 PTP 每个消息只有一个消费者 发送者和接收者没有时间依赖 接收者确认消息接收和处理成功 2 发布-订阅模型 Pub/Sub 多个消费者可以获得消息。 发布者和订阅者之间存在时间依赖性。 发布者需要建立一个订阅(subscription)，以便消费者订阅。 订阅者必须保持持续的活动状态接收消息，除非订阅者建立了持久的订阅。 订阅者未连接时发布的消息将在订阅者重新连接时重新发布。 （1）每个消息可以有多个订阅者 （2）客户端只有订阅后才能接收到消息 （3）持久订阅和非持久订阅 消息中间件的使用情景。 1、网站用户注册，注册成功后会过一会发送邮件确认或者短信。 这种场景是发布订阅模式的。 2、日志进行集中收集，用于计算pv，用户行为分析。 小流量测试，版本a 98%流量，版本a.1 2%流量，最后根据集中日志收集，通过日志判断版本效果。 3、数据复制案例 将数据从源头复制到多个目的地，一般要求顺序或者保证因果。并且保证数据的完整性。 用于跨机房数据传输，搜索，离线数据计算等。 4

一、概述 　　ConfigClient（微服务）从ConfigServer端获取自己对应的配置文件，但是目前的问题是：当远程git仓库配置文件发生改变时，每次都是需要重启ConfigCient(微服务)，如果有上百上千个微服务呢？我想我们不会一个个去重启每个微服务，也就是说如何让ConfigServer端通知到ConfigClient端？即ConfigClient端如何感知到配置发生更新？ 　　SpringCloud Bus会向外提供一个http接口，即下图中的/bus/refresh。我们将这个接口配置到git的webhook上，当git上的内容发生改变时，就会自动调用/bus/refresh接口。Bus就会通知ConfigServer，configserver会发布更新消息到消息总线的消息队列，其他服务订阅到该消息就会信息刷新，从而实现整个微服务进行自动刷新。 　　SpringCloud Bus官网地址： https://www.springcloud.cc/spring-cloud-bus.html 二、实现方式 (1)方式一：某个微服务承担配置刷新的职责 ①提交配置出发post请求调用客户端A的/bus/refresh接口 ②客户端A收到请求从Server端更新配置并且发送给Spring Cloud Bus消息总线 ③Spring Cloud

为了更好地支持交易业务的快速发展，马蜂窝支付中心从最初只支持基础支付和退款的「刀耕火种」阶段，经历了架构调整的「刮骨疗伤」阶段，完成了到实现综合产品平台形态的「沉淀蓄力」阶段的演进。 目前，马蜂窝支付中心集成了包括基础订单、收银台、路由管理、支付通道、清算核对、报表统计等多种能力，为马蜂窝度假（平台、定制）、交通（机票、火车票、用车）、酒店（开放平台、代理商）等近 20 条业务线提供服务。本文将围绕支付中心整体演变过程中不同阶段的核心部分进行简要介绍。 一、支付中心 1.0 初期为快速响应业务的支付、退款以及一些基础需求，支付中心主要负责接入支付通道（支付宝、微信、连连等），由各业务线分别实现收银台，然后调用支付中心进行支付。业务系统、支付中心和第三方通道的交互流程图如下： 各系统交互流程为： 业务线将订单信息封装后请求到支付中心 支付中心对订单信息简要处理后增加支付信息请求到第三方支付通道 第三方支付通道将支付结果异步回调到支付中心 支付中心将第三方响应的数据简易处理后同步通知到各业务系统 业务系统进行逻辑处理、用户通知及页面跳转等 业务发展初期，业务量较小，交易场景也比较单一，这样的设计可以快速响应业务需求，实现功能。但当业务复杂性不断提高，接入的业务也越来越多时，该架构就显得力不从心了。各业务线需要重复开发一些功能，并且支付中心不具备整体管控能力，开发维护成本越来越大

计划 1.1 安装组件 Capability Description 版本 RPA Central RPA 任务执行中心 2020.11 RPA Designer RPA Workflow设计器 2020.11 RPA Robot RPA Robot 2020.11 RPA Recorder RPA UI录屏工具(UFT) 2020.11 RPA Self Service RPA 自服务工具 2020.11 1.2 安装环境 本文档内容包含一些格式和说明约定。 组件 Configuration OS 数量 IP RPA Central 4CPU 24G RAM Windows server 2016 1 10.0.0.4 RPA Designer 4CPU 24G RAM Windows server 2016 1 10.0.0.4 RPA Recorder 4CPU 24G RAM Windows server 2016 1 10.0.0.4 RPA Robot 4CPU 24G RAM Windows server 2016 1 10.0.0.4 RPA Self Service 4CPU 24G RAM Windows server 2016 1 10.0.0.4 安装 准备 1.3 安装 Visual C++ 2010 下载并安装Visual C++2010,如下：

如今微服务如日中天，Spring Boot作为构建Spring Cloud全家桶的基础框架，早已经成长为后端的主流技术了，同时它也是Java工程师面试必问的知识点。 这一点呢，我是深有体会，因为每天都有大量读者都会在小编后台给我留言，说希望多分享一些SpringBoot相关的内容，每天也有大量学员检索SpringBoot相关的视频以及学习资料。 所以，今天小编就来给大家带来一波福利！在这篇文章我会推荐一些优质的 Spring Boot 实战书籍 （Spring Boot实战派以及Spring Boot2实战之旅） 帮助大家深入学习 Spring Boot。文章质量的话，大家可以放心。同时，小编还专门为大家准备了一份突击金三银四的面试必备宝典，有想要获取的小伙伴在文末有领取方式！！ 废话不多说，我们直奔主题： Spring Boot实战派 入门篇（1~3章） 基础篇（4~6章） 进阶篇（7~13章） 文章重点 Spring Boot 进阶 本章首先介绍AOP、loC、Servlet容器;然后深入讲解自动配置原理、自定义 Starter、自定义注解:最后讲解异常的处理,以及如何进行单元测试 用ORM操作 SQL数据库 集成安全框架,实现安全认证和授权 集成NoSQL数据库,实现搜索引擎 集成Redis，实现高并发 本章首先介绍Redis的原理、概念、数据类型

从上一篇文章大家可以看出，实现一个自己的消息总线框架是非常重要的内容，消息总线可以将界限上下文之间进行解耦，也可以为大并发访问提供必要的支持。 消息总线的作用： 1.界限上下文解耦：在DDD第一波文章中，当更新了订单信息后，我们通过调用经销商界限上下文的领域模型和仓储，进行了经销商信息的更新，这造成了耦合。通过一个消息总线，可以在订单界限上下文的WebApi服务(来源微服务-生产者)更新了订单信息后，发布一个事件消息到消息总线的某个队列中，经销商界限上下文的WebApi服务(消费者)订阅这个事件消息，然后交给自己的Handler进行消息处理，更新自己的经销商信息。这样就实现了订单界限上下文与经销商界限上下文解耦。 2.大并发支持：可以通过消息总线进一步提升下单的性能。我们可以将用户下单的操作直接交给一个下单命令WebApi接收，下单命令WebApi接收到命令后，直接丢给一个消息总线的队列，然后立即给前端返回下单结果。这样用户就不用等待后续的复杂订单业务逻辑，加快速度。后续订单的一系列处理交给消息的Handler进行后续的处理与消息的进一步投递。 消息总线设计重点： 1.定义消息(事件)的接口：所有需要投递与处理的消息，都从这个消息接口继承，因为需要约束消息中必须包含的内容，比如消息的ID、消息产生的时间等。 public interface IEvent { Guid Id {

微服务实战(二)：落地微服务架构到直销系统(构建消息总线框架接口) 从上一篇文章大家可以看出，实现一个自己的消息总线框架是非常重要的内容，消息总线可以将界限上下文之间进行解耦，也可以为大并发访问提供必要的支持。 消息总线的作用： 1.界限上下文解耦：在DDD第一波文章中，当更新了订单信息后，我们通过调用经销商界限上下文的领域模型和仓储，进行了经销商信息的更新，这造成了耦合。通过一个消息总线，可以在订单界限上下文的WebApi服务(来源微服务-生产者)更新了订单信息后，发布一个事件消息到消息总线的某个队列中，经销商界限上下文的WebApi服务(消费者)订阅这个事件消息，然后交给自己的Handler进行消息处理，更新自己的经销商信息。这样就实现了订单界限上下文与经销商界限上下文解耦。 2.大并发支持：可以通过消息总线进一步提升下单的性能。我们可以将用户下单的操作直接交给一个下单命令WebApi接收，下单命令WebApi接收到命令后，直接丢给一个消息总线的队列，然后立即给前端返回下单结果。这样用户就不用等待后续的复杂订单业务逻辑，加快速度。后续订单的一系列处理交给消息的Handler进行后续的处理与消息的进一步投递。 消息总线设计重点： 1.定义消息(事件)的接口：所有需要投递与处理的消息，都从这个消息接口继承，因为需要约束消息中必须包含的内容，比如消息的ID、消息产生的时间等。

【rabbitmq】Queueingconsumer被废止后老代码如何做的解决方案 参考文章： （1）【rabbitmq】Queueingconsumer被废止后老代码如何做的解决方案 （2）https://www.cnblogs.com/nfsnyy/p/12264590.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4437884/blog/4907823

网上也搜过很多案例，但是大多是都还是存在一些问题，比如队列、交换机的持久化，还有更严重的问题就是 很多地方没有提到消费端的消息确认。 这里结合下 个人自己的理解 整合的例子。 首先 需要安装好rabbitmq的服务器，可百度。 1.加入springboot rabbitmq依赖： <!--rabbitmq--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> 2.配置文件中 加入mq的配置： spring: rabbitmq: host: 127.0.0.1 port: 5672 username: guest password: guest publisher-confirms: true virtual-host: / publisher-returns: true listener: direct: acknowledge-mode: manual simple: acknowledge-mode: manual # 其他的自定义配置 3.注入mq的一些属性以及ConfirmCallback package com.statistica.common.config; import