Posts

K8s 核心数据结构（2） 参考书籍：《Kubernetes源码剖析-郑旭东著》 Kubernetes 内置资源概览 资源组 资源种类 说明 apiextensions.k8s.io CustomResourceDefinition 自定义资源类型 ， 由 APIExtensions Server 负责管理该资源类型 apiregistration.k8s.io APIService 聚合资源类型，由 AggregatorServer 负责管理该资源类 admissionregistration.k8s.io MutatingWebhookConfiguration 变更准入控制器资源类型( Webhook) ValidatingWebhookConfiguration 验证准入控制器资源类型 ( Webhook) apps ControllerRevision 记录资源对象所有的历史版本的资源类型 DaemonSet 在 Pod 资源对象的基础上提供守护进程的资源类型 Deployment 在 Pod资源对象的基础上提供支持无状态服务的资源类型 ReplicaSet 在 Pod 资源对象的基础上提供一组 Pod 副本的资源类型 StatefulSet 在 Pod资源对象的基础上提供支持有状态服务的资源类型 auditregistration.k8s.io AuditSink 审计资源类型 authentication.k8s.io TokenReview 认证资源类型 authorization.k8s.io LocalSubjectAccessReview 授权检查用户是否可以在指定的命名空间中执行操作 SelfSubjectAccessReview 授权检查用户是否可以执行操作(若不指定 spec.namespace，则在所有的命名空间中执行操作） SelfSubjectRulesReview 授权枚举用户可以在指定的命名空间中执行一组操作 SubjectAccessReview 授 权检查用户是否可以执行操作 autoscaling HorizontalPodAutoscaler 在 Pod 资源对象的基础上提供水平自动伸缩资源类型 batch Job 提供一次性任务的资源类型 CronJob 提供定时任务的资源类型 certificates.k8s.io CertificateSigningRequest 提供证书管理的资源类型 coordination.k8s.io Leases 提供领导者选举机制的资源类型 core ComponentStatus 该资源类型已被奔用，其用于提供获取 Kuberetes 组件运行状况的资源类型 ConfigMap 提供容器内应用程序配置管理的资源类型 Endpoints 提供将外部服务器映射为内部服务的资源类型 Event 提供 Kubernetes 集群事件管理的资源类型 LimitRange 为命名空间中的每种资源对象设置资源(硬件资源)使 用限制 Namespace 提供资源对象所在的命名空间的资源类型 Node 提供 Kubernetes 集群中管理工作节点的资源类型。每个节点都有一个唯一标识符 PersistentVolume 提供 PV 存储的资源类型 PersistentVolumeClaim 提供 PVC 存储的资源类型 Pod 提供容器集合管理的资源类型 PodTemplate 提供用于描述预定义 Pod 资源对象副本数模板的资源类型 ReplicationController 在 Pod资源对象的基础上提供副本数保持不变的资源类型 ResourceQuota 提供每个命名空间配额限制的资源类型 Secret 提供存储密码 、Token 、密钥等敏感数据的资源类型 Service 提供负载均衡器为 Pod 资源对象的代理服务的资源类型 ServiceAccount 提供 ServiceAccount 认证的资源类型 events.k8s.io Event 提供Kuberetes集群事件管理的资源类型 networking.k8s.io RuntimeClass 提供容器运行时功能的资源类型 Ingress 提供 从Kubernetes 集群外部访问集群内部服务管理的资源类型 node.k8s.io RuntimeClass 提供容器运行时功能的资源类型 policy Evictions 在 Pod 资源对象的基础上提供驱逐策略的资源类型 PodDisruptionBudget 提供限制同时中断 Pod 的数量 ，以保证集群的高可用性 PodSecurityPolicy 提供控制 Pod 资源安全相关策略的资源类型 rbac.authorization.k8s.io ClusterRole 提供 RBAC 集群角色的资源类型 ClusterRoleBinding 提供 RBAC 集群角色鄉定的资源类型 Role 提供 RBAC 角色的资源类型 RoleBinding 提供 RBAC 角色绑定的资源类型 scheduling.k8s.io PriorityClass 提供 Pod 资源对象优先级管理的资源类型 settings.k8s.10 PodPreset 在创建 Pod 资源对象时，可以将特定信息注入 Pod 资源对象中 storage.k8s.io StorageClass 提供动态设置PV存储参数的资源类 VolumeAttachment 供触发 CSI ControllerPublish 和 ControllerUnpublish 操作的资源类型 ...

Kubernetes 核心数据结构（1） 参考书籍：《Kubernetes源码剖析-郑旭东著》 K8s 是一个完全以资源为中心的系统 Group、Version、Resource 核心数据结构 ​ Kuberetes 系统虽然有相当复杂和众多的 功能，但它本质 上是一个资源控制系统——注册、管理、调度资源 并维护资源的状态。 ​ Kuberetes 将资源再次分组和版本化，形成 Group（资源组）、Version（资源版本）、Resource（资源） Group: 被称为资源组，在Kubernetes API Server 中也可称其为 APIGroup。 Version: 被称为资源版本，在Kubernetes API Server 中也可称其为 APIVersions。 Resource: 被称为资源，在Kubernetes API Server 中也可称其为 APIResource。 Kind: 资源种类，描述 Resource 的种类，与 Resource 为同一级别。 ​ ​ Kubernetes 系统支持多个Group，每个Group 支持多个Version，每个Version 支 持多个Resource，其中部分资源同时会拥有自己的子资源(即SubResource )。例如， Deployment资源拥有Status 子资源。 ​ 资源组、资源版本、资源、子资源的完整表现形式<group>/<version>/<resource>/ <subresource>。以常用的 Deployment 资源为例，其完整表现形式为apps/v1/deployments/status ​ 另外资源对象(Resource Object )在本书中也是 一个常用概念，由“ 资源组+ 资源版本+资源种类” 组成，并在实例化后表达一个资源对象，例如 Deployment 资源实例化后拥有资源组、资源版本及资源种类，其表现形式为<group>/<version>, Kind=<kind>，例如apps/v1, Kind=Deployment. ​ 每一个资源都拥有一定数量的资源操作方法(即 Verbs )，资源操作方法用于 Etcd 集群存储中对资源对象的增、删、改、查操作。目前 Kubemetes 系统支持8 种资源操作方法，分别是 create、delete、delete、collection、get、list、patch、update、watch 操作方法。 ​ 每一个资源都至少有两个版本，分别是外部版本(External Version)和内部版本 ( Internal Version )。外部版本用于对外暴露给用户请求的接又所使用的资源对象。内部版本不对外暴露，仅在Kubernetes API Server 内部使用。 ​ Kubernetes 资源也可分为两种， 分别是Kubernetes Resource (Kubermetes 内罝资源 ) 和 Custom Resource( 自 定 义 资 源 )。 开 发 者 通 过 C R D ( 即 Custom Resource Definitions )可实现自定义资源，它允许用户将自己定义的资源添加到 Kubernetes 系统中，并像使用 Kubernetes 内置资源 一样使用它们。 ...

K8s 架构 参考文章：Kubernetes源码剖析 架构概览 ​ Kubernetes 系统架构遵循客户端 / 服务端 （ C/S ） 架构 ， 系统架构分为 Master 和 Node 两部分 ， Master 作为服务端 ， Node 作为客户端 。 Kubernetes 系统具有多个 Master 服务端 ， 可以实现高可用 。 在默认的情况下 ， 一个 Master 服务端即可完成所有工作 。 服务端也被称为主控节点 ， 它在集群中主要负责如下任务 。 集群的 “ 大脑 ” ， 负责管理所有节点 (Node）。 负责调度 Pod 在哪些节点上运行 。 负责控制集群运行过程中的所有状态 。 Node 客户端也被称为工作节点 ， 它在集群中主要负责如下任务 。 负责管理所有容器 （ container ) 。 负责监控 / 上报所有 Pod 的运行状态 。 组件概览 ...

GO 三方库源码阅读姿势 参考内容：极客专栏：手把手带你写一个web框架 阅读顺序 库函数 > 结构定义 > 结构函数。 ​ 简单来说，就是当你在阅读一个代码库的时候，不应该从上到下阅读整个代码文档，而应 该先阅读整个代码库提供的对外库函数(function)，再读这个库提供的结构 (struct/class)，最后再阅读每个结构函数(method) 查看库函数 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 go doc net/http(三方库名称) | grep "^func" func CanonicalHeaderKey(s string) string func DetectContentType(data []byte) string func Error(w ResponseWriter, error string, code int) func Get(url string) (resp *Response, err error) func Handle(pattern string, handler Handler) func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) func Head(url string) (resp *Response, err error) func ListenAndServe(addr string, handler Handler) error func ListenAndServeTLS(addr, certFile, keyFile string, handler Handler) error func MaxBytesReader(w ResponseWriter, r io.ReadCloser, n int64) io.ReadCloser func NewRequest(method, url string, body io.Reader) (*Request, error) func NewRequestWithContext(ctx context.Context, method, url string, body io.Reader) (*Request, error) func NotFound(w ResponseWriter, r *Request) func ParseHTTPVersion(vers string) (major, minor int, ok bool) func ParseTime(text string) (t time.Time, err error) func Post(url, contentType string, body io.Reader) (resp *Response, err error) func PostForm(url string, data url.Values) (resp *Response, err error) func ProxyFromEnvironment(req *Request) (*url.URL, error) func ProxyURL(fixedURL *url.URL) func(*Request) (*url.URL, error) func ReadRequest(b *bufio.Reader) (*Request, error) func ReadResponse(r *bufio.Reader, req *Request) (*Response, error) func Redirect(w ResponseWriter, r *Request, url string, code int) func Serve(l net.Listener, handler Handler) error func ServeContent(w ResponseWriter, req *Request, name string, modtime time.Time, ...) func ServeFile(w ResponseWriter, r *Request, name string) func ServeTLS(l net.Listener, handler Handler, certFile, keyFile string) error func SetCookie(w ResponseWriter, cookie *Cookie) func StatusText(code int) string ​ 在这个库提供的方法中，我们去掉一些 New 和 Set 开头的函数，因为你从命名上可以看出，这些函数是对某个对象或者属性的设置。 剩下的函数大致可以分成三类: 为服务端提供创建 HTTP 服务的函数，名字中一般包含 Serve 字样，比如 Serve、 ServeFile、ListenAndServe 等。 为客户端提供调用 HTTP 服务的类库，以 HTTP 的 method 同名，比如 Get、Post、 Head 等。 提供中转代理的一些函数，比如 ProxyURL、ProxyFromEnvironment 等。 查看结构定义(模块) ​ 我们过一遍这个库提供的所有 struct，看看核心模块有哪些，同样使用 go doc: 1 go doc net/http | grep "^type"| grep struct ​ 可以看到整个库最核心的几个结构: 1 2 3 4 5 6 7 8 9 10 type Client struct{ ... } type Cookie struct{ ... } type MaxBytesError struct{ ... } type ProtocolError struct{ ... } type PushOptions struct{ ... } type Request struct{ ... } type Response struct{ ... } type ServeMux struct{ ... } type Server struct{ ... } type Transport struct{ ... } 看结构的名字或者 go doc 查看结构说明文档，能逐渐了解它们的功能: Client 负责构建 HTTP 客户端; Server 负责构建 HTTP 服务端; ServerMux 负责 HTTP 服务端路由; Transport、Request、Response、Cookie 负责客户端和服务端传输对应的不同模块。 ​ 现在通过库方法(function)和结构体(struct)，我们对整个库的结构和功能有大致印象 了。整个库承担了两部分功能，一部分是构建 HTTP 客户端，一部分是构建 HTTP 服务 端。 ​ 构建的 HTTP 服务端除了提供真实服务之外，也能提供代理中转服务，它们分别由 Client 和 Server 两个数据结构负责。除了这两个最重要的数据结构之外，HTTP 协议的每个部 分，比如请求、返回、传输设置等都有具体的数据结构负责。 ...

