0、前言
微服务，相信大家已经不陌生了。传统的单体应用有很多缺点，比如：代码数据集中管理、开发效率低、启动慢、可靠性差、技术单一等。而微服务则有很多优点，比如：按照功能拆分、自治、松耦合、跨语言、轻量级通信等。
我们来逐步拆解其中的细节部分，首先介绍微服务间的三大通信方式：基于网关 API、基于 RPC 和 基于 SideCar 的方式。
1、基于网关 API
简单来说，网关 API 的功能可以分为四部分：
1). 请求接入
为各种应用提供统一的服务接入
处理所有的接入请求
2). 治理策略
包括负载均衡、限流、熔断、超时重试、 灰度发布、协议适配、流量监控、日志统计等
3). 认证鉴权
包括用户鉴权、身份校验、黑白名单管理、防web攻击等
4). 统一管理
管理所有的服务及策略
提供配置管理的工具
2、基于 RPC
RPC 指远程服务调用(remote process call)，假如两个应用 A 和 B 分别部署在两台服务器上，如果 A 想要调用 B 应用上的函数，由于不在同一个内存空间，怎么办呢?则需要通过网络来表达需要调用的语义和传达调用的数据。
主流 RPC 框架有 Dubbo、gRPC、bRPC 和 Thrift
从 github star 来看，Dubbo > gRPC > bRPC > Thrift.
3、基于 SideCar
提到 SideCar，总是会联系到 Service Mesh，何为 Service Mesh?Service Mesh 表征了云上应用了 SideCar 技术后服务之间呈现出来的一种关系，如下图所示：
SideCar 可以说是后 Kubernetes 时代诞生的技术。它与原生 Kubernetes 的关系如下图所示：
原生 K8S 中每个 node 里有一个 kube-proxy，而 Service Mesh 中每个 pod 里都有一个 proxy(SideCar)，这个 proxy(上图中蓝色部分) 可以是独立容器部署，也可以和业务进程(上图中绿色部分)共同部署在一个容器里。node 里的多个 proxy 是同一个 proxy 的相同副本。这也很好理解嘛!如果每个业务进程都有一个不同的 proxy，那 SideCar 的存在就没意义了嘛。
使用 Service Mesh 并不是说它会与 Kubernetes 决裂，而是它会自然而然地发生。 Kubernetes 的本质是通过声明式配置进行应用生命周期管理，而 Service Mesh 的本质是提供应用之间的流量和安全管理和可观察性。
SideCar 的代表性技术是 istio，其控制面实现是 Envoy.
Istio Service Mesh 可以使用 Kubernetes 中的服务进行服务注册。它还可以通过控制平面的平台适配器连接到其他服务发现系统，然后生成数据平面的配置(使用CRD语句，存储在etcd中)，数据平面的透明代理。
『透明代理』部署在每个应用服务 pod 中的 sidecar 容器中。这些代理需要请求控制平面同步代理配置。之所以是透明代理，是因为没有应用容器完全感知代理，进程 kube-proxy 组件喜欢阻塞流量，但是 kube-proxy 阻塞了 Kubernetes 节点的流量，而 Sidecar 代理阻塞了 pod 之外更多信息。
