库 vs 服务 vs 侧车Sidecar的比较

22-03-04 banq

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

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

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

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

 

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

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

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

 

Sidecar:边车、侧车

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

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

 

总结
上面提到的方法--库、服务和Sidecar都可以一起用于一个应用程序,以达到预期的效果。一个应用程序可以使用库来进行数据库调用,使用sidecar来进行分布式日志记录,使用服务来提供认证功能。开发团队需要权衡利弊,然后选择正确的解决方案。
 

猜你喜欢