说实话，我现在看到团队里新来的小朋友张嘴就说 "Sidecar 是云原生标准答案"，我都会笑着摇摇头。三年前我也是这么想的，那时候 Sidecar 和 Service Mesh 火得一塌糊涂，感觉不整个 Sidecar 你就不是正经云原生开发。
我之前也踩过同样的坑 — 跟风上了 Sidecar 架构，折腾了好几个月，最后还是切回了 SDK 模式。这篇文章我就说说真实的经历，不是要踩哪个捧哪个，就是把我遇到的问题和思考分享出来，说不定你也在纠结选哪个，能有点参考。
当时为什么选了 Sidecar？现在又为什么放弃？
三年前我们团队遇到的问题其实很典型：业务要同时跑在私有数据中心和公有云，要求一套代码到处运行。那时候翻遍了技术文章，十个里面有八个说 "用 Sidecar！这就是标准答案"。
我印象特别深，那时候看了很多 conference talk，演讲者都说得特别好 — "把跨切面关注点抽离到 Sidecar，应用只管业务逻辑，多干净啊！" "语言无关，不管你什么语言，Sidecar 都能工作"。我听得心潮澎湃，感觉这就是未来啊，赶紧上马。
结果呢？我们折腾了三个月，确实跑通了，但用着用着就感觉不对劲儿。
第一个让我不舒服的是问题排查。有一次线上出问题，请求超时，你得顺着链路追 — 从应用到 Sidecar，再从 Sidecar 到下游服务，网络配置是不是对？Sidecar 证书有没有过期？是不是 Sidecar 版本不兼容？本来一个简单的问题，现在牵扯出好几个组件，排查时间直接翻倍。我觉得可能因人而异，但对我们小团队来说，这个排查成本真的有点扛不住。
第二个就是资源开销。每个应用实例都要跑一个 Sidecar 容器，内存直接多出去几百 MB，CPU 也占一块。我们大部分应用都是小服务，有时候 Sidecar 占用的资源比应用本身还多。说实话，挺心疼的，我们不是大公司，服务器成本都是真金白银掏出去的。
第三个其实也是最重要的 — 我们就是个 Java 技术栈团队，全公司百分之九十五的服务都是 Java，所谓的 "语言无关优势" 我们根本用不上。你说你支持多语言，可我们根本不需要啊，那这个优势对我们来说就是多余的复杂度。
那时候刚好发现了 Capa-Java，它走的是 SDK 路线，所有能力都在进程内，我抱着死马当活马医的心态试了试，结果一用就是三年。
Capa-Java 到底是怎么工作的？我用代码给你演示
可能有人会说，SDK 模式不就是把各个云厂商的 API 包装一下吗？有什么特别的？其实不是这样的，我觉得它设计最巧妙的地方就是 "标准 API + SPI 插件" 这个思路。
我给你看一段实际代码，你一看就明白了。这是我们生产环境真实调用另一个服务的代码：
// 构建 RPC 客户端
CapaRpcClient client = new CapaRpcClientBuilder()
.build();
// 调用远端服务的方法
Mono<OrderResponse> result = client.invokeMethod(
"order-service", // 服务名
"createOrder", // 方法名
new OrderRequest(100, "product-123"), // 请求参数
HttpExtension.POST,
null,
TypeRef.of(OrderResponse.class)
);
// 处理响应
result.subscribe(response -> {
System.out.println("订单创建成功: " + response.getOrderId());
});
看到了吗？这段代码不管你跑在阿里云、AWS 还是私有数据中心，完全不需要改。唯一的区别就是你打包的时候用哪个插件而已。如果你跑在阿里云，就把阿里云插件放到 classpath；如果你跑在私有云，就用私有云插件。业务代码一行都不用动。
再看看配置获取，也是一样简单：
ConfigurationClient configClient = new ConfigurationClientBuilder()
.build();
// 动态获取配置，支持推送更新
Mono<Configuration> config = configClient.getConfiguration("payment-service");
config.subscribe(cfg -> {
int timeout = cfg.getValue("timeout", 30000);
System.out.println("当前超时配置: " + timeout);
});
还是那句话，代码一模一样，底层用什么配置中心，对业务代码来说完全透明。这一点真的太舒服了。
说实话，这种设计一点都不新鲜，Java 里用了几十年了，JDBC 就是这个思路啊 — 标准 API 给业务用，不同数据库不同驱动（插件），你换数据库不用改业务代码。Capa 就是把这个经过时间考验的模式用到了混合云这个场景上，我觉得这挺聪明的，不用瞎发明新轮子，把成熟模式用好就够了。
用了三年，说说真实的优缺点，不吹不黑
我见过太多开源项目推广，只说优点不说缺点，说实话那样挺没意思的。我用了三年，实事求是地说说，这东西好在哪儿，不好在哪儿。
优点我觉得最明显的有这几个
第一个肯定是操作简单。真的太简单了，你就是正常开发 Java 应用，加几个 Maven 依赖，打包运行，完事了。没有额外的容器要部署，没有额外的进程要监控，没有额外的证书要管。我之前用 Sidecar 的时候，每次发布都要检查一遍 Sidecar 是不是正常启动了，现在根本不用想这个事儿。
第二个是性能确实好。不说别的，少了一次网络跳转，少了好几次序列化反序列化，这个提升是实实在在的。我们压测过，P99 延迟比之前 Sidecar 方案降了大概 25% 左右，这个数字挺可观的。而且对我们这种小服务来说，省下的那几百 MB 内存也很重要，本来应用就小，现在资源浪费少多了。
第三个是对中小团队真的友好。我觉得现在技术圈有种风气，什么都要照着 FAANG 的标准来，人家用什么我们就用什么。可你想过没有，FAANG 有几百人的平台团队，我们呢？我们小团队一共没几个人，每个人都身兼数职，能把业务搞定就不错了，哪有空天天折腾 Sidecar 升级、监控、排错？Capa 这种方式，它就是你的应用的一部分，你怎么部署应用就怎么部署 Capa，不用学新东西，不用加新流程，这对小团队来说太重要了。
第四个是概念简单，新人上手快。新来的同事，不用先给他讲半天 Service Mesh 原理，不用讲 Sidecar 怎么和应用交互，出问题了该去哪边查日志。你就给他看 API，他会写 Java 就能用，半天就能上手干活。这个节省的培训时间，也是实实在在的收益。
缺点也很明显，你得能接受才行
第一个，只适合 Java 技术栈。如果你公司是多语言混编，Java、Go、Node.js 什么都有，那 Capa 确实不合适。它目前主要就是支持 Java，虽然别的语言也在推进，但生态肯定不如 Sidecar。Sidecar 不管你什么语言，只要能跑容器就能工作，这是 Sidecar 天生的优势，人家这个优势是真的，我不否认。
第二个，版本升级得每个应用自己升。因为 Capa 是链接到应用里面的，所以每个应用想升级就得自己改 pom 版本，重新发布。Sidecar 就不一样了，你可以统一升级 Sidecar，应用不用动。这个 trade-off 你得想清楚 — 你是想要每个应用可以灵活控制升级时机，还是想要统一管控？对我们来说，我们觉得每个应用自己控制节奏挺好的，不觉得这是问题，但有的人可能就喜欢统一管控，那这就是缺点。
第三个，生态确实不如 Dapr 那些大牌项目大。人家 Dapr 有微软撑腰，又是 CNCF 项目，贡献者多，支持的组件也多，各种云厂商各种存储各种消息队列都支持。Capa 是社区驱动的项目，核心团队人不多，支持的组件肯定没那么全。如果你需要一些比较冷门的组件，可能得自己写插件。当然，SPI 插件机制设计得挺好，自己写也不难，但终究还是要自己写对吧？
第四个，如果你已经下定决心要脱离 Java 生态，那这东西不适合你。比如你们公司现在全线转 Go 了，那你肯定不需要一个 Java 专用的 SDK 对吧？Capa 就是为那些还在使用 Java，并且打算继续用 Java 的团队准备的，它不试图说服你转语言，它就是帮你解决问题。
对比一下：什么时候选 Sidecar？什么时候选 SDK（Capa-Java）？
我总结了一下我这些年的经验，给你一个简单的判断思路，你可以对照自己的情况看看：
我觉得你可以试试 Capa-Java（SDK 模式）如果你符合下面大多数情况：
- 你主要就是 Java 技术栈，团队里大部分服务都是 Java
- 团队规模不大，没有专门的平台工程团队天天维护基础设施
- 你的应用需要跑在多个云或者混合环境，要求一套代码到处部署
- 你对延迟比较敏感，希望尽量少一些不必要的网络开销
- 你想要简单，不想加太多额外的移动部件，能少一事就少一事
你应该老老实实选 Sidecar 如果你符合下面大多数情况：
- 你真的是多语言环境，好几种语言混着用
- 你有专门的平台团队，能够承担额外的运营开销
- 你需要很丰富的生态，各种各样的组件都想用现成的
- 你喜欢统一管控基础设施，想要单独升级 Sidecar 不用碰应用
- 你的团队就是喜欢追最新的架构潮流，觉得 Sidecar 更 "云原生"
其实我现在越来越觉得，架构选择这事儿，真的没有绝对的对错，只有适合不适合。大团队有大团队的选择，小团队有小团队的活法，适合你的就是最好的。
我见过不少团队，明明五六个人的小团队，硬上了复杂的 Service Mesh 架构，结果把自己折腾得够呛，天天跟基础设施较劲，业务功能反而没时间做了，何苦呢？技术是为业务服务的，不是用来炫技的对吧？
这三年我最大的感悟是什么？
用了三年，说句真心话，我最大的感悟就是 — 好的架构是那种会隐身的架构，它不会天天跳出来让你操心它，它就在那儿安安静静干活，让你能把精力都放在真正重要的业务功能上。
Capa-Java 就是这样，它不完美，它有缺点，但是它把我需要解决的问题解决了，而且解决得很干净。我不用天天惦记着它，它就是我应用的一部分，和其他依赖一样，该怎么用就怎么用。
还有一个感悟就是，不要觉得新技术就一定比老技术好，不要觉得某种架构就是政治正确。现在一说云原生，好像你不用 Sidecar 你就不是云原生了，我觉得这就是扯淡。云原生的本质是让应用能够更好地适应云环境，更好地弹性伸缩，更好地持续交付，不是说一定要用某种特定的架构风格。
Capa-Java 用 SDK 的方式，一样能实现这些目标啊，那它为什么就不是云原生了？我觉得云原生这个词现在都被玩坏了，变成了一个营销标签，好像不用你就落伍了。其实啊，能解决你的问题，让你的团队效率更高，让你的业务跑得更稳，那就是好架构，管它是什么标签呢。
最后问问大家
你在混合云开发的时候踩过哪些坑？你用过 Sidecar 模式吗？体验怎么样？有没有人跟我一样，最后又切回了 SDK 模式？欢迎在评论区聊聊你的经历，我挺好奇大家都是怎么选的。
这篇文章是我自己三年生产环境使用 Capa-Java 的真实体验，不是广告，就是觉得这个思路很多人可能不知道，分享出来给需要的人参考。项目开源在 GitHub，感兴趣的可以自己去看看：github.com/capa-cloud/…
#Java #混合云 #云原生 #架构 #开源