K8s创建Pod的历程 参考原文：https://icloudnative.io/posts/what-happens-when-k8s/#span-idinline-toc1span-kubectl 1. kubectl 验证和生成器 ​ 当敲下回车键以后，kubectl 首先会执行一些客户端验证操作，以确保不合法的请求（例如，创建不支持的资源或使用格式错误的镜像名称）将会快速失败，也不会发送给 kube-apiserver。通过减少不必要的负载来提高系统性能。 ​ 验证通过之后， kubectl 开始将发送给 kube-apiserver 的 HTTP 请求进行封装。kube-apiserver 与 etcd 进行通信，所有尝试访问或更改 Kubernetes 系统状态的请求都会通过 kube-apiserver 进行，kubectl 也不例外。kubectl 使用生成器（ generators）来构造 HTTP 请求。生成器是一个用来处理序列化的抽象概念。 ​ 通过 kubectl run 不仅可以运行 deployment，还可以通过指定参数 --generator 来部署其他多种资源类型。如果没有指定 --generator 参数的值，kubectl 将会自动判断资源的类型。 ​ 例如，带有参数 --restart-policy=Always 的资源将被部署为 Deployment，而带有参数 --restart-policy=Never 的资源将被部署为 Pod。同时 kubectl 也会检查是否需要触发其他操作，例如记录命令（用来进行回滚或审计）。 ​ 在 kubectl 判断出要创建一个 Deployment 后，它将使用 DeploymentV1Beta1 生成器从我们提供的参数中生成一个 运行时对象。 API 版本协商与 API 组 ​ 为了更容易地消除字段或者重新组织资源结构，Kubernetes 支持多个 API 版本，每个版本都在不同的 API 路径下，例如 /api/v1 或者 /apis/extensions/v1beta1。不同的 API 版本表明不同的稳定性和支持级别，更详细的描述可以参考 Kubernetes API 概述。 ​ API 组旨在对类似资源进行分类，以便使得 Kubernetes API 更容易扩展。API 的组名在 REST 路径或者序列化对象的 apiVersion 字段中指定。例如，Deployment 的 API 组名是 apps，最新的 API 版本是 v1beta2，这就是为什么你要在 Deployment manifests 顶部输入 apiVersion: apps/v1beta2。 ​ kubectl 在生成运行时对象后，开始为它 找到适当的 API 组和 API 版本，然后 组装成一个版本化客户端，该客户端知道资源的各种 REST 语义。该阶段被称为版本协商，kubectl 会扫描 remote API 上的 /apis 路径来检索所有可能的 API 组。由于 kube-apiserver 在 /apis 路径上公开了 OpenAPI 格式的规范文档， 因此客户端很容易找到合适的 API。 ​ 为了提高性能，kubectl 将 OpenAPI 规范缓存到了 ~/.kube/cache 目录。如果你想了解 API 发现的过程，请尝试删除该目录并在运行 kubectl 命令时将 -v 参数的值设为最大值，然后你将会看到所有试图找到这些 API 版本的HTTP 请求。参考 kubectl 备忘单。 ​ 最后一步才是真正地发送 HTTP 请求。一旦请求发送之后获得成功的响应，kubectl 将会根据所需的输出格式打印 success message。 客户端身份认证 在发送 HTTP 请求之前还要进行客户端认证，这是之前没有提到的，现在可以来看一下。 为了能够成功发送请求，kubectl 需要先进行身份认证。用户凭证保存在 kubeconfig 文件中，kubectl 通过以下顺序来找到 kubeconfig 文件： 如果提供了 --kubeconfig 参数， kubectl 就使用 –kubeconfig 参数提供的 kubeconfig 文件。 如果没有提供 –kubeconfig 参数，但设置了环境变量 $KUBECONFIG，则使用该环境变量提供的 kubeconfig 文件。 如果 –kubeconfig 参数和环境变量 $KUBECONFIG 都没有提供，kubectl 就使用默认的 kubeconfig 文件 $HOME/.kube/config。 解析完 kubeconfig 文件后，kubectl 会确定当前要使用的上下文、当前指向的群集以及与当前用户关联的任何认证信息。如果用户提供了额外的参数（例如 –username），则优先使用这些参数覆盖 kubeconfig 中指定的值。一旦拿到这些信息之后， kubectl 就会把这些信息填充到将要发送的 HTTP 请求头中： x509 证书使用 tls.TLSConfig 发送（包括 CA 证书）。 bearer tokens 在 HTTP 请求头 Authorization 中 发送。 用户名和密码通过 HTTP 基本认证 发送。 OpenID 认证过程是由用户事先手动处理的，产生一个像 bearer token 一样被发送的 token。 小结补充 ​ 如果要对k8s的部署文件进行进一步正确性校验，可以参看这个Kubeval ...

