觉得有点怪怪的，比如查询的代码，如果只是想在查询搞个缓存，可以直接在service类上套个springcache的@cacheable注解就搞定了，多爽哎
同学，你可能没理解这个业务的背景。如果只是面向c端的最普通的那种缓存架构，确实就是你说的那种，每个服务自己写缓存。但是如果是电商的商品详情页的系统架构，是要缓存一整个商品详情页的，涉及可能几十个服务的数据，如果每个服务都自己胡乱写缓存，那么缓存的控制权就放在几十个服务的负责人那里。那么负责商品详情页系统的同学，就要一个一个沟通缓存格式、后续的变动、新加一个缓存数据、等等吧，然后商品详情页系统从redis里获取几十个服务零散写入的数据，整合起来，给商品详情页提供出去。
这个过程是不可行的，会导致大量的沟通成本，而且在大团队协作里会导致经常容易出问题
你依赖的某个服务，可能来个新同学，自己没事儿把某个写缓存的代码给删了，你都不知道
所以才要打造所谓的服务闭环，就是说，几十个服务，自己不写缓存，有数据变动，发个消息到MQ，自己就不管了。然后你开发一个商品详情页系统，监听MQ，从各个服务拉取他们变动的数据，如何存缓存？什么格式？要怎么存？用什么架构？多级缓存怎么玩儿？怎么做缓存降级？全都在你一个人的掌控之中，打造了一个闭环。就是说商品详情页涉及到的各种数据的缓存，你完全可控。
要不是打造这样的服务闭环，会导致你做商品详情页的复杂缓存架构，几乎没法做，每次有一点变动就要找：商品服务、价格服务、库存服务、推荐服务、评论服务、会员服务、促销服务，等等各个方向的人开会，几乎会把自己搞死
我看有的架构是直接通过canel订阅binlog，消费 如果订阅的商品数据有变动直接可以消费到，在写入缓存中去
是的，这个是我们后期的改良版，前期还要靠人为约定让几十个服务给你发MQ，但是我们现在都改成更直接canal监听binlog了，就是我要什么数据我自己监听，我甚至发MQ都不要你来干了。无情自动化，能靠系统自动化的，就不要靠口口交流和商量。
具体问题具体分析，就像你所说的，如果是个小的项目，就一个系统只有查询，按你说的没有问题。但是你要考虑到今后的业务发展，当从一个台机器一个应用，到几十台机器，几十个应用的时候，就很有必要将缓存独立处理了。
可以使用外界的插件或者服务都可以