注：转载自TVP专栏
陈超，腾讯云TVP（腾讯云最具价值专家），历任百度凤巢某业务团队技术负责人、丁丁租房基础架构与运维部负责人，现猫眼娱乐基础架构负责人。参与国内最大的商业广告平台“凤巢系统”服务化过程，从 0-1 搭建丁丁租房整体业务微服务架构和基础架构体系，从 0-1 搭建猫眼娱乐基础架构体系。具备 8 年互联网工作经验，在服务治理领域具备丰富经验。
现在市面上有非常多介绍Servicemesh概念、架构、方法论以及标准化实现的文章，但是对于Servicemesh应该如何才能被真正有效可靠的落地，我们会面临哪些困难选择，并未太多提及。本文希望从这个角度出发，结合笔者在生产环境落地中的一些经验和踩过的坑，探讨如何才能更好地让系统演进到Servicemesh架构。如果对于Servicemesh本身概念、发展现状以及为什么需要它不清楚的话，可以先阅读一文。此处不复赘述。以下我们直接进入正题。
mesh本质上相当于寄生在业务机器上。使用的是业务机器的资源。实际上的测试中发现，由于采用了c++/go实现的mesh对于内存的消耗比较可控，默认情况下只占用几M，在高并发下一般也只会上升至几十M。这对于正常情况下8G/16G内存的应用机器来说基本可以忽略不计。所以内存的额外占用这个问题可以基本忽略。但是其对于cpu资源的消耗则较大，一般会趋近于业务正常使用的cpu资源量。这意味着，加入了mesh之后，有可能业务能使用的cpu资源只剩下本来的一半。这就是一个比较大的问题了。
关于这个问题，目前业内的主要论述认为，由于正常业务机器的资源使用率不到10%，所以这部分的额外占用在实际情况下并不会对业务造成实质性的影响，反而可以让我们更好地利用上闲置资源，避免浪费。业务与mesh互利共赢。
这个逻辑，在未来很长一段时间内肯定都是成立的。但是，我认为基于这个逻辑，会衍生出的两个新问题：
这看似是一个无解的命题，因为servicemesh的架构就是这样。资源也就是这些，不会凭空多出来。但是，笔者想问一下，我们是不是可以打破servicemesh的架构，或者说，优化servicemesh的架构？
回顾下我们第一讲里面介绍服务治理发展史时候提到的三个重要的思潮：
Server Proxy
Smart Client
Local Proxy
Servicemesh即属于Local Proxy之一，可以解决与业务方强耦合、语言强相关、单点等问题。但其他思潮就一无是处吗？显然答案是否定的。其他的方式仍然具备着强大的生命力和存在的价值。我们的解决方案即使用Server Proxy作为闲置资源不够时的兜底方案，采取逻辑上的Central Mesh来解决上述的问题：
Central Mesh装载有所在区域所需的的所有信息，承担起Sidecar的所有能力。即Central Mesh也作为所在区域Sidecar的backup，在Sidecar失灵或者闲置资源不足以正常运转Sidecar的情况下，主动切换流量。
Central Mesh之所以称之为“逻辑上”，是因为Central Mesh不一定是就一组中央集群，而是可以分散就近部署，以尽量降低网络延时和单点带来的额外风险。比如可以按机房、按地域、按网关甚至就近部署到上。
性能上的损耗是回避不了的一个问题。由于多进行了一次转发以及要进行服务治理，所以性能天然地比直连RPC的方式的性能要差。基于我们实际的性能测试结果，其相比于直连，mesh方式的性能会退化20-50%左右，这还是在不采用iptables这种更耗性能的方式下进行的测试。当然，这个增加的延时在毫秒级，对于大部分的业务要求来说，其实是可接受的。对业务性能的影响微乎其微。
但是，我们还是需要考虑如下的潜在问题：
所以针对以上问题，一方面，我们需要对于性能的退化有心理预期，另一方面，我们也应该竭尽所能地优化甚至压榨servicemesh的性能极限，而不是说选择了mesh就放弃了性能听之任之了。想想netty著名的压榨性能到极致的“eventloop挑选”。
在mesh的通讯性能优化上，有几个可以考虑的点：
还有很多其他的性能优化手段，此处就不再一一列举。
我们去做Servicemesh的一大初衷，是为了解决和业务强耦合的现状，进行了服务治理能力的下沉。但是，下沉的时候，我们发现，服务治理本身也囊括了非常多的东西，动态配置、流控、熔断、故障演练、、路由、通讯、服务注册发现、集中式日志、分布式链路调用、监控埋点等等。这些东西都一股脑地揉入到一个单薄的Sidecar里。我们做这一件事的时候，是不是也需要开始审视一下，服务治理本身那么多的功能之间是不是也有类似的问题，会产生组织层面和技术层面的相互干扰、依赖、影响甚至是冲突？没错，这就是会延伸出来的问题。
以上都是可能带来的问题，当然，你可以用隔离舱，可以用热部署，可以代码仓库想办法分割。但是，当一切都下沉的时候，面对本来七八个团队一起管理维护的能力集，你真的能很好地解决上述的问题吗？
我们建议，这种时候，拆开Sidecar吧。以一定的规则，基于你的mesh所在的发展阶段综合考虑，拆开你的Sidecar。也许拆开它，一切就都解决了。需要关注的是，拆开的Sidecar不宜过多，否则会导致Sidecar泛滥而花费高昂的运维升级成本。所以你看，是不是和服务化的历程有些类似，都在“拆拆拆”的过程中，简化问题，同时引入新的问题？这才是我们所身处的事业的美妙之处，因为你总能在一些看似不相关的地方找到他们的相似之处。
Pilot可以进行服务订阅，并桥接到XDS接口体系中。但是，为什么没有进行服务注册的能力呢？笔者猜测这是因为Servicemesh是在云原生背景下基于Local Proxy所演进而来的。而Local Proxy在云原生方案里面，基本都不会负责服务注册，因为他们会将服务注册交给云（Mesos、Marathon、K8s等都有现成方案）来实现，或者会一般会结合consul/etcd/zk单独另起agent来完成服务注册。此时Local Proxy则朴素地只关注反向代理的工作。
而这，对于我们实际生产环境的使用来说，则显得没那么友好。因为业务发展到一定阶段，一般都有自己的一套服务治理框架，采用自己的服务注册订阅方式。他们不太可能为了将服务治理mesh化，反而把整套服务订阅发布体系迁移到云原生体系中去，那就有点本末倒置了。所以就必然会选择进行适配。而适配的过程中，为了使用上服务订阅发布，他们就不得不深度改造Sidecar，加入服务注册的能力，再让Sidecar对接第三方的注册中心。工作繁琐复杂的同时，也打破了Servicemesh希望控制平面屏蔽基础设施差异性的初衷。
所以笔者认为Servicemesh是需要彻底屏蔽掉具体注册中心的存在的。发布和订阅应该都经过Pilot，为使用方提供统一门面。以后无论注册中心如何切换，都无需再深度侵入修改Sidecar。
这是一个老大难的问题。控制面板中的Mixer现在基本是处于一个“墙倒众人推”的地步。Istio比较偏执地将其单拎出来，处理限流和数据遥测等事宜。前者会带来很大的性能瓶颈（即使Istio后续在Envoy中增加了缓存机制也无力回天），后者会带来双倍的流量消耗。很多Servicemesh的实现都摒弃或者简化了Mixer。网上对应的文章有不少，此处不复赘述。
虽然Istio的这一设计太过于理想化，希望通过这种方式屏蔽基础设施差异性，然后为Sidecar提供无限庞大的内存容量支持，同时将一些复杂多变逻辑尽可能剔除出Sidecar，来保证Sidecar尽可能稳定可靠。但是现实还是很残酷的，有通讯的地方就会产生问题。分布式环境的复杂性大半就是由于网络导致的。
而如果将Mixer一股脑地下沉，则不得不面对各种复杂逻辑下如何保障Sidecar本身足够稳定可靠，消耗足够少资源，引入尽量少依赖，足够小而美的状态？
虽然控制面试和数据面板的切割是一个很困难的命题，而Istio这方面也引起了一些吐槽，但是从先驱者的角度上来看，Istio成功整合了发展了很长时间的Local Proxy方案，并将其上升到了方法论的高度，成功引发了业内对于控制面板和数据面板的体系化思考，这才是Istio做出的最大贡献，这是一场从战术到战略的变革，从术到道的创新。