架构师需要掌握哪些知识

架构师需要掌握的知识如下：

1、并发编程：JAVA内存模型（JMM）、java当中的线程通讯和消息传递、Synchronized的概念和分析、Volatile和DCL的知识、并发基础之AQS的深度分析、原子 *** 作常用知识讲解。

2、框架和源码应用：mybatis应用和源码解析、tomcat源码解析、spring源码分析。

3、Spring微服务：Spring Cloud  、Spring Boot。

4、性能调优：mysql性能调优、java数据结构算法、JVM性能调优。

5、互联网工程：Maven、Git、Linux。

6、分布式：分布式协调框架（Zookeeper）、RPC服务框架（Dubbo）、分布式数据缓存（Redis）。

7、项目实战。

架构师的种类：

1、应用架构师。

应用架构师是行业中数量最多的架构师，主要负责公司产品的技术架构。产品架构师需要对业务有足够的理解，根据产品需求设计架构，在运营团队的协助下评估量级，并管理项目的整个生命周期。

2、中间件架构师。

中间件架构师主要负责基础框架、公共组件，通用服务的搭建。比如分布式服务框架诸如 Dubbo，HSF；比如消息队列诸如 RocketMQ，Kafka。在大型互联网公司中，往往不是把开源框架简单拿来，而是研发出符合自身业务的企业中间件。

3、基础设施架构师。

基础设施架构师负责服务器资源、网络资源、数据库等基础设施的建设；以及持续集成工具、持续部署工具的搭建。

大家好，我是BugKing，不知不觉正式工作快满2年了，在工作之前没有用过消息队列中间件，在这想分享下我这两年对RocketMQ的使用以及一些思考，因为内容比较多，会用好几期来分享。
先简单来聊下我在日常开发中，哪些问题适合使用RocketMQ来解决，因为我是搞IM的，所以下面我都会以IM的角度来分享。

在我负责的IM系统中，经常会遇到业务方群发几十万消息的场景，那面临这么多的请求，如何避免请求压垮我们的IM聊天系统呢？我们的系统应该是在自身能力范围内尽可能多地处理请求，那我们就可以使用消息队列来达到流量控制和保护后端服务的目的。
加入RocketMQ后，整个业务方发送消息的流程变成：
1、业务方调用rpc框架如dubbo接口发送消息后，直接将消息内容放入RocketMQ；
2、发消息后端服务从RocketMQ中获取消息内容，完成后续发消息流量，投递给前端。

这种设计既有优点也有缺点

那想在同一个topic下的某种消息进行流量控制限速呢？有没有什么好的办法？
我的做法是根据某种类型消息的标识，通过令牌桶算法（单机限流），根据你预估的处理能力，为这种消息单独设置一个线程池，线程池队列长度可以设置大些，用这个线程池也单独处理这种消息，这样也不会让其他类型的消息堆积在MQ。

IM系统也需要解决的核心问题时，如何利用有限的服务器资源，尽可能多地处理大量发送消息。在一个正常的IM系统中，一个完整的消息发送包含了很多 *** 作，当你发出去一条消息后可会有这些 *** 作：
1、消息入库
2、消息投递前端
3、用户不在线需要发送离线push。
4、用户这条消息被风控了需要发送风控提示。
5、消息需要统计数据，包含每天发送量，push量等等。
6、
如果没有任何优化，正常的处理流程时：消息投递后，依次调用上述流程，然后结束。
对于这几个步骤来说，决定消息是否发送成功，实际上只有消息入库这个步骤，只要消息入库了，用户就一定能看到消息，就算当时没有投递给前端，后续用户拉历史消息也能把消息拉出来，但是为了判断用户在不在线，需不需要发离线push，依赖消息投递前端的结果，所以当消息入库、消息投递前端后，就可以马上结束流程，然后把消息体放入rokcetMQ中，由消息队列异步执行后续的 *** 作。

rocketMQ的另一个作用，就是实现系统之间的解耦。
我们知道订单时在电商系统中比较核心的，当有一个新订单时：
1、支付系统发起支付流程
2、风控需要审核
3、IM系统发送一些卡片消息（比如确认收货地址）
4、统计系统需要统计数据
5、
这些订单下油的系统都需要实时获得订单数据。随着业务的发展，订单的下游可能在不断增加，负责订单的程序员不得不花费大量的精力，应对不断变化的下游系统，不停地调试订单系统与下游系统的接口。任何一个接口变更，订单系统就需要修改并上线，这是不能接受的。几乎所有的电商都会选择消息队列来解决类型的系统耦合的问题。这时候引入rocketMQ憨，订单系统在有一个新订单时，发送一条消息到rocketMQ的topic中，所有下游系统都订阅topic，这样每个下游可以根据订单消息来做相应的处理。

