架构师成长之路之Servicemesh罪与罚

前言

现在市面上有非常多介绍Servicemesh概念、架构、方法论以及标准化实现的文章，但是对于Servicemesh应该如何才能被真正有效可靠的落地，我们会面临哪些困难选择，并未太多提及。本文希望从这个角度出发，结合笔者在生产环境落地中的一些经验和踩过的坑，探讨如何才能更好地让系统演进到Servicemesh架构。如果对于Servicemesh本身概念、发展现状以及为什么需要它不清楚的话，可以先阅读架构师成长之路之服务治理漫谈一文。此处不复赘述。以下我们直接进入正题。

考虑过资源上的损耗吗？

mesh本质上相当于寄生在业务机器上。使用的是业务机器的资源。实际上的测试中发现，由于采用了c++/go实现的mesh对于内存的消耗比较可控，默认情况下只占用几M，在高并发下一般也只会上升至几十M。这对于正常情况下8G/16G内存的应用机器来说基本可以忽略不计。所以内存的额外占用这个问题可以基本忽略。但是其对于cpu资源的消耗则较大，一般会趋近于业务正常使用的cpu资源量。这意味着，加入了mesh之后，有可能业务能使用的cpu资源只剩下本来的一半。这就是一个比较大的问题了。

关于这个问题，目前业内的主要论述认为，由于正常业务机器的资源使用率不到10%，所以这部分的额外占用在实际情况下并不会对业务造成实质性的影响，反而可以让我们更好地利用上闲置资源，避免浪费。业务与mesh互利共赢。

这个逻辑，在未来很长一段时间内肯定都是成立的。但是，我认为基于这个逻辑，会衍生出的两个新问题：

1. 资源不会无限期闲置。我们已经注意到，由于涉及到成本分摊，现在越来越多的业务方对于资源使用已经越来越重视，加上未来的主流趋势云原生的目标之一也是希望提升机器资源使用率。按着这个趋势，当有一天资源利用率的问题已经被相对妥善地解决了，那mesh对于CPU占用的这个问题就会凸显，届时将如何解决这一问题呢？如果让mesh绑定单独cpu核或者采取绑定单独pod资源的方式来和每个业务实例资源做区隔，那必然也会带来不小的成本浪费。
2. 资源使用率这个数字之外，还有业务高低峰问题。我们都知道业务是有高低峰的。比如外卖业务每日饭点是高峰，酒店业务每到节假日是高峰，电影票业务每到春节是高峰。有高低峰就说明肯定会有资源的适当冗余。所以虽然看着资源使用率不高，但是真到了高峰，部分业务的系统cpu资源会飙升甚至趋近于打满，这种情况下如果引入mesh，则给业务方的直接感受就是：高峰期业务处理能力下滑一半。我相信业务方听到这个结论后都会表示无法接受。这个时候怎么处理这一问题呢？除了业务方扩容一倍机器之外，还有解法吗？

这看似是一个无解的命题，因为servicemesh的架构就是这样。资源也就是这些，不会凭空多出来。但是，笔者想问一下，我们是不是可以打破servicemesh的架构ÿ