前言
昨天看到一篇讲述Sidecar的文章，发现对这个组件的理解还不够透彻，所以在这里整理一下我对“三轮边车”的认识。了解过Service mesh的对Sidecar应该不会陌生。下面我会简单讲述一下传统服务到微服务的一个转变，以及微服务的几种服务发现模式。
服务的转变
早期的时候，所有的服务都部署在一台机子上。当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
当随着访问量增大，为了有效解决高并发问题，可以将单一的应用部署成多台机器，构成一个简单的集群 。
但随着垂直应用越来越多，应用之间交互不可避免，如果还只是简单将所有应用部署成多台机子，就会造成一些功能块的重复部署，如支付模块在多个应用有涉及，不应该每一个应用都部署一份支付模块的代码，而是将一些核心服务抽取出来做成一个微服务，提供给这些应用使用。
这个时候为了保证微服务的可靠，单个微服务需要部署成集群。在分布式的应用中，避免不了的一个问题就是服务发现了。即如果某块微服务部署成集群后，消费者该如何发现这些服务对应的IP地址呢？！
这个就是下面要讲的服务发现模式了。
传统集中式代理
最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署。
常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，软硬结合两层代理也是业内常见做法。
如通过Nginx实现负载均衡， 所有的服务地址由运维人员手动配置，消费端直接将请求发给代理，代理解析目标地址然后做负载均衡。
但是！！如果某个服务挂了没有办法发现。Nginx也不知道哪台挂了，照常的向宕机的发送请求。总不能每次都一挂都手动去修改Nginx的配置吧！！而且Nginx这么重要如果也挂了怎么办？！！ 虽然可以使用keepalived来保证可靠性。
客户端嵌入式代理
客户端嵌入式代理，这种模式一般需要独立的服务注册中心组件配合。引入一个服务中心，如Zookeeper、Eureka可以实现注册和发现。通常服务中心有心跳监测，所以不用担心服务宕机之后的问题。
但是！！它对于消费端和生产端都有侵入。在生产端需要在服务启动的时候往服务中心进行注册。同时消费端需要有服务的发现。针对编程人员，通常只需要关注的是CURD，这服务发现部分对新同事不够友好，有学习成本！！！
主机独立进程代理
上面两种的方法都有不足点，主机独立进程代理是上面两个方法的折中。
该方法会在一个消费端机子上启动一个 代理进程。 注意！！ 这里不是单独起了一个集中式的代理，而是在每一个消费端中启动一个代理进程。即一个主机的所有消费端使用一个这个代理！！
这里需要说明的是，这个和传统集中式代理有什么区别呢？先是请求一个代理，然后这个代理再去请求服务中心，为什么要这么做，有这个必要吗？
首先这种模式它的确解决了传统代理中的一些弊端，如手动配置服务端代理，且服务宕机无法解决的问题。第二，因为这个代理和消费端是处于同一个机子，它们完全可以使用localhost进行通信，原本的服务发现是嵌入在消费端，现在直接有这个代理来做了，这也解决了客户端嵌入式的弊端。
Sidecar
在上面讲的三种服务发现的模式，那么Sidecar和这些模式有什么联系嘛？！其实Sidecar就是上面的第三种模式了。Sidecar译为“边车三轮车”。
吃鸡游戏中，开车的一个人负责认真开车，而坐在边车的人可以看地图或者开枪！！！ 这就是无嵌入式的添加功能。和主机独立进程代理一样，添加了一个代理来做服务的发现，原本由消费端来做的，现在添加了一个边车，让坐在边车的容器来做服务发现。
再举个例子，比如我们可以在一个web-server的容器中配置一个sidecar ，这个sidecar可以去读取web-server产生的日志，做成了日志监控的“边车”。这个就是我理解的Sidecar了，有说错的地方可以给个issue。