【云原生架构】库(Library ) vs 服务(Service ) vs Sidecar(边车)

所有软件应用程序都由可重用的元素组成。这些可重用元素的目标和功能从基础设施级别到安全级别到业务能力各不相同。
本文的目的是比较用于构建和部署这些可重用元素的不同方法。

这是重用代码的最广泛使用的方法。可重用代码作为库开发和发布。在这种方法中，客户端应用程序将库定义为直接依赖项，使用提供的 API 并将其代码与主应用程序逻辑一起发送。库和主应用程序逻辑的代码作为同一进程/容器的一部分执行。

优点

• 延迟：库中的代码与主应用程序在同一进程中执行，因此没有网络延迟。

• 可用性：整体可用性很高，因为没有网络分区（CAP 定理）。

• 易于使用：使用非常简单。

• 环境上下文：库可以访问环境上下文（内存、CPU 等），因为它们是同一容器的一部分。

缺点

• 资源：内存、CPU 等资源与主应用程序共享。这意味着库的性能会对主应用程序产生副作用。

• 技术：库中使用的库与主要应用程序的库相同，因此，如果组织有不同的应用程序集，则每种语言都需要多个实现。

• 可维护性：库中的任何错误修复都需要对所有客户端应用程序进行代码更改和测试。

下一个最广泛使用的模式是为可重用功能定义服务。在这种方法中，应用程序使用请求-响应机制进行网络调用以调用另一个服务。服务和主要应用程序逻辑的代码在不同的 Pod/服务器实例中执行。

优点

• 资源：应用程序和服务分开部署，因此资源不共享。资源可以独立地针对应用程序和服务进行优化。

• 可维护性：当涉及到错误修复时，服务可以独立发布。不需要版本升级。

• 技术：可以使用适合其目的的任何技术选择来开发服务。

缺点

• 易用性：与库相比，服务的易用性相对较低。

• 延迟：由于应用程序和服务是分布式的，并且调用需要网络调用，因此延迟明显更高。

• 环境上下文：服务无法访问主应用程序的环境上下文（内存、CPU 等），因为两者都在不同的实例中独立运行。

• 可用性：由于网络分区，总体可用性将低于库。

Sidecar 模式是由两个容器组成的单节点模式。side car 和主应用程序逻辑的代码作为不同进程/容器的一部分执行，但一起部署在同一个 pod/server 实例中。

优点缺点

• 可维护性：当涉及到错误修复时，Sidecar 可以独立发布。

• 技术：Sidecar 可以使用适合其目的的任何技术进行开发。

• 延迟：与服务相比，延迟较低，但高于库。这种方法的反模式是使所有可重用的组件边车，因为这将导致显着的影响性能影响。

• 资源：应用程序和 Sidecar 部署为集合，因此资源共享，但可以为 Sidecar 单独设置资源限制，以防止 Sidecar 过度使用。这种方法的反模式是让所有可重用的组件使用边车，因为它会导致资源配置管理的巨大开销。

• 易用性：与库相比，Sidecar 的易用性相对较低，如果 CI/CD 管道支持开箱即用，则与服务相比使用起来更简单。

• 环境上下文：sidecar 可以访问环境上下文（内存、CPU 等），因为它是同一个 pod/server 实例的一部分。这允许边车进行应用程序性能监控等。

• 可用性：与服务相比，可用性会更高，因为没有真正的网络分区。一般来说，可用性主要取决于主应用程序和边车之间的通信协议。例如。如果协议被触发并忘记，那么边车中的失败不会对主应用程序产生级联副作用。

上面提到的方法 — Library、Service 和 Sidecar 都可以一起用于应用程序以达到预期的结果。应用程序可以使用库进行数据库调用，使用边车进行分布式日志记录，以及提供身份验证功能的服务。开发团队需要权衡利弊，然后选择正确的解决方案。

谢谢大家关注，转发，点赞和点在看。