Tekton 入门 术语解释 Cloud Native ​ 云原生是一种软件开发方法，其中应用程序被分解为微服务，这些微服务被打包到容器中，容器在云中动态编排以优化资源利用 Continuous Delivery ​ 持续交付是一种软件开发实践，团队可以安全、快速、可持续地向用户发布软件变更。 Tekton ​ Tekton 是一个用于创建持续交付系统的开源 kubernetes 原生的框架。你可以使用 tekton 跨多个云提供商或混合环境构建，测试和部署。Tekton 通过抽象出复杂的kubenetes概念和实现细节来简化应用程序管理。它提供了用于声明持续交付管道的 Kubernetes 自定义资源。 基本构建块 其中Task、TaskRun、Pipeline、PipelineRun、PipelineResource、Condition作为其核心CRD，这里主要介绍它们。 Task： 定义构建任务，它由一系列有序steps构成。每个step可以定义输入和输出，且可以将上一个step的输出作为下一个step的输入。每个step都会由一个container来执行。 是 Tekton 中不可分割的最小单位，正如同 Pod 在 Kubernetes 中的概念一样 TaskRun： Task用于定义具体要做的事情，并不会真正的运行，而TaskRun就是真正的执行者，并且会提供执行所需需要的参数，一个TaskRun就是一个Pod。 Pipeline： 顾名思义就是流水线，它由一系列Tasks组成。就像Task中的step一样，上一个Task的输出可以作为下一个Task的输入。 PipelineRun： Pipeline的实际执行，创建后会创建Pod来执行Task，一个PipelineRun中有多个Task。 PipelineResource： 主要用于定义Pipeline的资源，常见的如Git地址、Docker镜像等。 Condition： 它主要是在Pipeline中用于判断的，Task的执行与否通过Condition的判断结果来决定。 Tips： PipelineResource和Condition都会被废弃。但是在低版本中还是会继续使用，所以这里会简单介绍一下。 ...

