微服务的架构下，如何根据业务抽象出适合自己系统的组件？

导读：基础SpringBoot/SpringCloud微服务的架构下，我们或多或少会根据业务抽象出适合自己系统的组件或SDK，来应对对内、对外的拓展。

在SpringBoot/SpringCloud先前介绍了一些，如：

• @Conditional来指定指定条件的时候才将某个 bean 加载到应用上下文中。
• @FunctionalInterface函数式接口申明
• @JsonTypeInfo在Java类继承的情况下如何实现父类及子类的JSON序列化与反序列化。

等等其他的注解标识，极大简化了业务逻辑和代码。

当然不这么实现是不是没有其他方式实现了，其实也不是唯一的方式！简单暴力的方式也是可以的，写业务逻辑时，if-else 可能是最容易想到的逻辑方式了。然而大量堆砌的 if-else 毫无疑问将给代码维护带来巨大的困难。如果想用if-else 来完善你的业务组件，尽量优化你的代码，避免后期业务拓展棘手。

• 如何优化你的if-else？来试试“责任链模式+策略模式”

如果在同一JVM中上述的方式没有多大问题，但是分布在不同的JVM中(微服务集群)，上述的方案估计要丢弃了。

在阅读下文时，考虑几个问题：

• 自定义的组件规则/SDK包，什么时候扫描才合理？
• 组件元数据怎样采集？

案例场景

目前存在三个服务，引擎层服务A，业务服务B、业务服务C。A|B|C在同一注册集群中，A需提供组件于B\C服务使用，依赖关系如下图所示。