Service Mesh概念踩坑记：那些让我熬夜的问题

2017年，Service Mesh（服务网格）很火，被称为，微服务的下一代架构，各种文章，各种分享，都在说，Service Mesh，能解决，微服务治理的所有问题，服务发现、负载均衡、熔断降级、限流、链路追踪、监控、安全，等等，都能，搞定，而且，对业务代码，无侵入，很美好。

我们团队，那时候，正好，在做微服务治理，踩了很多坑，看到Service Mesh，这么火，这么美好，就，心动了，决定，把微服务，接入Service Mesh，试试效果。

没想到，接入之后，踩了很多坑，很多问题，排查了很久，熬了好几个通宵，才解决，今天，就来分享一下，我的Service Mesh踩坑记，那些，让我熬夜的问题，希望，能给大家一些参考。

一、为什么要接入Service Mesh

先说说，我们为什么，要接入Service Mesh。

我们团队，那时候，已经，把单体应用，拆成了，微服务，有，二十多个服务，但是，微服务治理，很头疼，很多问题：

1. 服务治理的逻辑，和业务代码，耦合在一起： 熔断、降级、限流、重试、负载均衡，这些，服务治理的逻辑，都写在，业务代码里，用的是，Hystrix，Ribbon，这些，库，每个服务，都要，引入，都要，配置，很麻烦，而且，不同的语言，比如，Java，Node.js，Python，要用，不同的库，不一致，维护起来，很麻烦。

1. 分布式追踪，很麻烦： 微服务之间，调用链，很长，出了问题，排查，很麻烦，我们，用了，Zipkin，做分布式追踪，但是，每个服务，都要，手动，埋点，传递，traceId，很麻烦，而且，很容易，漏埋，断链，排查起来，很头疼。

1. 监控告警，不统一： 每个服务，监控的指标，不一样，告警规则，也不一样，出了问题，不能，快速定位，很头疼。

1. 安全，不好做： 服务之间的调用，认证，授权，加密，这些，安全问题，不好做，每个服务，都要，自己实现，很麻烦，也，容易出问题。

这时候，Service Mesh，出现了，号称，能解决，所有这些问题，而且，对业务代码，无侵入，只需要，在，每个服务旁边，部署一个，Sidecar代理，所有的，服务治理的逻辑，都在，Sidecar里，业务代码，不需要，改，就能，享受，服务发现、负载均衡、熔断降级、限流、重试、分布式追踪、监控、安全，等等，所有的，服务治理能力，听起来，太美好了。

我们，那时候，被微服务治理，折磨得，很痛苦，看到Service Mesh，这么美好，就，决定，试一试，接入Service Mesh。

那时候，Service Mesh的，主流实现，有，Linkerd，和，Istio，Linkerd，比较轻量，比较成熟，Istio，功能，更强大，但是，比较重，比较复杂，我们，对比了一下，最后，选了，Istio，因为，功能，更强大，而且，是，Google，IBM，Lyft，一起搞的，背景，很强，觉得，应该，比较靠谱。

没想到，就是，这个决定，让我们，踩了，很多坑，熬了，很多通宵。

二、Service Mesh的基本概念

在讲，踩坑之前，先简单说说，Service Mesh的，基本概念，方便，大家理解。

Service Mesh，中文，叫，服务网格，是，一个，专门，用于，处理，服务与服务之间，通信的，基础设施层，它，能，可靠地，在，复杂的，服务拓扑中，传递，请求。

简单来说，Service Mesh，就是，在，每个服务，旁边，部署一个，Sidecar代理（边车代理），所有的，入站，和，出站的，流量，都，经过，这个，Sidecar代理，然后，由，Sidecar代理，来处理，服务发现、负载均衡、熔断降级、限流、重试、分布式追踪、监控、安全，等等，所有的，服务治理逻辑，业务代码，不需要，关心这些，只需要，关注，业务逻辑，就行。

Service Mesh，通常，分为，两个部分：