分布式12问 原文转载自：分布式夺命12连问 (qq.com) 分布式理论 1. 说说CAP原则？ CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这3个基本需求，最多只能同时满足其中的2个。 ...

CMDB介绍 CMDB含义 CMDB代表配置管理数据库，通常被称为任何ITSM系统的心脏。 ​ 简而言之，CMDB是一个存储库，用于存储有关构成IT基础架构的组件的信息。 这些组件通常称为CI（可配置项）。 据ITIL称，CI是为交付IT服务而需要进行管理的任何资产。 通常，CMDB包括CI的列表，它们的属性以及它们之间的关系。 CMDB的核心功能之一是支持服务管理流程，主要包括：事件，问题，变更，发布和资产管理。 ...

回溯算法实现（DFS） 回溯算法其实就是我们常说的 DFS 算法，本质上就是一种暴力穷举算法 递归遍历二叉树 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 def back_track(nums, track, res): # 结束条件 if len(nums)== len(track): # res.extend(track) # 正常 res.append(track)# 不正常 return None # 遍历选择列表 for num in nums: if num in track: continue track.append(num) back_track(nums, track.copy(), res) track.pop() return None if __name__ == '__main__': nums =[1, 2, 3] track =[] res =[] back_track(nums, track, res) print(res) 某种程度上说，动态规划的暴力求解阶段就是回溯算法。只是有的问题具有重叠子问题性质，可以用 dp table 或者备忘录优化，将递归树大幅剪枝，这就变成了动态规划。而今天的两个问题，都没有重叠子问题，也就是回溯算法问题了，复杂度非常高是不可避免的。 LRU（Least recently used）算法实现 LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。 ...

