库 vs 服务 vs 侧车Sidecar的比较

所有软件应用程序都由可重用的元素组成。这些可重用元素的目标和功能从基础设施级别到安全级别到业务能力各不相同。
本文的目的是比较用于构建和部署这些可重用元素的不同方法。
 
1.库包
这是重用代码的最广泛使用的方法。可重用代码作为库开发和发布。在这种方法中，客户端应用程序将库定义为直接依赖项，使用提供的 API 并将其代码与主应用程序逻辑一起发送。库和主应用程序逻辑的代码作为同一进程/容器的一部分执行。
优点

• 延迟：库中的代码与主应用程序在同一进程中执行，因此没有网络延迟。
• 可用性：整体可用性很高，因为没有网络分区（CAP定理）。
• 易于使用：使用非常简单。
• 环境上下文：库可以访问环境上下文（内存、CPU 等），因为它们是同一容器的一部分。

• 资源：内存、CPU 等资源与主应用程序共享。这意味着库的性能会对主应用程序产生副作用。
• 技术：库中使用的库与主要应用程序的库相同，因此，如果组织有不同的应用程序集，则每种语言都需要多个实现。
• 可维护性：库中的任何错误修复都需要对所有客户端应用程序进行代码更改和测试。

• 资源：应用程序和服务分开部署，因此资源不共享。资源可以独立地针对应用程序和服务进行优化。
• 可维护性：当涉及到错误修复时，服务可以独立发布。不需要版本升级。
• 技术：可以使用适合其目的的任何技术选择来开发服务。

• 易用性：与库相比，服务的易用性相对较低。
• 延迟：由于应用程序和服务是分布式的，并且调用需要网络调用，因此延迟明显更高。
• 环境上下文：服务无法访问主应用程序的环境上下文（内存、CPU 等），因为两者都在不同的实例中独立运行。
• 可用性：由于网络分区，总体可用性将低于库。

• 可维护性：当涉及到错误修复时，Sidecar可以独立发布。
• 技术。Sidecar可以使用任何适合其目的的技术来开发。
• 延迟性。与服务相比，其延迟性较低，但比库高。这种方法的反模式是使所有可重复使用的组件成为侧车，因为这将导致对性能的重大影响。
• 资源。应用程序和Sidecar被部署到一起，所以资源是共享的，但可以为侧车单独设置资源限制，以防止侧车的过度使用。这种方法的反模式是使所有可重用的组件成为侧车，因为这将导致资源配置管理的巨大开销。
• 易用性：与库相比，边车的易用性相对较低，如果CI/CD管道支持开箱即用，那么与服务相比，使用起来会更简单。
• 环境背景。环境上下文（内存、CPU等）是可以被sidecar访问的，因为它是同一个pod/服务器实例的一部分。这使得侧车可以进行应用性能监控等。
• 可用性：与服务相比，可用性会更高，因为没有真正的网络分区。一般来说，可用性主要取决于主应用程序和侧车之间的通信协议。例如，如果协议是火灾和遗忘，那么侧车的故障将不会对主应用程序产生连带的副作用。