XIAOSUO 记录个人学习的足迹

摘要：Deployment 使用 Kubernetes提供了一种更加简单的更新RC和Pod的机制，叫做Deployment。通过在Deployment中描述你所期望的集群状态，Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成你所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。 事件和状态查看：可以查看Deployment的升级详细进度和状态。 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。 暂停和启动：对于每一次升级，都能够随时暂停和启动。 多种升级方案：Recreate----删除所有已存在的pod,重新创建新的; RollingUpdate----滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。 #创建命令：kubectl create -f deployment.yaml --record #使用rollout history命令，查看Deployment的历史信息：kubectl rollout history deployment cango-demo #使用rollout undo回滚到上一版本: kubectl rollout undo deployment cango-demo #使用–to-revision可以回滚到指定版本: kubectl rollout undo deployment hello-deployment --to-revision=2 1234 ConfigMap 配置 在几乎所有的应用开发中，都会涉及到配置文件的变更，比如说在web的程序中，需要连接数据库，缓存甚至是队列等等。 一些大公司专门开发了自己…… 阅读全文

摘要：webapi：使用asp.net core使用c#创建的Restful服务，就是webapi, webapi中的控制器是派生自ControllerBase的类， ControllerBase类 不要通过从 Controller 类派生来创建 Web API 控制器。 Controller 派生自 ControllerBase，并添加对视图的支持，因此它用于处理 Web 页面，而不是 Web API 请求。 此规则有一个例外：如果打算为视图和 Web API 使用相同的控制器，则从 Controller 派生控制器。 ControllerBase 类提供了很多用于处理 HTTP 请求的属性和方法。 例如，ControllerBase.CreatedAtAction 返回 201 状态代码： 下面是 ControllerBase 提供的方法的更多示例。 方法 说明 BadRequest 返回 400 状态代码。 NotFound 返回 404 状态代码。 PhysicalFile 返回文件。 TryUpdateModelAsync 调用模型绑定。 TryValidateModel 调用模型验证。 特性 Microsoft.AspNetCore.Mvc 命名空间提供可用于配置 Web API 控制器的行为和操作方法的属性。 下述示例使用属性来指定受支持的 HTTP 操作动作和所有可返回的已知 HTTP 状态代码： HttpPost [ProducesResponseType(StatusCodes.Status400BadRequest)] public ActionResult Create(Pet pet) { pet.Id = _petsInMemoryStore.Any() ? _petsInMemoryStore.Max(p = p.Id) + 1 : 1; _petsInMemoryStore.Add(pet); return CreatedAtAction(nameof(GetById), new { id = pet.Id }, pet); } 特性 说明 [[Route\]] 指定控制器或操作的 URL 模式。 [[Bind\]] 指定要包含的前缀和属性，以进行模型绑定。 [[HttpGet\…… 阅读全文

摘要：什么是API API全称Aplication Programming Itererface即应用程序编程接口， 我们在开发应用程序时经常用到。API作为接口，用来“连接”两个不同的系统，并使其中一方为另一 方提供服务，比如在操作系统上运行的应用程序能够访问操作系统所提供的API,并通过这些API来调用操,作系统的各种功能。因此，API 是一个系统向外暴露或公开的一套接口， 通过这些接口，外部应用程序能够访问该系统。在Web应用程序中，Web API具有同样的特性，它作为一个Web应用程序，向外提供了,在Web应用程序中，Web API具有同样的特性，它作为一个Web应用程序，向外提供了一些接口， 这些接口的功能通常是对数据进行操作,一些接口， 这些接口的功能通常是对数据进行操作(如获取或修改数据等)，它们能够被外部应用程序，比如桌面应用程序、手机应用甚至其他Web应用程序(如ASP.NET Core MVC视图应用、单页Web应用)等访问并调用。WebAPI能够实现不同应用程序之间的访问，它与平台或编程语言无关，可以使用不同的技术来构建Web API,如Java、.NET等; 什么是REST REST(Representational State Transfer) 表述性传递状态，Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格，作为一种web服务的设计与开发方式，Rest可以降低开发的复杂性，提高系统的可伸缩性。 REST是一种基于资源的架构风格，在REST中，资源(Resource)是最基本的概念任何能够命名的对象都是资源，如：user,team,order,docment。他表示web服务要操作的一个实体，一个资源具有一个统一资源标识符。(Uniform Resource Identifier URI),如 users/123。通过资源能够标识并访问资源。 资源标识 主键编号进行标识 资源集合 除了单个资源外，资源集合表示多个相同类型的资源，如users。在系统设计时，不同的实体之间往往存在着某种关联关系。如一个用户有多个订单。同样，在REST中，这种关联关系也能够有资源之间的层次关系体现出来。如users/123/orders/1 由于REST资源为中心，因此REST接口的端点(Endpoint)均以资源或资源集合结尾，它…… 阅读全文