linux 网络模型 概念说明 在进行解释之前，首先要说明几个概念： 用户空间和内核空间 进程切换 进程的阻塞 文件描述符 缓存 I/O 用户空间与内核空间 ​ 现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。 ​ 针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间。 而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。 进程切换 ​ 为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的。 从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化： 保存处理机上下文，包括程序计数器和其他寄存器。 更新PCB信息。 把进程的PCB移入相应的队列，如就绪、在某事件阻塞等队列。 选择另一个进程执行，并更新其PCB。 更新内存管理的数据结构。 恢复处理机上下文。 总而言之就是很耗资源，具体的可以参考这篇文章：进程切换 进程的阻塞 ​ 正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。 文件描述符fd ​ 文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。 ​ 文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。 缓存 I/O ​ 缓存 I/O 又被称作标准 I/O，大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中，操作系统会将 I/O 的数据缓存在文件系统的**页缓存（ page cache ）**中，也就是说，数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。 缓存 I/O 的缺点： 数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作，这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。 IO拷贝 DMA 负责内核间的 IO 传输，CPU 负责内核和应用间的 IO 传输。 更多详情见：一文彻底揭秘操作系统之「零拷贝」！ - 腾讯云开发者社区-腾讯云 (tencent.com) CPU COPY ​ 通过计算机的组成原理我们知道, 内存的读写操作是需要 CPU 的协调数据总线,地址总线和控制总线来完成的因此在"拷贝"发生的时候,往往需要 CPU 暂停现有的处理逻辑,来协助内存的读写，这种我们称为 CPU COPY。CPU COPY 不但占用了 CPU 资源,还占用了总线的带宽。 DMA COPY ​ DMA(DIRECT MEMORY ACCESS) 是现代计算机的重要功能，它有一个重要特点：当需要与外设进行数据交换时, CPU 只需要初始化这个动作便可以继续执行其他指令,剩下的数据传输的动作完全由DMA来完成可以看到 DMA COPY 是可以避免大量的 CPU 中断的 ...

