总结：心得体会
既然选择这个行业，选择了做一个程序员，也就明白只有不断学习，积累实战经验才有资格往上走，拿高薪，为自己，为父母，为以后的家能有一定的经济保障。
学习时间都是自己挤出来的，短时间或许很难看到效果，一旦坚持下来了，必然会有所改变。不如好好想想自己为什么想进入这个行业，给自己内心一个答案。
面试大厂，最重要的就是夯实的基础，不然面试官随便一问你就凉了；其次会问一些技术原理，还会看你对知识掌握的广度，最重要的还是你的思路，这是面试官比较看重的。
最后，上面这些大厂面试真题都是非常好的学习资料，通过这些面试真题能够看看自己对技术知识掌握的大概情况，从而能够给自己定一个学习方向。包括上面分享到的学习指南，你都可以从学习指南里理顺学习路线，避免低效学习。
大厂Java架构核心笔记（适合中高级程序员阅读）：
Binder绑定器是Spring Cloud Stream中一个非常重要的概念。在没有绑定器这个概念的情况下，我们的Spring Boot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性，这使得我们实现的消息交互逻辑就会非常笨重，因为对具体的中间件实现细节有太重的依赖，当中间件有较大的变动升级、或是更换中间件的时候，我们就需要付出非常大的代价来实施。
通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。当我们需要升级消息中间件，或是更换其他消息中间件产品时，我们要做的就是更换它们对应的Binder绑定器而不需要修改任何Spring Boot的应用逻辑。这一点在上一章实现消息总线时，从RabbitMQ切换到Kafka的过程中，已经能够让我们体验到这一好处。
目前版本的Spring Cloud Stream为主流的消息中间件产品RabbitMQ和Kafka提供了默认的Binder实现，在快速入门的例子中，我们就使用了RabbitMQ的Binder。另外，Spring Cloud Stream还实现了一个专门用于测试的TestSupportBinder，开发者可以直接使用它来对通道的接收内容进行可靠的测试断言。如果要使用除了RabbitMQ和Kafka以外的消息中间件的话，我们也可以通过使用它所提供的扩展API来实现其他中间件的Binder。
仔细的读者可能已经发现，我们在快速入门示例中，并没有使用application.properties或是application.yml来做任何属性设置。那是因为它也秉承了Spring Boot的设计理念，提供了对RabbitMQ默认的自动化配置。当然，我们也可以通过Spring Boot应用支持的任何方式来修改这些配置，比如：通过应用程序参数、环境变量、application.properties或是application.yml配置文件等。比如，下面就是通过配置文件来对RabbitMQ的连接信息以及input通道的主题进行配置的示例：
spring.cloud.stream.bindings.input.destination=raw-sensor-data
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=springcloud
spring.rabbitmq.password=123456
发布-订阅模式
在Spring Cloud Stream中的消息通信方式遵循了发布-订阅模式，当一条消息被投递到消息中间件之后，它会通过共享的Topic主题进行广播，消息消费者在订阅的主题中收到它并触发自身的业务逻辑处理。这里所提到的Topic主题是Spring Cloud Stream中的一个抽象概念，用来代表发布共享消息给消费者的地方。在不同的消息中间件中，Topic可能对应着不同的概念，比如：在RabbitMQ中的它对应了Exchange、而在Kakfa中则对应了Kafka中的Topic。
在快速入门的示例中，我们通过RabbitMQ的Channel进行发布消息给我们编写的应用程序消费，而实际上Spring Cloud Stream应用启动的时候，在RabbitMQ的Exchange中也创建了一个名为input的Exchange交换器，由于Binder的隔离作用，应用程序并无法感知它的存在，应用程序只知道自己指向Binder的输入或是输出通道。为了直观的感受发布-订阅模式中，消息是如何被分发到多个订阅者的，我们可以使用快速入门的例子，通过命令行的方式启动两个不同端口的进程。此时，我们在RabbitMQ控制页面的Channels标签页中看到如下图所示的两个消息通道，它们分别绑定了启动的两个应用程序。
而在Exchanges标签页中，我们还能找到名为input的交换器，点击进入可以看到如下图所示的详情页面，其中在Bindings中的内容就是两个应用程序绑定通道中的消息队列，我们可以通过Exchange页面的Publish Message来发布消息，此时可以发现两个启动的应用程序都输出了消息内容。
下图总结了我们上面所做尝试的基础结构，我们启动的两个应用程序分别是“订阅者-1”和“订阅者-2”，他们都建立了一条输入通道绑定到同一个Topic（RabbitMQ的Exchange）上。当该Topic中有消息发布进来后，连接到该Topic上的所有订阅者可以收到该消息并根据自身的需求进行消费操作。
相对于点对点队列实现的消息通信来说，Spring Cloud Stream采用的发布-订阅模式可以有效的降低消息生产者与消费者之间的耦合，当我们需要对同一类消息增加一种处理方式时，只需要增加一个应用程序并将输入通道绑定到既有的Topic中就可以实现功能的扩展，而不需要改变原来已经实现的任何内容。
消费组
虽然Spring Cloud Stream通过发布-订阅模式将消息生产者与消费者做了很好的解耦，基于相同主题的消费者可以轻松的进行扩展，但是这些扩展都是针对不同的应用实例而言的，在现实的微服务架构中，我们每一个微服务应用为了实现高可用和负载均衡，实际上都会部署多个实例。很多情况下，消息生产者发送消息给某个具体微服务时，只希望被消费一次，按照上面我们启动两个应用的例子，虽然它们同属一个应用，但是这个消息出现了被重复消费两次的情况。为了解决这个问题，在Spring Cloud Stream中提供了消费组的概念。
最后
文章中涉及到的知识点我都已经整理成了资料，录制了视频供大家下载学习，诚意满满，希望可以帮助在这个行业发展的朋友，在论坛博客等地方少花些时间找资料，把有限的时间，真正花在学习上，所以我把这些资料，分享出来。相信对于已经工作和遇到技术瓶颈的朋友们，在这份资料中一定都有你需要的内容。
57acb)收录**
173
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
