下载安卓APP箭头
箭头给我发消息

客服QQ:3315713922

分布式系统中的容器设计模式

作者:匿名     来源: 互联网点击数:1009发布时间: 2021-10-17 23:09:24

标签: 容器Docker云原生

  Docker的出现,极大地改变了程序包装和部署的方式,也是完全改变分布式系统设计的最基本的组件。

  接下来的文章里,我想给大家介绍一下分布式系统中的容器设计模式相关的知识点,大家跟随小编一起来看看。

  首先说第一个pattern,SingleContainerPatten

  首先,从最小的组件容器开始,简单地说,容器就是将应用程序及其所需的依赖库打成一个包。Docker的出现,极大地改变了程序包装和部署的方式,也是完全改变分布式系统设计的最基本的组件。

  就像OOPJava编程语言中的Object(Class)一样,Container是容器分布式系统最基本的对象。在java语言中,最基本的对象载体是Class,class是Object,而在容器系统中,最基本的对象载体是ContainerImage,当它运行时,它就是Container。Java对象有自己的初始化机制,Container也有自己的InitContainer机制。Java对象有销毁机制,Container也有preStop函数,可以优雅地停止。

  在现实设计中,需要将一个应用程序拆卸成多个容器来实现,还需要重点考虑:解耦和重用。不断问自己几个问题:我的容器够解耦了吗?还能拿出一部分作为独立容器吗?这些容器可以轻松重用到其他地方吗?

  另外,由多个容器组成的pattern

  在学习K8S的过程中,一定会有好奇心:为什么Pod(包括一个或多个Container)是最小的部署单元,而不是直接的容器?这里涉及到K8S中一个非常精致的设计。Pod是一组共享生命周期,部署在同一节点的容器组合。他们可以通过共享的volume/network和IPC进行通信。不是单个容器,而是多个容器完成特定功能的原因是这些容器要完成的职责不同,根据单个职责(singleresponsibility)的原则,应该属于不同的组件;其次,由于职责不同,维护的team不同,迭代周期也不同;最后,有些容器可以在其他环境中重复使用。因此,从解耦和重用的设计原则出发,Kubernetes通过增加一个虚拟层,即POD,给系统设计带来了极大的灵活性,同时也产生了多种设计模式。

  InitContainerPattern

  正如Java语言中的Object具有初始功能一样,Pod中的InitContainer也起到了初始功能。在appcontainer启动之前,需要满足一些前置条件。  

 

  我们来看一个简单的例子,比如上图。其中myapp-container是appcontainer,用于执行业务逻辑。它的启动取决于后台的mydb和myservice。所以有两个initcontainers,分别执行nslookup检查依赖服务是否启动。如果没有启动,等2秒后再检查。如果已经启动,就顺利启动自己的容器,然后再启动。

  使用互联网的注意事项如下:1。互联网的执行顺序是在pod启动过程中首先执行,也就是顺序执行,即一个互联网执行后,再执行下一个互联网。他没有readinessprobecheck,逻辑简单,执行速度快。2.互联网也是互联网,也占用CPU/内存系统资源,所以在计算资源消耗时需要添加,否则调度时可能会有问题。

  Sidecarpattern

  以下是Sidecarpattern介绍。

  我们所说的sidecar,就是托车。在K8S中,sidecarcontainer是与appcontainer同时启动的容器,有自己的责任,可以在其他地方重复使用。让我们看看典型的例子。  

  

 

  AppContainer是webserver,sidecarcontainer定期从githubsync代码下来,通过Podvolume共享文件。这样做的好处是将github定期sync代码的逻辑剥离出来,成为可重用的模块,可以用于其他场合。appcontainer只需要做网络服务,不需要考虑sync等逻辑。

  何时考虑使用sidecar?如果两个container需要同时部署,但各有各的职责,可以分别进行迭代和演变,并且有可能重用。

  那么什么时候不适合sidecar呢?当这两个container有不同的扩展需求时,即两者需要独立扩展时,不需要sidecar模式;此外,两者的通信可能会带来一些网络消耗和一定的延迟。如果业务不能接受这种延迟,不要使用sidecar。

  AmbassadaorDesignPattern

  这是一个特殊的sidecar,实际上是appcontainer的proxy,它接收流量,然后进行处理,然后将流量转发给appcontainer,使其完成真正的商业逻辑。

  举例来说,我想在webserver上添加一个认证逻辑或SSL,但我不想更改原来的webserver或更改,我可以在它所在的pod中部署另一个proxy,这样proxy就可以处理这些认证逻辑,而原来的appcontainer不需要更改。  

 

  另外,ambassadorpattern也可以用于shardaservice或A/B测试。此外,新兴的技术热点ServiceMesh及其实现istio,都是利用sidecar的方式做服务代理,将流量控制的逻辑降低到基础架构层,通过ambassador的方式很容易实现。它们的出现将极大地改变微型服务架构,使其更加注重业务逻辑的高效实现,而将流量控制(包括服务发现、服务限制、小流量等服务路由功能统一地交给servicemesh来解决。

  AdapterPattern

  另一个特殊的sidecar,如果您希望外部输出的内容符合下游要求,而不需要修改appcontainer,您可以添加adapter的sidecar,从而进行类似日志转换。比如:  

 

  Appcontainer根据自己的要求生成日志并保存在文件系统中,另一个adaptercontainer通过共享存储读取日志,然后进行日志转换等工作,从而将内容输出到下游的metrics系统。

  小编的介绍就到这里了,总的来说,DesignPattern的核心是解耦和重用;在分布式容器和容器系统中,有大量可重用的组件和pattern,其中Singlecontainer和multiplecontainer是最基本的组件。

    >>>>>>点击进入计算专题

赞(12)
踩(0)
分享到:
华为认证网络工程师 HCIE直播课视频教程