鸭子类型 定义 鸭子类型（英语：duck typing）在程序设计中是动态类型的一种风格。在这种风格中，一个对象有效的语义，不是由继承自特定的类或实现特定的接口，而是由"当前方法和属性的集合“决定。这个概念的名字来源于由詹姆斯·惠特科姆·莱利提出的鸭子测试（见下面的“历史”章节），“鸭子测试”可以这样表述： ​ “当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。” 在鸭子类型中，关注点在于对象的行为，能作什么；而不是关注对象所属的类型。例如，在不使用鸭子类型的语言中，我们可以编写一个函数，它接受一个类型为"鸭子"的对象，并调用它的"走"和"叫"方法。在使用鸭子类型的语言中，这样的一个函数可以接受一个任意类型的对象，并调用它的"走"和"叫"方法。如果这些需要被调用的方法不存在，那么将引发一个运行时错误。任何拥有这样的正确的"走"和"叫"方法的对象都可被函数接受的这种行为引出了以上表述，这种决定类型的方式因此得名。 鸭子类型通常得益于"不"测试方法和函数中参数的类型，而是依赖文档、清晰的代码和测试来确保正确使用。 在常规类型中，我们能否在一个特定场景中使用某个对象取决于这个对象的类型，而在鸭子类型中，则取决于这个对象是否具有某种属性或者方法——即只要具备特定的属性或方法，能通过鸭子测试，就可以使用。 多态 为什么会在鸭子类型中去介绍多态这个东西，众所周知，面向对象编程的三大特点 继承、封装、多态 ...

RESTful设计方法 原文参考自哔哩哔哩: https://www.bilibili.com/video/BV1k5411p7Kp RESTful API 介绍 REST 代表的是表现层状态转移（REpresentational State Transfer），由 Roy Fielding 在他的论文《Architectural Styles and the Design of Network-based Software Architectures》里提出。 REST 本身并没有创造新的技术、组件或服务，它只是一种软件架构风格，是一组架构约束条件和原则，而不是技术框架。 ...

原文:同源策略、跨域解决方案 一、同源策略 1、先来说说什么是源 • 源（origin）就是协议、域名和端口号。 以上url中的源就是：http://www.company.com:80 若地址里面的协议、域名和端口号均相同则属于同源。 以下是相对于 http://www.a.com/test/index.html 的同源检测 ...

