让我们一起来看看我们如何使用 sidecar 来解决微服务架构中横切关注点，例如授权、缓存、配置秘密管理和可观察性。
跨领域问题
让我们从解释横切关注点开始。
应用程序的不同层需要应用程序业务代码之外的一些需求。
例如日志记录、配置、缓存、授权、可观察性……
传统开发
传统的方法是在我们的开发服务中编码和使用所有这些工具。如果我们有用相同语言编写的不同服务，我们可以在服务之间共享这些代码，并将它们用作服务之间的包/库。
那么什么是糟糕的场景呢？
在使用多种语言编写服务的环境中，必须使用每种语言重新实现这些要求。
想象一下，您（或您的团队）用不同的语言一遍又一遍地编写相同的功能……
在这种情况下是否有解决方案而不是编写相同的代码？
首先想到的是为这些需求编写单独的 API 服务。
那么这是一个正确的解决方案吗？
我们会遇到什么问题？
当消费者服务的数量增加时，如何扩展这些共享服务？
将应用程序代码移动到通过网络访问的另一个服务将导致我们的应用程序的网络延迟（延迟）。它会减慢我们的应用程序。
那么，如果你不想用不同的语言重写相同的故事，或者面对网络延迟，你会怎么做？
答：我们将使用边车模式。
边车模式
那么这个边车是什么？
我们可以在 Kubernetes 上运行的 pod 中运行多个容器。我们可以将在主应用程序容器旁边运行的容器称为边车。
这些附加功能可以用一种语言开发，然后我们可以将它们“注入”到我们的应用程序中。我们使用 Go 语言开发我们的 sidecar，并将它们注入到微服务中。
这种“注入”操作是由 Kubernetes 基于一个名为Dynamic Admission Webhook的概念执行的。
当一个 pod 扩大规模时，额外的边车也随之而来。
此外，使用专门为跨 sidecar 共享的 pod 创建的网络接口，可以忽略网络延迟，因为它位于 localhost 之上。
边车还能做什么？
- Pod 网络配置
- Pod 网络请求/响应可以被中断/操纵
- 可以制作服务网格
- 可以做微服务运行时实现
例如，Istio Service Mesh 可以作为 sidecar 工作。pod 的整个网络控制由传入的 istio-proxy 作为 sidecar 接管，并且可以操纵传入和传出的请求/响应。
您可以编写各种网络规则。当整个网络通过 istio-proxy sidecar 时，所有网络进程都有度量数据，我们可以可视化微服务间服务调用。