Open howie6879 opened 3 years ago
https://www.howie6879.cn/k8s/docs/03_appendix/00.%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E5%9F%BA%E4%BA%8E%E5%AE%B9%E5%99%A8%E7%9A%84%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/
设计模式——基于容器的分布式系统 # 20世纪80年代末至90年代初，面向对象编程思想给软件开发带来了一轮技术革新，就像润物细无声的春雨那般，向全世界的程序员们快速普及了模块化构建应用程序的方法，一直流行至今。 当下，我们可以看到类似的革新出现在了分布式系统开发，具体特点如下： 基于容器的微服务架构体系日益流行 容器天然隔离的属性非常适合作为分布式系统中的基本对象 基于面向对象，四人帮基于经验提出和总结了对于一些常见软件设计问题的标准解决方案，其描述了一系列基于接口的模式，可以在各种环境中重用，这被称之为软件设计模式。历史一定程度上来说是重复的，随着这种架构模式的成熟，基于容器的分布式系统的设计模式也就自然而然地浮现了。 本篇主要阐述的是Brendan Burns在基于容器的分布式系统中发现的三种设计模式： single-container patterns for container management：容器管理之单容器模式 single-node patterns of closely cooperating containers：容器协调之单节点（多容器）模式 multi-node patterns for distributed algorithms：分布式算法之多节点模式 基于容器分布式系统的设计模式会给分布式计算编码带来以下优势： 最佳实践，给没有经验的程序员带来相对正确的使用方式 简化开发 提升系统可靠性 模式的价值 # 模式的目的是提供一般建议或结构来指导设计，这样做的好处有以下三点： 站在巨人的肩膀上，对于经验不怎么丰富的开发者，可以通过模式来指引走在正确的道路上，从而少踩坑，提升项目质量 提供通用的名称和定义，有共同的领域语言进行交流是一件很重要的事情 方便识别并构建共享的通用组件 单容器模式 # 就像对象会定义边界一样，容器为定义接口提供了天然的边界；它不仅可以暴露特定应用的功能，还可以通过钩子函数来管理系统。传统的容器管理接口是极其有限的，如： run pause stop 这些接口只能说满足基础的使用需求，但是就目前的现状来看，更丰富的接口可以为系统开发者与操作者提供更多的功能。鉴于HTTP和JSON的普及程度，可以考虑通过容器在特定的节点托管一个Web服务来实现。这样做的目的是什么，可以从下面两个角度来看待： upward：容器可以暴露丰富的应用信息，比如： 各类监控指标（QPS、应用健康等） 一些开发人员感兴趣的信息如（线程、堆栈、锁、网络消息统计等） 组件配置、日志等 downward：任何开发者在编写软件组件的时候，都可以使用容器原生支持的生命周期接口来进行管控。比如一个集群管理系统通常会给任务分配对应的优先级，高优先级的任务即使在集群被超额订阅的情况下也能保证运行，这种保证是通过逐出已经运行的低优先级任务来实现的，然后这些低优先级任务能否运行取决于后面是否还有资源分配过来；但是这样有个问题就是开发者需要承担一些没必要的复返，比如处理一些优先级比较低的任务被抛弃的情况。相反，如果在应用程序和管理系统之间定义了正式的生命周期，那么应用程序组件将变得更易于管理，比如k8s使用Docker 的graceful deletion功能，这就允许应用程序通过完成当前任务，把状态写入磁盘等等操作之后再终止，将这个功能扩展一下就可以使使有状态的分布式系统的状态管理更加容易。 单节点（多容器）模式 # 上面提到了单容器的接口，我们稍稍延伸一下，对于一个多容器组成的应用，会有怎样的设计模式呢？当然，此时我们仍旧有些限制条件需要讲清楚：
https://www.howie6879.cn/k8s/docs/03_appendix/00.%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E5%9F%BA%E4%BA%8E%E5%AE%B9%E5%99%A8%E7%9A%84%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/
设计模式——基于容器的分布式系统 # 20世纪80年代末至90年代初，面向对象编程思想给软件开发带来了一轮技术革新，就像润物细无声的春雨那般，向全世界的程序员们快速普及了模块化构建应用程序的方法，一直流行至今。 当下，我们可以看到类似的革新出现在了分布式系统开发，具体特点如下： 基于容器的微服务架构体系日益流行 容器天然隔离的属性非常适合作为分布式系统中的基本对象 基于面向对象，四人帮基于经验提出和总结了对于一些常见软件设计问题的标准解决方案，其描述了一系列基于接口的模式，可以在各种环境中重用，这被称之为软件设计模式。历史一定程度上来说是重复的，随着这种架构模式的成熟，基于容器的分布式系统的设计模式也就自然而然地浮现了。 本篇主要阐述的是Brendan Burns在基于容器的分布式系统中发现的三种设计模式： single-container patterns for container management：容器管理之单容器模式 single-node patterns of closely cooperating containers：容器协调之单节点（多容器）模式 multi-node patterns for distributed algorithms：分布式算法之多节点模式 基于容器分布式系统的设计模式会给分布式计算编码带来以下优势： 最佳实践，给没有经验的程序员带来相对正确的使用方式 简化开发 提升系统可靠性 模式的价值 # 模式的目的是提供一般建议或结构来指导设计，这样做的好处有以下三点： 站在巨人的肩膀上，对于经验不怎么丰富的开发者，可以通过模式来指引走在正确的道路上，从而少踩坑，提升项目质量 提供通用的名称和定义，有共同的领域语言进行交流是一件很重要的事情 方便识别并构建共享的通用组件 单容器模式 # 就像对象会定义边界一样，容器为定义接口提供了天然的边界；它不仅可以暴露特定应用的功能，还可以通过钩子函数来管理系统。传统的容器管理接口是极其有限的，如： run pause stop 这些接口只能说满足基础的使用需求，但是就目前的现状来看，更丰富的接口可以为系统开发者与操作者提供更多的功能。鉴于HTTP和JSON的普及程度，可以考虑通过容器在特定的节点托管一个Web服务来实现。这样做的目的是什么，可以从下面两个角度来看待： upward：容器可以暴露丰富的应用信息，比如： 各类监控指标（QPS、应用健康等） 一些开发人员感兴趣的信息如（线程、堆栈、锁、网络消息统计等） 组件配置、日志等 downward：任何开发者在编写软件组件的时候，都可以使用容器原生支持的生命周期接口来进行管控。比如一个集群管理系统通常会给任务分配对应的优先级，高优先级的任务即使在集群被超额订阅的情况下也能保证运行，这种保证是通过逐出已经运行的低优先级任务来实现的，然后这些低优先级任务能否运行取决于后面是否还有资源分配过来；但是这样有个问题就是开发者需要承担一些没必要的复返，比如处理一些优先级比较低的任务被抛弃的情况。相反，如果在应用程序和管理系统之间定义了正式的生命周期，那么应用程序组件将变得更易于管理，比如k8s使用Docker 的graceful deletion功能，这就允许应用程序通过完成当前任务，把状态写入磁盘等等操作之后再终止，将这个功能扩展一下就可以使使有状态的分布式系统的状态管理更加容易。 单节点（多容器）模式 # 上面提到了单容器的接口，我们稍稍延伸一下，对于一个多容器组成的应用，会有怎样的设计模式呢？当然，此时我们仍旧有些限制条件需要讲清楚：