问题引入
应用程序和服务通常需要一组相关的外围功能,例如监控、日志记录、配置和网络服务等。
对于单应用程序程序而言,这些外围功能往往紧密集成在主应用程序中,好处是可以在运行主应用程序的同一个进程中共享内存资源,不过,这也意味着无法对它们进行有效的隔离,当其中一个组件发生故障,可能会影响到其他组件甚至整个应用程序的正常运行,此外,这样做的另一个局限是需要使用与主应用程序相同的语言来开发这些外围组件。因此,外围组件和主应用程序之间保持着紧密的耦合关系。
如果单应用程序被分解为不同的微服务,则可以使用不同的语言和技术构建每个微服务,这样做提高了系统的灵活性,但同时也意味着外围组件与微服务之间的交互变得复杂,需要基于构建微服务的特定语言实现与微服务的资源共享以及对底层平台的访问,此外,将这些外围功能部署为单独的服务可能会增大应用程序的延迟。因此,管理这些特定于语言的接口代码和依赖关系会显著增加系统的复杂性。
解决方案
为了解决上述问题,在微服务中引入了 sidecar 模式(中文译作「边车」模式),该模式会将一组内聚性的任务与主应用程序(某个微服务)部署在一起(同一台主机),不过,要将它们隔离到单独的进程或容器内,以便为跨语言的微服务提供同构接口。这样一来,我们就可以无侵入地为应用添加多种功能,而不必为满足第三方组件需求向主应用程序添加额外的配置代码。就像边车加装到摩托车上一样,在微服务架构中,sidecar 附加到主应用(或者叫父应用)上,可以扩展并增强系统的功能特性,同时 sidecar 与主应用是松耦合的(sidecar 聚合的功能包括平台抽象、远程服务代理、日志、配置、流量监控等):
或者更形象的图示如下,载人的摩托车是主应用,载狗的边车是 sidecar:
sidecar 不一定是主应用程序的一部分,只是与主应用程序相连接,是连同主应用程序一起部署的支持性进程或服务,它们具有相同的生命周期,但分属于不同的进程,一个 sidecar 实例必然对应着一个微服务主应用实例。
综上,sidecar 模式的优点如下:
实际应用
我们上篇分享介绍的 Micro Proxy 显然是 sidecar 模式的应用,下面我们通过一个具体实例来演示基于 Micro Proxy 实现将 PHP 语言编写的微服务纳入 Go Micro 微服务体系中来,对应的简单系统架构如下:
Micro Proxy 代理了 Go Micro 框架的功能特性,所以基于 PHP 实现的服务可以通过 Micro Proxy 发布到注册中心,同时可以基于 Micro Proxy 对外提供的接口代理其它微服务对 PHP 远程服务的引用。
具体实现代码我们放到下篇分享去提供。