• 数据平面（Data Plane）： 就是，所有的，Sidecar代理，负责，处理，实际的，流量，和，服务治理逻辑。
• 控制平面（Control Plane）： 负责，管理，和，配置，所有的，Sidecar代理，比如，下发，路由规则，熔断规则，限流规则，安全策略，等等，Sidecar代理，从，控制平面，获取，配置，然后，按照配置，处理流量。

Istio的，数据平面，用的是，Envoy，一个，高性能的，C++写的，代理，控制平面，是，Istio自己，实现的，包括，Pilot（流量管理），Mixer（策略和遥测），Citadel（安全），等等。

听起来，很美好，对吧？但是，实际，用起来，踩坑，很多。

三、踩过的坑

下面，就来，详细说说，我们，踩过的，那些坑，以及，怎么解决的。

坑1：Sidecar代理，资源消耗，比想象的大

第一个坑，就是，Sidecar代理，资源消耗，比我们想象的，大很多。

我们，一开始，以为，Sidecar代理，很轻量，占不了，多少资源，所以，每个服务，旁边，部署一个，Envoy，也没太在意，资源的问题。

但是，上线之后，发现，服务器的，CPU，和，内存，使用率，涨了，很多，原来，一台服务器，能跑，10个服务，现在，只能跑，6-7个，因为，每个服务，都多了，一个，Envoy，占了，不少，CPU，和，内存。

我们，监控了一下，发现，每个Envoy，空闲的时候，大概，占，50-100MB内存，有流量的时候，CPU，也会，占，5%-10%，如果，流量大，或者，连接数多，占的，更多，我们，有，二十多个服务，每个服务，多个实例，加起来，Envoy，占的资源，很可观，相当于，多了，30%-40%的，资源消耗，成本，涨了，不少。

而且，Envoy，启动的时候，也，比较慢，要，几秒钟，才能，就绪，服务，发布的时候，要，等，Envoy，启动，好了，才能，接流量，发布时间，变长了。

解决方案：

1. 调整，Envoy的，资源配置： 我们，根据，每个服务的，流量，和，重要性，调整了，Envoy的，CPU，和，内存，request，和，limit，对于，流量小的，服务，给，少一点，资源，流量大的，服务，给，多一点，避免，资源浪费。
2. 优化，Envoy的，配置： 我们，优化了，Envoy的，配置，比如，减少，不必要的，过滤器，调整，连接池的大小，调整，超时时间，等等，减少，资源消耗。
3. 考虑，用，更轻量的，实现： 我们，也，评估了，Linkerd，Linkerd2，用Rust写的，代理，更轻量，资源消耗，更小，但是，功能，没有，Istio，强大，最后，我们，还是，保留了，Istio，但是，优化了，资源配置。
4. 不是，所有服务，都要，接入： 我们，后来，也，调整了，策略，不是，所有服务，都接入，Service Mesh，一些，内部的，简单的，不需要，复杂治理的，服务，就，不接入了，减少，资源消耗。

经验： Service Mesh，不是，免费的，Sidecar代理，会，消耗，不少，资源，接入之前，一定要，评估，资源成本，不要，以为，是，无侵入的，就，没有成本，资源成本，也是，成本，而且，可能，不低。

坑2：延迟，增加了，不少

第二个坑，就是，延迟，增加了，不少。

我们，接入Service Mesh，之后，发现，服务的，响应时间，变长了，原来，平均，几十毫秒，现在，变成了，一百多毫秒，增加了，不少，用户，也，反馈，系统，变慢了。

我们，排查了一下，发现，延迟，主要，来自，几个地方：

1. Sidecar代理，的，处理延迟： 每个请求，都要，经过，Sidecar代理，入站，一次，出站，一次，相当于，多了，两跳，每一跳，都有，一点，延迟，加起来，就，不少了，特别是，调用链，长的时候，一个请求，经过，好几个服务，每个服务，都，两跳，延迟，增加，很明显。
2. TLS加密，的，开销： Istio，默认，开启了，服务之间的，TLS加密，也就是，mTLS，双向认证，每个请求，都要，加密，解密，这个，也有，不少的，CPU开销，和，延迟。
3. Mixer，的，遥测，开销： Istio的，Mixer，负责，策略，和，遥测，每个请求，都要，调用，Mixer，上报，遥测数据，这个，也有，不少的，延迟，特别是，Mixer，性能，不好的时候，延迟，更明显。
4. 负载均衡，和，路由，的，开销： Sidecar代理，要，做，负载均衡，路由，匹配，这些，也有，一点，开销。

