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

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

　　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，从而进行类似日志转换。比如：　　