RocketMQ用的消息模式时发布 - 订阅模型。在发布 - 订阅模型中，消息的发送方称为发布者，接收方称为订阅者，服务端存放的消息的容器称为主题（Topic）。传统的队列模式和这种模型最大的区别就是，一份消息数据能不能被消费多次对的问题。因为在传统的队列模型中，任何一条消息都只能被一个消费者收到。

RocketMQ是发布-订阅模型，但是RocketMQ也有队列的概念，那队列的作用是什么呢？

我们都知道RocketMQ中有ack机制，确保消息不会在传递过程中由于网络或服务器故障而丢失，在消费端如果收到消息并完成了业务逻辑后，会给MQ回一个消费成功的确认，代表一条消息被成功消费，否则会给消费者重新发送消息，直到成功ack。这个确认机制保证了消息传递的可靠性，但是也带来了一个问题，为了确保消息的有序性，在某一笑消息被成功消息前，下一条消息是不能被消费的，否则违背了有序性这个原则，也就是每个Topic在任意时刻，最多只能有一个消费者在进行消费，这样消费端总体的消费性能就不能通过水平扩展消费者数量来提升，所以RocketMQ引入了队列来解决这个问题。来看下面这个图：

RocketMQ的每个Topic都包含多个队列，通过多个队列来实现多实例并行生产和消费。rocketMQ只在队列上保证消息的有序性，Topic层面是无法保证消息严格顺序的。每个消费组都有主题中一份完整的消息，不同消费组之间消费进度不受对方影响，
一条消息被消费组1消费过，也会给消费组2消费。
每一个消费组中包含多个消费者，同一个消费组内的消费者是竞争关系，比如一个消费组内的一条消息被消费者1消费了，就不会再给同组的其他消费者消费。

在一个Topic下的消息消费过程中，消息需要被不同的组进行多次消费，所以每个消费组在每个队列都维护一个消费位置，在这个位置之前的消息都是被消费过的，之后的消息都是没有被消费过。

需要注意的是Topic和消费组的关系、消费组和消费者的关系，消费组和队列数没有关系，不是有多少消费者就有多少队列，队列数可以根据数据量和消费速度合理配置

可以按照某个唯一标识，比如IM中，根据消息发送方用户id，通过一致性哈希算法，计算出队列ID，指定队列ID发送，这样可以保证相同的用户发的消息总被发送到同一个队列上，可以确保严格顺序。

时间不早了～下期再见。

近年来，随着微服务架构的流行，分布式消息引擎在物联网、分布式事务、实时计算和大规模缓存同步等场景中的应用日益增多。本文将分享微众银行基于 RocketMQ 构建消息服务平台的实践，并通过添加诸多高级特性来解决消息收发过程中遇到的各种问题，通过此文，您将了解到：

不管是银行的系统还是其他一些传统企业的系统，他们在最早的时候都使用到了服务总线，即 ESB 或者某种形式存在于 SOA 架构中，目的是把所有的服务都串起来，让服务之间能够形成一个调用。但这类服务架构其实是比较重的，所有的服务架构都要经过总线，总线成为了架构上的瓶颈。很多商业化的 ESB 总线大家可能都用过，像 Oracle、IBM 等都有。从服务调用的维度来看，银行的应用架构的演进经历了以下 3 个阶段。

这个阶段的架构具有以下 3 个特点：

这个阶段引入了 ESB 总线的理念：

ESB 总线为渠道、核心和外围系统建立了一座桥梁，提供完全统一的接口标准协议，提升了系统发布的实时性。但同时，ESB 成为了最大的单点，要支持大并发高 TPS 低延时，所以 HA 和性能要求非常高，变更需要相当谨慎。

到了 2012 年以后，随着 Facebook、Amazon 等开放平台获得的巨大成功，BAT 都逐步将自己的接口开放出来，并实施了开放平台生态圈战略，从而推动了 SOA 服务化的快速发展。

左边是之前的传统银行集中式总线架构，右边是互联网服务化架构，包含了开放平台、服务注册和发现，以及服务化产品系统。

通过开放平台对外提供接口暴露，可以发现这种架构在保障传统银行系统稳定性的同时也可以满足互联网金融需求的快速迭代实施，并且也使用了新兴的互联网分布式技术，来降低开发和运维的成本。

微众银行基于 Apache RocketMQ 构建了自己的分布式消息服务架构，我们以 RMB（Reliable Message Bus）为接入层，以基于 Apache RocketMQ 定制开发的 WeMQ（WeBank Message Queue）为消息服务核心，通过 GSL（Global Service Location）进行服务定位，通过 SGS（Service Governance System）进行服务请求和服务响应的服务治理，整个分布式链路的追踪日志会上报到 Log 中。

接下来，我们来看看我们基于 RocketMQ 改造使用到的常见的消息服务模式：

Consumer 可以是一个或者多个，但是一个消息会被多个不同系统的其中一个 consumer 收到。

多个在线的 Consumer 会同时收到广播消息。