解决方案：

1. 关闭，不必要的，功能： 我们，关闭了，一些，不需要的，功能，比如，mTLS，我们，内部服务，之间，不需要，加密，就，关闭了，减少，加密解密的，开销，还有，一些，不需要的，遥测，也，关闭了，减少，Mixer的，调用。
2. 优化，Mixer，的，性能： 我们，优化了，Mixer的，配置，增加了，缓存，减少，不必要的，属性，和，适配器，提高，Mixer的，性能，减少，延迟。
3. 调整，超时，和，重试： 我们，调整了，服务之间的，超时时间，和，重试次数，避免，因为，超时，和，重试，导致，延迟，增加。
4. 接受，一定的，延迟： 最后，我们，也，接受了，一定的，延迟增加，因为，Service Mesh，带来了，很多，服务治理的，能力，这些，能力，也是，有成本的，延迟，就是，成本之一，只要，在，可接受的，范围内，就，可以。

经验： Service Mesh，会，增加，延迟，因为，多了，Sidecar代理，的，处理，还有，各种，治理逻辑，的，开销，接入之前，一定要，评估，延迟的，影响，特别是，对延迟，敏感的，服务，要，谨慎，考虑，要不要，接入。

坑3：连接池，问题，导致，连接耗尽

第三个坑，就是，连接池，问题，导致，连接耗尽，服务，不可用。

有一次，线上，突然，有几个服务，报错，连接超时，503错误，我们，赶紧，排查，发现，是，Envoy的，连接池，满了，连接，耗尽了，新的请求，没有，连接，可用，就，报错了。

我们，分析了一下，原因，是，Envoy的，连接池，默认配置，不太合理，默认的，最大连接数，比较小，而且，连接，空闲超时，比较长，连接，用完了，不释放，时间长了，连接池，就，满了，特别是，流量大的时候，更容易，出现。

而且，我们，有，一个服务，有，连接泄漏，调用，下游服务，之后，连接，没有，正确释放，导致，连接，一直，被占用，时间长了，连接池，就，满了。

解决方案：

1. 调整，连接池，的，配置： 我们，根据，每个服务的，流量，和，下游服务的，数量，调整了，Envoy的，连接池，配置，增加了，最大连接数，调整了，空闲超时时间，避免，连接，长时间，被占用，不释放。
2. 排查，连接泄漏： 我们，排查了，那个，有连接泄漏的，服务，发现，是，代码里，HTTP客户端，没有，正确，关闭，连接，导致，连接泄漏，修复了，代码，连接泄漏，就，解决了。
3. 监控，连接池： 我们，增加了，连接池的，监控，监控，连接池的，使用率，空闲连接数，活跃连接数，等等，当，连接池，使用率，过高的时候，及时，告警，及时，处理，避免，连接耗尽。

经验： Service Mesh，的，连接池，配置，很重要，默认配置，不一定，适合，你的，场景，一定要，根据，自己的，流量，和，服务情况，调整，连接池，配置，并且，监控，连接池的，使用情况，避免，连接耗尽，导致，服务，不可用。

坑4：熔断降级，不生效，或者，误触发

第四个坑，就是，熔断降级，不生效，或者，误触发。

我们，接入Service Mesh，一个，重要的，原因，就是，想用，它的，熔断降级，功能，但是，上线之后，发现，熔断降级，有时候，不生效，有时候，又，误触发，很头疼。

有一次，一个，下游服务，出问题了，响应很慢，按道理，应该，熔断，但是，没有，熔断，导致，上游服务，也，被拖慢了，整个，调用链，都，很慢，影响了，很多用户。

还有一次，一个，下游服务，只是，短暂的，抖动，一下，就，恢复了，但是，熔断，被，触发了，而且，很久，都，不恢复，导致，上游服务，一直，调用，失败，影响了，用户。

