spring-boot-starter-data-redis dubbo

Spring-bootフレームワークで開発する場合、redisをmybatis 2次キャッシュとして利用する場合、単体フレームワークの場合、@Cacheable(value = "users", key = "'findAll'")、通常はserviceの方法に直接ロードしたり、コントローラに直接ロードしたりすることができます.
dubboに加入して分散型マイクロサービスを始めると、この時はそんなにわがままを言ってはいけません.dubboフレームワークは、露出したサービスクラスに直接、@Service(version = "1.0.0")を加えることでサービスを提供することができます.そんなに煩わしい構成をしなくても、確かに半分の仕事がありますが、新しい問題をもたらします.例えば、その実現方法に関連するキャッシュ注釈を加えると、エラーが発生せず、dubboフレームワークが動作しません.以下のようにします.

2017-8-9 17:32:02 main DEBUG Finished creating instance of bean 'userServiceImpl'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.context.event.internalEventListenerFactory'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.transaction.config.internalTransactionalEventListenerFactory'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'cacheManager'
2017-8-9 17:32:02 main INFO Registering beans for JMX exposure on startup
2017-8-9 17:32:02 main DEBUG Autodetecting user-defined JMX MBeans
2017-8-9 17:32:02 main DEBUG Unable to locate LifecycleProcessor with name 'lifecycleProcessor': using default [org.springframework.context.support.DefaultLifecycleProcessor@1af05b03]
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'lifecycleProcessor'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.boot.autoconfigure.internalCachingMetadataReaderFactory'
2017-8-9 17:32:02 main DEBUG Returning cached instance of singleton bean 'org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor'
2017-8-9 17:32:02 main DEBUG Could not find key 'spring.liveBeansView.mbeanDomain' in any property source

では、このような問題に対して私たちはどのように解決しますか?このとき,注釈をmapperやdaoのインタフェースにロードすることで,問題が解決できる.

@Mapper
public interface UserDao {

    @Select("select * from t_sys_user where type = 'user_type_1'")
    Dict findUser();
    
    @Select("select * from t_sys_user")
    @Cacheable(value = "users", key = "'findAll'")
    List findAll();
}

実際、私たちはredisをMybatisの2級キャッシュとして使う以上、私たちがプログラムを書くときは、Mybatisに近づくべき方法が難しいのではないでしょうか.そのため、ある技術を規範的に使用することがどんなに重要か.
もちろん、spring bootの無プロファイルを捨てて、従来のxmlの方法を直接採用し、service層ではspringの注釈を直接採用し、主に必ず交換し、構成問題を解決することができます.
従来のモードとspringの注釈を採用すると、サービスの方法にキャッシュの注釈を加えることができ、私たちの心理的な考えに近づくことができます.結局、性能を大幅に向上させ、redisに対する絶えず読む圧力を減らすことができます.
しかし、上記の2つの方法のほかに、servletの方法やコントローラの上に直接ロードすることもできますが、非常に慎重です.そうしないと、何が予想外の問題になるのか分かりません.
もちろん,xml方式で構成したくない場合は,サービスの中間クラスを中間に別途ロードし,中間クラスにrpcの呼び出しを適用して問題を解決することもできる.
この問題の本質的な原因は,各スキャンクラスのスキャン順序と注釈の有効化順序が関係しているためであり,@Order方式で制御できるが,理想的ではない.このような問題に対応して、しばらく良い解決策がなくて、底層のソースコードを修正する必要があって、問題はそれぞれの特徴とその対象の分野の違いと実現技術の採用ができないため引き起こして、しばらく赤水河を数度しかできなくて、迂回戦術を歩きます.