摘要：OpenID Connect 如果要谈单点登录和身份认证，就不得不谈OpenID Connect (OIDC)。最典型的使用实例就是使用Google账户登录其他应用，这一经典的协议模式，为其他厂商的第三方登录起到了标杆的作用，被广泛参考和使用。 OpenID Connect简介 OpenID Connect是基于OAuth 2.0规范族的可互操作的身份验证协议。它使用简单的REST / JSON消息流来实现，和之前任何一种身份认证协议相比，开发者可以轻松集成。 OpenID Connect允许开发者验证跨网站和应用的用户，而无需拥有和管理密码文件。OpenID Connect允许所有类型的客户,包括基于浏览器的JavaScript和本机移动应用程序,启动登录流动和接收可验证断言对登录用户的身份。 OpenID的历史是什么？ OpenID Connect是OpenID的第三代技术。首先是原始的OpenID，它不是商业应用，但让行业领导者思考什么是可能的。OpenID 2.0设计更为完善，提供良好的安全性保证。然而，其自身存在一些设计上的局限性，最致命的是其中依赖方必须是网页，但不能是本机应用程序；此外它还要依赖XML，这些都会导致一些应用问题。 OpenID Connect的目标是让更多的开发者使用，并扩大其使用范围。幸运的是，这个目标并不遥远，现在有很好的商业和开源库来帮助实现身份验证机制。 OIDC基础 简要而言，OIDC是一种安全机制，用于应用连接到身份认证服务器（Identity Service）获取用户信息，并将这些信息以安全可靠的方法返回给应用。 在最初，因为OpenID1/2经常和OAuth协议（一种授权协议）一起提及，所以二者经常被搞混。 OpenID是Authentication，即认证，对用户的身份进行认证，判断其身份是否有效，也就是让网站知道“你是你所声称的那个用户”； OAuth是Authorization，即授权，在已知用户身份合法的情况下，经用户授权来允许某些操作，也就是让网站知道“你能被允许做那些事情”。 由此可知，授权要在认证之后进行，只有确定用户身份只有才能授权。 (身份验证)+ OAuth 2.0 = OpenID Connect OpenID Connect是“认证”和“授权”的结合，因为其基于OAuth协议，…… 阅读全文

摘要：OAuth2是什么 OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息 OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0 Oatuh2用来做什么 有这样一种场景，一个用户（假设是QQ），希望让一个第三方的应用（比如说某个论坛），能够得到关于自身的一些信息（唯一用户标识，比如说QQ号，用户个人信息，比如说是一些基础资料，昵称和头像等）。但是在获得这些资料的同时，却也不能提供用户名和密码之类的验证信息。比如说用户不可能将自身的用户名和密码给第三方让第三方到用户中心之类的地方去获取信息。要达到这样的结果肯定有许多的实现方式。而Oatuh2就是实现上述目标的一种规范，或者说是具体实现的指导方案。 Oauth2具体做法 OAuth定义了四个角色： 资源所有者（resource owner）： 能够对受保护资源授予访问权限的实体。当资源所有者是一个人时，它被称为终端用户。 资源服务器（resource server）： 托管受保护资源的服务器，能够接受和响应通过令牌对受保护的资源的请求。 客户端（client）： 代表资源所有者及其授权进行受保护资源请求的应用程序。术语“客户端”并不暗示任何特定的实现特征（例如，应用程序是在服务器，台式机还是其他设备上执行）。 授权服务器（authorization server）： 成功后，服务器向客户端发出访问令牌验证资源所有者并获得授权。 授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以是与资源服务器相同的服务器或单独的实体。单个授权服务器可以发出可以被多个资源服务器接受的访问令牌。 Oauth2的流程 Oauth2，根据RFC6749文档，大致的流程如下图所示 上图中的client就是第三方应用。可以看到，Oauth的大致思路是一个线性的流程。 第三方应用向资源持有者请求获取资源 资源持有者授权给予第三方应用一个许可 第三方应用将该许可给予认证服务器进行认证，如果认证成功，返回一个Access Token 第三方应用使用该access token到资源服务器处获取该access token对应的资源（也就是第一步中资源持有者自身的资源） …… 阅读全文

