就程序员而言，日后的职业发展可以走 3 个方向：专攻技术深度、转团队管理、晋升架构师。
成为一名优秀的架构师，是大多数技术人的追求。但资深架构师的出现几率仅约为 0.3%。
如果想在 3-5 年后稳坐金字塔尖，必须有扎实的代码功底和项目积累，也要意识地培养技术广度和架构思维能力。多学习牛人经验也可获益良多。
图片
1 同步调用
同步调用是指在请求发起后，调用方一直阻塞等待调用处理完成的过程。在所提供的例子中，客户端代码 ClientCode 需要执行发送邮件的操作 sendEmail，这会触发对 EmailService 的调用。
EmailService 将调用 SmtpEmailAdapter 类来处理请求，而该类会通过 SMTP 和 TCP 协议调用远程服务，将请求发送到远程服务器。远程服务器收到消息后，会执行一系列操作，然后将邮件发送出去，并返回结果。
Adapter 接收到返回后，再将结果返回给 EmailService。EmailService 收到返回结果后，再将其返回给 ClientCode。在整个 sendEmail 过程中，ClientCode 会一直阻塞等待最终调用结果的返回，以确定操作是成功还是失败。由于这个等待过程是阻塞的，因此被称为同步调用。
2 异步调用
异步调用与同步调用相反。在异步调用的过程中，以发送邮件的例子为例，用户 ClientCode 调用 EmailService 后，EmailService 将调用请求发送到消息队列，然后立即返回。
ClientCode 在收到返回后可以继续向下处理，而不会继续阻塞等待。实际上，消息被发送到队列后，尚未被处理。在后续的消息消费阶段，比 EmailService 的返回可能会稍晚一些。有一个消息队列消费者 QueueConsumer 从消息队列中取出消息，然后将其发送给 SmtpAdapter，即调用 SmtpAdapter。
处理逻辑与同步调用类似，SmtpAdapter 通过 SMTP 通信协议将消息发送到远程服务器，执行邮件发送操作，通过 RemoteServer 进行处理。处理完成后，收到返回结果后通知消息队列 Queue。
在这个过程中，客户端的调用（即应用程序的调用）和实际的业务逻辑（发送邮件的操作）是异步的。在邮件发送操作的处理过程中，客户端代码已经返回，它可以继续执行自己的后续操作，而不需要等待邮件的发送完成，这就是异步调用。
图片
使用异步调用架构的主要手段之一是通过消息队列来构建。以下是该架构的图示：
- 消息生产者（Message Producer）：负责产生消息并将其发送到消息队列。消息生产者是异步的，它发送完消息后就可以继续执行其他任务，而不必等待消息被处理。
- 消息队列（Message Queue）：用于存储和传递消息。消息队列作为中介，接收生产者发送的消息，并将其提供给消费者。常见的消息队列系统包括 RabbitMQ、Apache Kafka、ActiveMQ 等。
- 消息消费者（Message Consumer）：从消息队列中获取消息并进行相应的业务逻辑处理。与消息生产者一样，消息消费者也是异步的，它可以在获取消息后立即开始处理，而无需等待消息的产生。
使用消息队列构建一个异步调用架构，你需要了解3种角色，一种是消息的生产者，一种是消息队列，还有一种是消息的消费者。
消息的生产者是客户端应用程序代码的一部分，用来初始化异步调用处理流程。
在基于消息队列的处理中，生产者的职责非常少，它要做的就是创建一个合法的消息，并把这个消息发送到消息队列中，由应用开发者决定生产者的代码在哪里执行，什么时候发送消息。
消息队列是消息发送的目的地，也是消息发给消费者的一个缓冲区。实现消息队列的方法有很多种，可以使用共享文件夹，也可以利用关系数据库或者 NoSQL 系统。
然而，最主要且常见的做法是使用专门的分布式消息队列服务器。这些消息队列服务器被设计用于高效地存储、传递和处理大量的异步消息。它们提供了可靠性、可伸缩性和高性能的特性，以满足不同应用场景的需求。
一些流行的分布式消息队列系统包括：
- RabbitMQ：一个开源的消息队列系统，实现了高级消息队列协议（AMQP）。
- Apache Kafka：分布式流处理平台，具有高吞吐量和可持久性的特点。
- ActiveMQ：一个开源的消息和集成模式服务器，实现了Java Message Service（JMS）规范。
- Amazon SQS（Simple Queue Service）：由亚马逊提供的托管消息队列服务。
- Redis：一种内存中数据结构存储，也可用作消息代理。
业务架构的第三个重要角色就是消息的消费者。消息的消费者从消息队列中接受并处理消息，消息的消费者也是由应用开发者实现的，但是它是一个异步处理的组件。
图片
消息的消费者不需要知道生产者存在，它只依赖消息队列中的消息。消息的消费者通常部署在独立的服务器上，和消息的生产者完全隔离，并且可以通过添加硬件的方式进行伸缩。
图片
点对点模型是一种消息传递模型，其中消费者和生产者只需知道消息队列的名称。在这种模型中，生产者将消息发送到消息队列，而消息队列的另一端有多个消费者竞争消费消息。
图片
每个到达消息队列的消息只会被路由到一个消费者，因此每个消费者看到的是全部消息的一个子集。
在这张图中，有多个消息生产者和多个消息消费者。多个生产者将消息发送到消息队列，而多个消费者在消息队列中竞争性地消费消息。
每条消息只会被一个消费者消费，每个消费者只会消费消息队列中的一部分消息。这种点对点的模型适用于需要确保每条消息只被一个接收者处理的场景，以及在消息生产者和消费者之间实现解耦的需求。
在发布订阅模型中，消息可能被发送到不止一个消费者，生产者发送消息到一个主题，而不是队列中。
消息被发布到主题后，就会被克隆给每一个订阅它的消费者，每个消费者接收一份消息复制到自己的私有队列。
消费者可以独立于其他消费者使用自己订阅的消息，消费者之间不会竞争消息。
常用的分布式消息队列都支持发布订阅模型，也就是说消息的发布订阅模型是分布式消息队列的一个功能特性。
图片
两种消息传递模型通常会根据业务需求和特点进行选择。点对点模型适用于一些耗时较长、逻辑相对独立的业务场景，例如发送邮件。因为发送邮件是一个比较耗时的操作，应用程序对于邮件发送是否成功并不太关心，而且发送邮件的逻辑相对独立。在这种情况下，应用程序只需要把邮件消息放入消息队列中就可以立即返回。消费者则只需从消息队列中取出邮件消息进行处理，通过远程服务器将邮件发送出去。由于每封邮件只需要被发送一次，因此消息只需要被一个消费者消费即可。
图片
相反，对于一些需要多个消费者协同处理的、涉及多个步骤的业务，例如新用户注册，通常会选择发布订阅模型。新用户注册成功后，可能需要发送激活邮件、欢迎短信，将用户注册数据写入数据库，并将新用户信息发送给关联企业的系统，以实现一次注册即可登录多个关联产品的需求。在这种情况下，可以使用按主题发布的方式，即发布订阅模型。新用户注册消息可以发布到一个主题，多个消费者可以订阅这个主题，分别处理不同的任务，如发送邮件、发送短信、写入数据库等。这种模型允许多个消费者同时对同一消息进行处理，实现了业务逻辑的解耦和灵活性的提高。
