本文转载自微信公众号“小姐姐的味道”，作者小姐姐养的狗。转载本文请联系味觉小姐公众号。嘿，又堵车了。记忆力好的同学一定记得我们开朗的江铃。拥有一辆江铃，让呼啸的风透过车窗打在脸上，是一件无比享受的事情。这次的车不一样。有点高级。猛烈驾驶时，风可以吹掉头盔。仔细看看上面的车，它有三个轮子。其中，左边多出的轮子和座位称为边车。它是可拆卸的，装上后就可以带上去兜风了。边车模型（sidecar）就像梅超风之于陈旋风，莫邪之于干将。因为它与更前沿的ServiceMesh概念息息相关，所以很容易让人望而却步。如果随便在网上搜索一下，就会发现晦涩难懂的概念。要了解下一代微服务并未雨绸缪，你需要啃一些枯燥的知识。通过我的介绍，你会发现sidecar模式是一种高度抽象的模式。不过别担心，我们仍然可以驾驶这辆怪异的车辆。它的概念很简单，但使用上有很多限制。一步步升级注意：以下都是sidecar模型，但是有些sidecar模型真的很简单。<1>大家都知道微服务很复杂，会引入一系列的问题，所以服务治理就显得尤为重要。比如日志采集、服务监控、服务治理等。比如上图中，我们在一台Linux服务器上部署了四个进程。其中，webservice是最重要的进程，其他进程只是作为一些附加功能部署。其实这三个圈就是sidecar的作用。只要挂载了，上面的服务就有这些功能。但是对于这三个组件的配置，还是比较复杂的。我们需要大量的重复性工作。<2>上图通过将web应用程序与我们的辅助应用程序打包在一起，进一步增强了不变性。在容器的支持下，我们可以按照约定简化打包发布操作。例如，上述组件可以直接通过localhost进行通信。但遗憾的是，我们的辅助程序都是在docker容器中作为进程启动的。这种“富容器模式”缺陷较多，不符合不可变基础设施的理念，不值得推荐。<3>k8s的pod是在container的基础上进一步抽象出来的。一个Pod可以包含多个容器。如下图所示，基础服务和web服务可以独立搭建，最终以Pod为载体搭便车。为了更清楚地看到这个过程，下图以日志采集为例，介绍两个pod和一个docker容器对同一个日志采集的拓扑图。从上面的演化过程我们可以看出。sidecar只是一个辅助或基本程序。但是如何方便地管理这些额外的程序，我们有不同的组织方法。只有高度的抽象，才能进行方便的组装和设计。<4>至此，我们就可以看看ServiceMesh的两张经典图了。我们将Web应用程序（业务服务）抽象为绿色方块。然后将辅助组件（sidecar）抽象成一个蓝色方块。在一个相对简单的环境中，我们的部署是这样的。由于辅助组件不能单独存在，所以都依附于绿色服务。我们画出服务集群的血肉（Web服务），只留下它的骨架（sidecar），我们可以得到如下图，这就是ServiceMesh。可以看到里面的连接线很复杂，人工是做不到的，只能靠平台来管理。只要缩放任何东西，它就会反映出它的复杂性。这只是一个只有36个服务节点的拓扑图。不要小看这个蓝色的小方块。它既可以是一个辅助程序，也可以是一个基础设施。今天典型的服务网格分为“数据平面”和“控制平面”。大部分落地企业采用代理的方式实现数据平面，控制平面的实现有限。像比较流行的Istio，通过负载均衡、服务间认证、监控等，可以轻松创建一个已经部署了服务的网络，服务代码几乎不需要改动。Istio支持通过在整个环境中部署一个特殊的sidecar代理来添加到服务中，它拦截微服务之间的所有网络通信，然后使用其控制平面功能来配置和管理Istio。我们来看看它的官方功能描述：HTTP、gRPC、WebSocket和TCP流量的自动负载均衡。通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。支持访问控制、速率限制和配额的可插拔策略层和配置API。自动测量、记录和跟踪集群内的所有流量（包括集群的入口和出口）。在具有强身份验证和基于授权的集群中启用安全的服务间通信。可以说，ServiceMesh剥离了业务属性，只剩下一个大网络，涵盖了运维和基础服务的所有工作。不能说没有使用成本。其中，比较重要的有两点：网络数据包经过层层代理和转发（大使模式），效率会降低，故障排除也会变得困难。需要根据这个网格的规范进行改造，也就是写一堆适配器（Adapter模式）。SpringCloud的Sidecar说到适配器，不免会想到SpringCloud的Sidecar。想玩转Java的新概念，怎么能少了Spring家族呢？SpringCloud还有一个sidecar组件，其maven坐标如下。