摘要：CPU是什么 我们都知道的定义是这样的：CPU又称中央处理器，它的英文全称为：Central Processing Unit，但同时如果你听到：Central Processor或者Main Processor往往同样也指的是CPU。 普通程序员开发的程序，其实绝大多数指的就是对中央处理器也就是CPU的编程。这句话也可能会被面试人员反着描述为，计算机的可编程性主要是指对中央处理器的编程。 在最初的时候，大约是1970年代以前，中央处理器由多个独立单元构成，后来才发展成集成电路，这些高度收缩的组件就是所谓的：微处理器。 另外，中央处理器广义上来说，是可以指代一系列可以执行复杂的计算机程序的逻辑机器。还记得三体中秦始皇嬴政派出无数士兵进行逻辑与或非运算吗？那样的场景，其实就是实现了广义上的中央处理器。 注意：ENIAC(Electronic Numerical Integrator And Computer)是世界上第一台”电子存储式可编程计算机”，但是由于他们也存在计算功能，而CPU的标准定义为：执行软件(计算机程序)的设备所以，ENIAC理论上不存在标准的CPU，但是最早于存储程序型计算机一通登场的设备是可以被称作CPU的，也就是说：CPU并不一定是微型的，早起的同步CPU是非常大的。直到1950~60年代的晶体管CPU时，CPU才慢慢变小。不再以体积庞大，不可靠与易碎的开关组件(继电器/真空管)组成或建造。 参考来自于维基百科，与哈佛计算机原理书籍，国内的一些小众参考资料与翻译是错误的，一定要注意。CPU并不小。尤其是百度百科，它所提供的参考资料只提及了”微”，但是万物相对论，没有相对何来形容词？从本段落开始，咱们只讨论：冯·诺依曼机，不讨论哈佛架构。 CPU的主要运作原理 CPU的主要运作原理很简单。不论其外观，都是执行存储与被称为”程序”里的一系列指令。所以说计算机是最愚蠢的傻子，没有码农他们就是一坨铁。 在冯诺依曼架构中，程序以一系列数字存储在计算机存储器中。 而只要是冯诺依曼机，CPU的运作原理就可以看成四个阶段：提取，解码，执行，回写。 提取：从程序内存中检索指令(程序内存，指的可不是你程序里面定义了一个int的这个内存，而是存储程序的内存)，由程序计数器指定程序存储器的位置，计数器保存供识别当前程序位置的数值(原始资料原文)。 拿人话说：程序计数…… 阅读全文

摘要：虽然散列表在关键字和存储位置之间建立了对应关系，理想情况是无须关键字的比较就可找到待查关键字。但是由于冲突的存在，散列表的查找过程仍是一个和关键字比较的过程，不过散列表的平均查找长度比顺序查找、二分查找等完全依赖于关键字比较的查找要小得多。 注意： 　 ①由同一个散列函数、不同的解决冲突方法构造的散列表，其平均查找长度是不相同的。 　②散列表的平均查找长度不是结点个数n的函数，而是装填因子α的函数。因此在设计散列表时可选择α以控制散列表的平均查找长度。 　③ α的取值 　α越小，产生冲突的机会就小，但α过小，空间的浪费就过多。只要α选择合适，散列表上的平均查找长度就是一个常数，即散列表上查找的平均时间为O(1)。 　④ 散列法与其他查找方法的区别 除散列法外，其他查找方法有共同特征为：均是建立在比较关键字的基础上。其中顺序查找是对无序集合的查找，每次关键字的比较结果为"="或"!="两种可能，其平均时间为O(n)；其余的查找均是对有序集合的查找，每次关键字的比较有"="、"<"和">"三种可能，且每次比较后均能缩小下次的查找范围，故查找速度更快，其平均时间为O(lgn)。而散列法是根据关键字直接求出地址的查找方法，其查找的期望时间为O(1)。 阅读全文

摘要：在用线性查找和二分查找的过程中需要依据关键字进行若干次的比较判断，确定数据集合中是否存在关键字等于某个给定关键字的记录以及该记录在数据表中的位置，查找效率与比较的次数密切相关。在查找时需要不断进行比较的原因是建立数据表时，只考虑了各记录的关键字之间的相对大小，记录在表中的位置和其关键字无直接关系。而之前介绍的哈希表就记录了存储位置和其关键字之间的某种直接关系，那么使用哈希表进行查找时，就无须比较或只做很少的比较久能直接由关键字找到相应的记录。实际上哈希表也就是为解决查找问题提出的。具体哈希表的内容请参考之前的“散列表”相关文章。 阅读全文

摘要：　分块查找(Blocking Search)又称索引顺序查找。它是一种性能介于顺序查找和二分查找之间的查找方法。 一、 二分查找表存储结构 　二分查找表由分块有序的线性表和索引表组成。 （1）分块有序的线性表 　表R[1..n]均分为b块，前b-1块中结点个数为 ，第b块的结点数小于等于s；每一块中的关键字不一定有序，但前一块中的最大关键字必须小于后一块中的最小关键字，即表是分块有序的。 （... 阅读全文

摘要：一、二分查找(Binary Search) 　 二分查找又称折半查找，它是一种效率较高的查找方法。 　二分查找要求：线性表是有序表，即表中结点按关键字有序，并且要用向量作为表的存储结构。不妨设有序表是递增有序的。 二、二分查找的基本思想 　二分查找的基本思想是：（设R[low..high]是当前的查找区间） （1）首先确定该区间的中点位置： （2）然后将待查的K值与R[mid].key... 阅读全文