行为型模式 行为型模式，顾名思义，它主要关注的是对象的责任。 它们关注对象之间的交互以及对象的响应性 对象应该能够交互，同时仍然保持松散耦合 观察者模式 在观察者设计模式中，对象（主题）维护了一个依赖（观察者）列表，以便主题可以使用观察者定义的任何方法通知所有观察者它所发生的变化。 它定义了对象之间的一对多的依赖关系，从而使得一个对象中的任何更改都将自动通知给其他对象 它封装了主题的核心组件 UML图 主题(Subject):类Subject需要了解Observe。Subject类具有许多方法，诸如register()和deregister()等，Observer可以通过这些方法注册到Subject类中。因此，一个Subject可以处理多个Observe。 观察者(Observe)：它为关注主题的对象定义了一个接口。它定义了Observe需要实现的各个方法，以便在主题发生变化时能够获得相应的通知。 具体观察者(ConcreteObserver):它用来保存应该与Subject的状态保持一致的状态。它实现了Observe接口以保持其状态与主题中的变化相一致。 代码案例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 #!/usr/bin/env python # -*- coding: utf-8 -*- class Subject(object): def __init__(self): self.__observer = [] def register(self, observer): self.__observer.append(observer) def notifyAll(self, *args, **kwargs): for observer in self.__observer: observer.notify(self, *args, **kwargs) class Observer1(object): def __init__(self, subject): subject.register(self) def notify(self, subject, *args): print(f"{type(self).__name__}:: Got, {args} from {subject}") class Observer2(object): def __init__(self, subject): subject.register(self) def notify(self, subject, *args): print(f"{type(self).__name__}:: Got, {args} from {subject}") if __name__ == '__main__': subject = Subject() observer1 = Observer1(subject) observer2 = Observer2(subject) subject.notifyAll("notify~~~") 观察者模式的优点和缺点 优点： 它使得彼此交互的对象之间保持送耦合 它使得我们可以在无需对主题或观察者进行任何修改的情况下高效地发送数据到其他对象 可以随时添加/删除观察者 缺点： 观察者接口必须由具体观察者实现，这涉及继承。无法进行组合，因为观察者接口可以实例化 如果实现不当的话，观察者可能会增加复杂性，并导致性能降低 在软件应用程序中，通知有时可能是不可靠的，并导致竞争条件或不一致性 ...

django的信号量 原文链接:https://juejin.cn/post/6844903674049724424 一、关于django信号量 Django包含一个"信号调度程序"，它有助于在框架中的其他位置发生操作时通知分离的应用程序。简而言之，信号允许某些发送者通知一组接收器已经发生了某些动作。当许多代码可能对同一事件感兴趣时，它们特别有用. 二、django中内置的信号量 1、Model的信号量 pre_init # django的modal执行其构造方法前，自动触发 post_init # django的modal执行其构造方法后，自动触发 pre_save # django的modal对象保存前，自动触发 post_save # django的modal对象保存后，自动触发 pre_delete # django的modal对象删除前，自动触发 post_delete # django的modal对象删除后，自动触发 m2m_changed # django的modal中使用m2m字段操作第三张表（add,remove,clear）前后，自动触发 class_prepared # 程序启动时，检测已注册的app中modal类，对于每一个类，自动触发 1 2 3 4 5 6 7 8 from django.db.models.signals import class_prepared from django.db.models.signals import pre_init from django.db.models.signals import post_init from django.db.models.signals import pre_save from django.db.models.signals import post_save from django.db.models.signals import pre_delete from django.db.models.signals import post_delete from django.db.models.signals import m2m_changed 2、Management的信号量 pre_migrate # 执行migrate命令前，自动触发 post_migrate # 执行migrate命令后，自动触发 1 2 from django.db.models.signals import pre_migrate from django.db.models.signals import post_migrate 3、Request/Response的信号量 request_started # 请求到来前，自动触发 request_finished # 请求结束后，自动触发 got_request_exception # 请求异常后，自动触发 1 2 3 from django.core.signals import request_finished from django.core.signals import request_started from django.core.signals import got_request_exception 4、Test的信号量 setting_changed # 使用test测试修改配置文件时，自动触发 template_rendered # 使用test测试渲染模板时，自动触发 1 2 from django.test.signals import setting_changed from django.test.signals import template_rendered 5、Database的信号量 connection_created # 创建数据库连接时，自动触发 1 from django.db.backends.signals import connection_created ...