我们，排查了一下，原因，是，Istio的，熔断，配置，比较复杂，参数，很多，我们，没有，配置，正确，比如，熔断的，阈值，时间窗口，恢复时间，等等，配置得，不合理，导致，要么，不生效，要么，误触发。

而且，Istio的，熔断，是，基于，连接，和，请求的，和，我们，以前用的，Hystrix，的，熔断，不太一样，我们，按照，Hystrix的，经验，去配置，结果，就，不对。

解决方案：

1. 仔细，学习，Istio的，熔断，配置： 我们，仔细，看了，Istio的，文档，学习了，熔断，的，各个参数，的，含义，和，配置方法，搞清楚了，Istio的，熔断，是，怎么工作的。
2. 根据，服务情况，调整，参数： 我们，根据，每个服务的，情况，调整了，熔断的，参数，比如，错误率阈值，响应时间阈值，时间窗口，恢复时间，等等，不同的，服务，配置，不一样，不是，一刀切。
3. 测试，熔断，效果： 我们，在，测试环境，做了，很多，熔断，的，测试，模拟，下游服务，故障，抖动，等等，测试，熔断，是不是，正确，触发，和，恢复，调整，参数，直到，满意。
4. 增加，监控，和，告警： 我们，增加了，熔断，的，监控，监控，熔断，的，触发情况，恢复情况，等等，当，熔断，被，触发的时候，及时，告警，及时，处理。

经验： Service Mesh，的，熔断降级，功能，虽然，强大，但是，配置，比较复杂，不是，开箱即用的，一定要，仔细，学习，配置方法，根据，自己的，服务情况，调整，参数，并且，充分测试，才能，正确，使用，不然，要么，不生效，要么，误触发，反而，影响，服务。

坑5：分布式追踪，断链，traceId，传递，有问题

第五个坑，就是，分布式追踪，断链，traceId，传递，有问题。

我们，接入Service Mesh，另一个，重要的，原因，就是，想用，它的，分布式追踪，功能，自动，埋点，传递，traceId，不用，业务代码，手动，埋点，但是，上线之后，发现，分布式追踪，经常，断链，traceId，传递，有问题，调用链，不完整，排查问题，还是，很麻烦。

我们，排查了一下，原因，有，几个：

1. 业务代码，没有，传递，header： Istio，虽然，能，自动，处理，traceId，但是，需要，业务代码，把，相关的，header，比如，x-request-id，x-b3-traceid，等等，从，入站请求，传递到，出站请求，不然，traceId，就，断了，我们，有些服务，代码里，没有，传递，这些，header，导致，断链。
2. 异步调用，traceId，丢失： 有些，服务，用了，异步调用，比如，消息队列，线程池，等等，在，异步线程里，traceId，丢失了，导致，断链。
3. Istio，的，追踪，采样率，配置： Istio，的，分布式追踪，有，采样率，默认，采样率，比较低，很多请求，不被，采样，所以，看不到，完整的，调用链，我们，以为，是，断链，其实，是，没被，采样。
4. 不同的，追踪系统，兼容性： 我们，原来，用的是，Zipkin，Istio，也，支持，Zipkin，但是，有些，格式，不太一样，导致，追踪，显示，有问题。

解决方案：

1. 业务代码，传递，header： 我们，修改了，业务代码，把，Istio，需要的，追踪相关的，header，从，入站请求，传递到，出站请求，确保，traceId，能，正确，传递。
2. 异步调用，传递，traceId： 我们，修改了，异步调用的，代码，在，异步线程里，也，传递，traceId，比如，用，ThreadLocal，或者，上下文，传递，确保，异步调用，也，有，traceId。
3. 调整，采样率： 我们，调整了，Istio的，追踪，采样率，根据，需要，调整，合适的，采样率，既能，看到，调用链，又，不会，因为，采样太多，影响，性能。
4. 统一，追踪系统： 我们，统一了，追踪系统，都用，Zipkin，格式，确保，兼容性，显示，正常。