生产者只有一个，消费者有多个，但是作为 HA，只有一个 Active，其他都是 StandBy。当 Active 挂掉一个，Standby 会迅速接管。

发送请求 - 等待响应结果。在发送方做了一个线程的等待，要等待结果的 notify。

在分布式消息系统的构建过程中，基于业务的需求，我们在 RocketMQ 的消息系统中添加了多项高级特性，包括多中心多活、灰度发布、熔断机制、消息存活期、流量的权重、消息去重、惊群效应问题的解决、背压模式、消息服务治理、MQTT 消息服务等。

DC 级别的多活希望解决的问题是，不仅消息不能丢，还要保证服务不能中断。这里有两个层面的故障，一个是应用全部宕机，那么希望被其他 IDC 的应用能够迅速来接管消息，另外一个是消息中间件宕机，那么希望生产者能够切换到其他 IDC 的中间件进行发送，并且这个中间件的消息在其他 IDC 有备份，能够进行消费。微众已经通过 IDC 断网演练检验同城多活能力。

灰度发布希望解决的问题是，同一个消费组内不同的实例有监听不一样的 topic 时，能保证不同 topic 的消息被正确的实例消费。

（灰度发布示意图）

当希望消息的堆积到一定程度时，可能是消费者出现了故障，我们希望能够提醒生产者。

熔断机制示意图

说到流量的权重，有一个问题是，Topic 的 Q 值是在使用过程中手动设置的，当实例的数量超过 Q 的数量，那么超过部分的实例是收不到消息的。但是，如果你的实例数量小于 Q 的话，它们之间会由于负载均衡分 Q。根据负载均衡算法，分到的 Q 可能是不一致的。比如有的分到 2 个，有的分到 3 个。在这种集群消费的情况下，就会出现处理的不对等。比如当大流量到来的时候，分到 3 个 Q 的那个实例可能会出现一些问题，比如挂掉了。

所以我们希望，不同的实例拿到的消息量应该是对等的。所以，流量权重希望解决的问题是，随着实例数的动态增加和减少，能够动态调整 consumeQueue 的数量，不至于出现流量不均匀的情况。因此，我们做了一个自动伸缩 Q 的功能。默认 Topic 建成时，Q 的数量是 1，当启动一个新的实例的时候，会自动扩展一个，停掉一个实例的时候会自动缩一个。从而达到 Q 个数量和实例的数量是一一对等的。这解决了实例和消息量不对等的问题。

在负载均衡的一个很短时间内，当新上一个实例的时候，由于大家分到的 Q 都是相同的，当前一个分到 Q 的还在继续拉消息，下一个实例由于负载均衡很快做完，也分到 Q，就会去拿这个 Q 的消息，这个时候就会出现消息的重复。此时，通常会通过 Redis 等缓存方式进行去重，也可以在 Broker 上做一个简单的处理，例如用互斥锁，在竞争消费的短时间内，对其进行加锁，抢到锁的才能进行消费，同时占有锁的时间有限制，从而解决消息去重的问题。

消息服务去重原理图

消息的背压消费模式

背压模式示意图

在一些特殊场景下，需要对消息引擎做一些加强，例如背压模式。当消息拉到本地的消费线程池时，会出现一个问题。当要做一些例如 DB 的写的 *** 作导致出现线程卡死，处理能力会下降，服务出现降级，但是消息还在不停地往本地拉。

这个时候，我们希望达到一种效果，能够根据后续服务的治理能力决定拉的消息数量。当然 RocketMQ 的 ProcessQ 也能达到这个效果，但是还不够精细化。因为在金融场景下，交易一旦出现不一致或者超时，会很麻烦。所以我们希望在实时的交易链路上去解决这个问题。于是我们做了一个类似 Reactor 框架的背压处理，能够根据处理能力实时拉取消息。

当对消息的有效期有要求时，可以在消费消息时对存活时间进行判断，超时则丢弃。

对于存活期非常短和对延时要求比较低的消息，我们通过内存模式（不落盘）进行加速，降低延时。

因为负载均衡算法在客户端，客户端的连接和断开都会触发消费组内的所有实例会收到 notification 做负载均衡。比较理想的情况是，一个实例的掉线不能影响到其他实例，当监听的 topic 比较多时，会出现负载均衡慢的问题，因此我们希望负载均衡收敛到服务端来做，客户端只需要关注 topic，不需要关注 consumeQueue。

目前，我们团队已经参与到 Apache RocketMQ 的社区建设中，并对自用的消息服务以社区分支的形式在维护，希望各行业更多的开发者可以一起参与进来，以打造适用范围更广、更好用的分布式消息引擎。

作者介绍

陈广胜，Apache RocketMQ 资深 Contributor，曾就职于 IBM 和华为，现任职于微众银行，曾参与过运营商云和大数据平台的建设，以及银行的基础架构建设等

---