1概述
作为金融企业对公众提供服务一定要保证其可用性，尽量做到更多个9（一般SLA中描述的高可用性99.99%，中的9越多代表全年服务可用时间越长服务更可靠，停机时间越短），随着软件系统的复杂度越来越高，故障是不可避免的。这就需要企业实现整体的弹性架构（ResilientArchitecture），为应对故障而设计。
然而，常见的RPC、RMI企业集成技术，因为是同步请求，常因为执行方失败、超时等因素而影响最终用户体验，而且很多故障是无法彻底消除的。而且RPC和RMI调用需要服务的消费方和服务的提供方同时在线，并且双方需要通过某种机制确认彼此的调用关系，因为存在这些弊端，就导致了面向消息的中间件（MOM）的产生，通过在企业架构中引入消息中间件，确保在故障发生时，受此影响的系统部分在一个很小的范围内。
消息中间件就是在分布式系统中间引入一个透明的中间层，隔离服务的提供方和消费方。
2为什么要引入MQ
2.1何为MQ
消息队列（MQ）是一种不同应用程序之间(跨进程)的通信方法，用于上下游应用程序之间传递消息。我们拆分来看：
l消息：应用程序通过写入和检索出入列队的数据（消息）来通信。
l队列：除去了接收和发送应用程序同时执行的要求。
这样就实现了上游与下游之间的解耦，上游向MQ发送消息，下游从MQ接收消息，上游下游互不依赖，它们只依赖MQ。因为有队列的存在，MQ可在上下游之间进行缓冲，把上游信息先缓存起来，下游根据自己的能力从MQ中拉去信息，起到削峰的作用。
2.2使用MQ带来的好处
2.2.1解耦
l什么是耦合
高内聚低耦合，是软件工程中的概念，这里的低耦合是指各个组件之间，尽可能相互独立。通俗一点的理解就是，增加模块间调用透明化，最高的透明度就是不用知道彼此的存在，因此减少接口的复杂性、规范调用的方式及传递的信息，降低产品各模块的依赖，提高重用程度。
l如何解耦
在企业整体架构中解耦，主要设计两个方面：一是简化减少交互，二是增加一个中间层实现两方的隔离，MQ就是其中的中间层（如下图所示）。
引入MQ后生产者和消费者不必知道彼此的存在也不必同时在线，主要交互流程如下：
\1)生产者负责：生产消息并通过SDK或API调用发送给MQ（同步发送或者异步发送）；
\2)MQ负责：接收消息，并持久化消息到消息存储（同步或异步存储消息）；
\3)生产者接收来自MQ的响应（消息发送状态或异常）；
\4)消费者订阅消息后，接收来自MQ的消息；
\5)消费者执行消息对应的后续业务操作；
\6)对消费结果进行确认（消费成功、失败、异常等）。
2.2.2削峰填谷
由于系统闲忙分布不均，QPS常相差几十倍甚至更高，特别是在遇到营销活动时，瞬间流量很可能超过后端系统的承载能力，这就要考虑通过消息中间件来缓冲，MQ客户端实例根据自己的处理能力从MQ服务器拉取消息，以此来减轻或消除后端系统的瓶颈。
2.2.3异构集成
由于各种原因，我们在企业信息化建设过程中，都会面临软件产品来自不同的厂家只解决某特定领域的问题，这些产品因为封闭的架构无法对外提供服务或缺少核心开发而无法做大的改造，这就造成了彼此之间很难集成。通过引入MQ可以部分解决该问题，只需要在某个环节生产一条消息，或者根据消息做出具体的响应，只需与MQ对接，不必与其他系统做一对一的对接。
2.2.4异步
隔离
为了提供金融服务的整体弹性，需要隔离内部、外部系统间的依赖。如支付通知分为两种，一种是同步通知，这时API调用会因为网络故障而超时，因为服务提供方处理能力限制而得不到及时响应……等多种因素影响，另一种是异步通知，在一定时效范围内最终通知到即可，从而提供提高最终用户的体验和交易成功率，提高业务的整体生产率。
3MQ选型
但凡选择就会受到主观和客观两个因素的影响。我们如何尽量客观的进行架构和框架选型，而避免先有结果而后找理由的文字游戏，下面我分享下我们做MQ选型的过程（这里不是说主观就是不好的，但作为工程师凡事做结构化和量化还是有必要的）。
3.1关键需求
\1)集群支持：为了保证消息中间件的可靠性，需要提供完备的生产者、消费者、消息中间件集群方案；
\2)持久化的支持：为了避免消息丢失，需要支持消息保存到磁盘文件或其它格式存储；
\3)消息重试的支持：消息处理失败后的支持失败转存或重试，并提供消息至少投第一次或消息最多投递一次的配置；
\4)分布式事务的支持：为了保证业务的完整性，选择的中间件需要支持分布式；
\5)消息的按序消费：在有些场景下，需要消息的消费能够按照发送的同样顺序进行处理从而保证顺序执行；
\6)消息的延时支持：在2C业务处理或三方数据源对接中，会遇到消息延时投递要求，需要支持延投递；
\7)消息堆积和回溯功能：在消息中间件持久化保存大量消息时不会对性能有大的影响，支持消息查询、重发，或者按照时间点来重新消费消息，以应对某一段时间消息的重新消费场景。
3.2其它需要考虑的因素
\1)产品与当前技术栈是否匹配，团队人员熟悉源代码更便于对消息中间件的原理理解和后续功能扩展；
\2)产品的使用广度特别是金融同业客户：同业因为业务同质化校对，场景需求相近，使用的人越多，说明关键场景支持较好，问题在之前暴露的越充分，当我们在使用时碰问题的时候，就比较容易找到对应的解决方案或解决人员；
\3)产品的高可用性：作为一个金融企业，需要服务的持续可用，作为提高企业弹性的基础消息平台，集群和高可用是一个必不可少的要求；
\4)产品的稳定性：产品可以持续、稳定的提供服务，不需要经常因为资源泄露或性能衰减等问题而重新启动。
\5)产品的活跃度：通过github统计数据能看出来这个产品是否经常有人维护，经常有人开发一些新的功能，经常fix一些bug。
3.3选型要点及原则
l搜寻满足关键需求的框架到候选清单；
l从功能和非功能性需求等几个方面对候选框架进行筛选；
l在帅选过程中要做好量化记录，避免先有倾向性的结果，后有筛选，这样选型就变成了一场数字游戏；
l有时要换个角度思考，常用来做比较的可能就是最好的，如很多MQ框架都与Kafka做比较，那么Kafka有可能就是最通用的框架，如果做选型就要对其是否满足自己的需求做重点分析；
l遵循第三眼美女原则，让理性引导感性；
l适合的就是最好的，不要但纯追求高性能和功能全面。
3.4选型建议
l为未来最少三年或五到十年来选择，因为TedNeward在JAVA消息服务的序言中总结了技术熟悉的过程4个阶段（门外汉、探索者、熟手、大师）。选型到全范围推广结束一年左右的时间就过去了，到大家熟悉和精通又一年过去了，谁都不想在刚熟悉还没用好，当前的产品就不满足要求了，又要重新来过。
l区分