经验： Service Mesh，的，分布式追踪，不是，完全，自动的，还是，需要，业务代码，配合，传递，相关的，header，特别是，异步调用，要，注意，传递，traceId，不然，还是，会，断链，而且，采样率，也要，配置，合适，不然，很多请求，看不到，调用链。

坑6：配置下发，延迟，或者，失败

第六个坑，就是，配置下发，延迟，或者，失败。

Istio，的，配置，是，从，控制平面（Pilot），下发到，Sidecar代理（Envoy）的，我们，有时候，修改了，配置，比如，路由规则，熔断规则，等等，但是，很久，都，不生效，或者，有些，Sidecar，生效了，有些，没生效，很头疼。

我们，排查了一下，原因，有，几个：

1. Pilot，性能，瓶颈： Pilot，负责，下发，配置，当，服务，数量多，配置，复杂的时候，Pilot，性能，会，有，瓶颈，下发，配置，很慢，甚至，失败。
2. 网络，问题： Pilot，和，Envoy，之间，的，网络，有问题，比如，延迟，丢包，导致，配置，下发，失败，或者，延迟。
3. Envoy，配置，更新，有，延迟： Envoy，收到，配置，之后，更新，配置，也，需要，一点时间，不是，立刻，生效。
4. 配置，有，错误： 有时候，我们，写的，配置，有，错误，Pilot，校验，不通过，就，不下发，导致，配置，不生效。

解决方案：

1. 优化，Pilot，的，性能： 我们，增加了，Pilot的，资源，CPU，内存，优化了，Pilot的，配置，提高，Pilot的，性能，减少，配置下发，的，延迟。
2. 监控，配置下发： 我们，增加了，配置下发，的，监控，监控，Pilot，的，状态，配置下发，的，延迟，成功率，等等，当，配置下发，有问题的时候，及时，告警，及时，处理。
3. 检查，配置，的，正确性： 我们，修改了，配置，之后，先，校验，配置，的，正确性，用，istioctl，工具，校验，确保，配置，没有，错误，再，下发。
4. 等待，配置，生效： 我们，修改了，配置，之后，会，等待，一段时间，让，配置，下发，生效，再，验证，不会，立刻，就，认为，配置，不生效。

经验： Service Mesh，的，配置下发，是，异步的，不是，立刻，生效的，而且，可能，有，延迟，或者，失败，修改了，配置，之后，要，等待，一段时间，再，验证，并且，要，监控，配置下发，的，状态，确保，配置，正确，下发，生效。

坑7：版本，兼容性，问题，升级，很麻烦

第七个坑，就是，版本，兼容性，问题，升级，很麻烦。

Istio，更新，很快，经常，有，新版本，我们，一开始，用的是，0.几的版本，后来，想，升级到，新版本，但是，发现，升级，很麻烦，很多，配置，API，都，变了，不兼容，升级，要，改很多，配置，还要，测试，很麻烦，而且，升级，过程中，还，可能，出问题。

我们，有一次，升级，Istio，版本，结果，升级之后，有几个，服务，出问题了，调用，失败，排查了，很久，才发现，是，新版本，的，某个，配置，默认值，变了，和，老版本，不一样，导致，行为，变了，服务，出问题，熬了，一个通宵，才，解决。

而且，Istio，的，版本，很多，0.x的版本，API，变化，很大，经常，不兼容，升级，成本，很高。

解决方案：

1. 谨慎，升级，版本： 我们，后来，升级，Istio，版本，很谨慎，不会，追新，有，新版本，就，升级，而是，看，新版本，有没有，我们，需要的，功能，或者，修复，重要的，Bug，才，升级，而且，升级之前，会，仔细，看，发布说明，看，有没有，不兼容的，变化。
2. 测试环境，充分测试： 升级，之前，我们，会，在，测试环境，充分测试，升级，新版本，然后，测试，所有的，服务，和，功能，确保，没有问题，再，在，生产环境，升级。
3. 灰度，升级： 生产环境，升级，我们，用，灰度，升级，先，升级，一部分，服务，或者，一部分，实例，观察，一段时间，没有问题，再，全部，升级，避免，全部，升级，出问题，影响，所有用户。
4. 保留，回滚，方案： 升级，之前，我们，会，准备，回滚，方案，如果，升级，出问题，能，快速，回滚，到，老版本，减少，影响。

