在每个java应用中，都会存在各种各样的SDK，随着时间流逝和技术的迭代，SDK也需要进行相应的版本更新，在大型微服务系统中，动辄几百上千个应用，要推动这个数量级的应用进行SDK升级或者覆盖接入，消耗的成本是巨大的，这也是微服务治理的一大难点。
那么这个难点如何解决呢？参考service mesh的思路，将技术复杂度下沉，业务逻辑和技术组件拆分、解耦。
SDK下沉是指将SDK的具体实现逻辑下沉，在应用工程中实现透明化，在真正运行时再动态加载。这样应用工程在代码研发时，不依赖SDK的实现代码。
但是在应用工程中不可能完全不依赖SDK的代码，例如微服务的RPC，比如dubbo微服务框架，Dubbo Service的export和refer都由特定的@Annotation标注表示，所以应用工程中需要明确依赖这些@Annotation，不过可以不用依赖Dubbo的SDK实现，并且这些@Annotation通常是不会发生变化的，但是SDK不同，会经常迭代、升级，所以在SDK的工程结构上可以进行拆分，将不常变化的@Annotation抽象和接口抽象放到api模块中，具体实现放到impl模块或者其它模块，如下：
| sdk 模块 | 说明 |
|---|---|
| api | 抽象后的接口或者Annotation，不常变化 |
| imple、starter、或者sdk具体实现模块 |