经验： Service Mesh，特别是，Istio，更新，很快，版本，兼容性，可能，有，问题，升级，一定要，谨慎，不要，追新，升级之前，要，仔细，看，发布说明，充分测试，灰度升级，并且，准备，回滚，方案，不然，升级，出问题，影响，很大。

坑8：监控告警，缺失，出问题，不能，及时发现

第八个坑，就是，监控告警，缺失，出问题，不能，及时发现。

我们，一开始，接入Service Mesh，之后，监控告警，没有，跟上，只，监控了，业务服务的，指标，没有，监控，Service Mesh，的，指标，比如，Sidecar代理，的，CPU，内存，连接池，延迟，错误率，控制平面，的，状态，配置下发，的，状态，等等，导致，Service Mesh，出问题了，我们，不能，及时，发现，等，用户，反馈了，才，知道，很被动。

比如，有一次，一个，Sidecar代理，内存，泄漏，慢慢，涨，最后，OOM了，服务，不可用，但是，我们，没有，监控，Sidecar的，内存，所以，没有，及时，发现，等，用户，反馈了，才，知道，已经，影响了，不少用户。

解决方案：

1. 完善，监控： 我们，完善了，监控，增加了，Service Mesh，的，各个，组件，的，监控，包括，Sidecar代理（Envoy），的，CPU，内存，连接池，延迟，错误率，流量，等等，控制平面（Pilot，Mixer，Citadel），的，CPU，内存，状态，配置下发，的，延迟，成功率，等等。
2. 增加，告警： 我们，增加了，告警，当，Service Mesh，的，指标，异常的时候，比如，Sidecar的，CPU，内存，过高，连接池，使用率，过高，延迟，过长，错误率，过高，控制平面，异常，配置下发，失败，等等，及时，告警，通知，我们，及时，处理。
3. 可视化，大盘： 我们，做了，Service Mesh，的，可视化，大盘，用Grafana，展示，Service Mesh，的，各个，指标，能，直观地，看到，Service Mesh，的，状态，出问题了，能，快速，定位。

经验： Service Mesh，本身，也是，一个，复杂的，系统，有，很多，组件，一定要，完善，监控告警，监控，Service Mesh，的，各个，组件，的，状态，不然，Service Mesh，出问题了，不能，及时，发现，会，影响，业务。

坑9：学习曲线，陡峭，运维成本，高

第九个坑，就是，学习曲线，陡峭，运维成本，高。

Service Mesh，特别是，Istio，很复杂，概念，很多，配置，很多，组件，很多，学习起来，很费劲，我们，团队，花了，很多时间，学习，才，基本，搞懂，而且，运维，也，很麻烦，出问题了，排查，很复杂，要，懂，Service Mesh，的，原理，和，配置，还要，懂，网络，代理，等等，对，团队的，技术能力，要求，很高。

我们，一开始，只有，一两个人，懂，Istio，其他人，都，不懂，出问题了，只能，找，那，一两个人，压力，很大，而且，那，一两个人，请假了，或者，离职了，就，麻烦了。

而且，Service Mesh，的，运维，也，增加了，很多，工作量，比如，升级，版本，配置，管理，问题排查，等等，运维成本，比，原来，高了，不少。

解决方案：

1. 团队，培训： 我们，组织了，团队，培训，分享，Service Mesh，的，知识，让，更多的人，懂，Service Mesh，不要，只有，一两个人，懂，避免，单点，依赖。
2. 文档，沉淀： 我们，沉淀了，Service Mesh，的，文档，包括，安装，配置，常见问题，排查方法，等等，方便，团队，查阅，出问题了，能，快速，找到，解决方案。
3. 简化，使用： 我们，封装了，一些，常用的，配置，模板，团队，使用的时候，不用，写，复杂的，配置，只用，填，几个，参数，就行，降低，使用，的，门槛。
4. 考虑，成本，和，收益： 我们，也，重新，评估了，Service Mesh，的，成本，和，收益，不是，所有服务，都，接入，只，对，需要，复杂治理的，核心服务，接入，减少，运维，的，工作量。

经验： Service Mesh，很复杂，学习曲线，陡峭，运维成本，高，接入之前，一定要，评估，团队的，技术能力，和，运维成本，能不能，hold住，不要，盲目，接入，不然，反而，增加，团队的，负担。

四、反思和总结

踩了，这么多坑，我们，也，做了，反思，和，总结。

1. Service Mesh，不是银弹： Service Mesh，不是，银弹，不是，接入了，就，万事大吉了，它，能，解决，一些，微服务治理的，问题，但是，也会，引入，一些，新的，问题，比如，资源消耗，延迟增加，复杂度增加，运维成本，增加，等等，所以，要不要用，什么时候用，怎么用，都要，谨慎，考虑，不要，盲目跟风。

2. 适合的场景： Service Mesh，适合，以下，场景：

• 微服务，数量，很多，服务治理，很复杂，需要，统一的，治理方案。
• 多语言，微服务，需要，统一的，服务治理，和，可观测性。
• 对，服务治理，的，要求，很高，需要，精细的，流量管理，安全，策略，等等。
• 团队，有，足够的，技术能力，和，运维能力，能，hold住，Service Mesh。

3. 不适合的场景： Service Mesh，不适合，以下，场景：

• 微服务，数量，很少，服务治理，简单，不需要，复杂的，治理方案。
• 对，延迟，很敏感，不能，接受，延迟增加。
• 资源，很紧张，不能，接受，Sidecar代理，的，资源消耗。
• 团队，技术能力，不足，运维能力，不足，不能，hold住，Service Mesh。
• 项目，很小，或者，短期，项目，不值得，投入，这么多，成本。

4. 接入，的，建议： 如果，决定，接入，Service Mesh，建议：

• 先，充分，调研，和，测试，在，测试环境，充分，验证，性能，功能，稳定性，等等，再，考虑，生产环境，接入。
• 不要，一下子，全部，接入，先，从，几个，非核心的，简单的，服务，开始，试点，积累，经验，再，逐步，推广，到，更多的，服务。
• 完善，监控告警，接入之前，就要，考虑，监控告警，接入之后，要，完善，监控，Service Mesh，的，各个，组件，的，状态。
• 团队，培训，和，文档，沉淀，让，团队，都，懂，Service Mesh，沉淀，文档，方便，使用，和，排查问题。
• 谨慎，升级，版本，不要，追新，升级之前，充分，测试，灰度，升级，准备，回滚，方案。

五、写在最后

Service Mesh概念踩坑记：那些让我熬夜的问题。

Service Mesh，是，一个，很好的，概念，能，解决，很多，微服务治理的，问题，但是，它，也，不是，银弹，会，引入，一些，新的，问题，增加，系统的，复杂度，和，运维成本，所以，要不要用，什么时候用，怎么用，都要，谨慎，考虑，不要，盲目跟风。

我们，踩了，很多坑，熬了，很多通宵，但是，也，学到了，很多，积累了，很多，经验，现在，Service Mesh，在，我们，团队，也，运行得，比较稳定了，确实，给我们，带来了，很多，好处，比如，统一的，服务治理，分布式追踪，监控，安全，等等，但是，我们，也，付出了，不少，成本。

希望，我的，踩坑经历，能，给大家，一些，参考，让大家，少踩，一些坑，少熬，一些通宵，根据，自己的，实际情况，谨慎，选择，是不是，要用，Service Mesh，以及，怎么用。

最后，用一句话结尾：

"任何，技术，都，不是，银弹，有，优点，也有，缺点，有，适用的，场景，也有，不适用的，场景，不要，盲目跟风，要，根据，自己的，实际情况，谨慎，选择，适合自己的，才是，最好的。"

祝大家，都能，选对，技术，少踩坑，系统，稳定运行，工作顺利！