2020¶

2020年9月23日
分类于 python
需要 6 分钟阅读时间

python 中日志异步发送到远程服务器

在python中使用日志最常用的方式就是在控制台和文件中输出日志了,logging模块也很好的提供的相应的类,使用起来也非常方便,但是有时我们可能会有一些需求,如还需要将日志发送到远端,或者直接写入数据库,这种需求该如何实现呢?

2020年9月20日
分类于 python
需要 2 分钟阅读时间

python 中的functools.partial用法

经常会看到有些代码中使用 functools.partial 来包装一个函数，之前没有太了解它的用法，只是按照别人的代码来写，今天仔细看了一下它的用法，基本的用法还是很简单的。

2020年2月14日
分类于 Go
需要 4 分钟阅读时间

golang高并发模型

github上看到的一篇关于golang高并发性的文章，觉得写的非常好

github 地址 https://github.com/rubyhan1314/Golang-100-Days

一、并发性Concurrency

1.1 多任务

怎么来理解多任务呢？其实就是指我们的操作系统可以同时执行多个任务。举个例子，你一边听音乐，一边刷微博，一边聊QQ，一边用Markdown写作业，这就是多任务，至少同时有4个任务正在运行。还有很多任务悄悄地在后台同时运行着，只是界面上没有显示而已。

1.2 什么是并发

Go是并发语言，而不是并行语言。在讨论如何在Go中进行并发处理之前，我们首先必须了解什么是并发，以及它与并行性有什么不同。(Go is a concurrent language and not a parallel one. )

并发性Concurrency是同时处理许多事情的能力。

举个例子，假设一个人在晨跑。在晨跑时，他的鞋带松了。现在这个人停止跑步，系鞋带，然后又开始跑步。这是一个典型的并发性示例。这个人能够同时处理跑步和系鞋带，这是一个人能够同时处理很多事情。

什么是并行性parallelism，它与并发concurrency有什么不同? 并行就是同时做很多事情。这听起来可能与并发类似，但实际上是不同的。

让我们用同样的慢跑例子更好地理解它。在这种情况下，我们假设这个人正在慢跑，并且使用它的手机听音乐。在这种情况下，一个人一边慢跑一边听音乐，那就是他同时在做很多事情。这就是所谓的并行性(parallelism)。

并发性和并行性——一种技术上的观点。假设我们正在编写一个web浏览器。web浏览器有各种组件。其中两个是web页面呈现区域和下载文件从internet下载的下载器。假设我们以这样的方式构建了浏览器的代码，这样每个组件都可以独立地执行。当这个浏览器运行在单个核处理器中时，处理器将在浏览器的两个组件之间进行上下文切换。它可能会下载一个文件一段时间，然后它可能会切换到呈现用户请求的网页的html。这就是所谓的并发性。并发进程从不同的时间点开始，它们的执行周期重叠。在这种情况下，下载和呈现从不同的时间点开始，它们的执行重叠。

假设同一浏览器运行在多核处理器上。在这种情况下，文件下载组件和HTML呈现组件可能同时在不同的内核中运行。这就是所谓的并行性。

WX20190730-100944

并行性Parallelism不会总是导致更快的执行时间。这是因为并行运行的组件可能需要相互通信。例如，在我们的浏览器中，当文件下载完成时，应该将其传递给用户，比如使用弹出窗口。这种通信发生在负责下载的组件和负责呈现用户界面的组件之间。这种通信开销在并发concurrent 系统中很低。当组件在多个内核中并行concurrent 运行时，这种通信开销很高。因此，并行程序并不总是导致更快的执行时间!

1.3 进程、线程、协程

进程(Process)，线程(Thread)，协程(Coroutine，也叫轻量级线程)

进程进程是一个程序在一个数据集中的一次动态执行过程，可以简单理解为“正在执行的程序”，它是CPU资源分配和调度的独立单位。进程一般由程序、数据集、进程控制块三部分组成。我们编写的程序用来描述进程要完成哪些功能以及如何完成；数据集则是程序在执行过程中所需要使用的资源；进程控制块用来记录进程的外部特征，描述进程的执行变化过程，系统可以利用它来控制和管理进程，它是系统感知进程存在的唯一标志。 进程的局限是创建、撤销和切换的开销比较大。

线程线程是在进程之后发展出来的概念。线程也叫轻量级进程，它是一个基本的CPU执行单元，也是程序执行过程中的最小单元，由线程ID、程序计数器、寄存器集合和堆栈共同组成。一个进程可以包含多个线程。线程的优点是减小了程序并发执行时的开销，提高了操作系统的并发性能，缺点是线程没有自己的系统资源，只拥有在运行时必不可少的资源，但同一进程的各线程可以共享进程所拥有的系统资源，如果把进程比作一个车间，那么线程就好比是车间里面的工人。不过对于某些独占性资源存在锁机制，处理不当可能会产生“死锁”。

协程协程是一种用户态的轻量级线程，又称微线程，英文名Coroutine，协程的调度完全由用户控制。人们通常将协程和子程序（函数）比较着理解。子程序调用总是一个入口，一次返回，一旦退出即完成了子程序的执行。

与传统的系统级线程和进程相比，协程的最大优势在于其"轻量级"，可以轻松创建上百万个而不会导致系统资源衰竭，而线程和进程通常最多也不能超过1万的。这也是协程也叫轻量级线程的原因。

协程与多线程相比，其优势体现在：协程的执行效率极高。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，协程的性能优势就越明显。

Go语言对于并发的实现是靠协程，Goroutine

二、Go语言的并发模型

Go 语言相比Java等一个很大的优势就是可以方便地编写并发程序。Go 语言内置了 goroutine 机制，使用goroutine可以快速地开发并发程序，更好的利用多核处理器资源。接下来我们来了解一下Go语言的并发原理。

2.1 线程模型

在现代操作系统中，线程是处理器调度和分配的基本单位，进程则作为资源拥有的基本单位。每个进程是由私有的虚拟地址空间、代码、数据和其它各种系统资源组成。线程是进程内部的一个执行单元。每一个进程至少有一个主执行线程，它无需由用户去主动创建，是由系统自动创建的。用户根据需要在应用程序中创建其它线程，多个线程并发地运行于同一个进程中。

我们先从线程讲起，无论语言层面何种并发模型，到了操作系统层面，一定是以线程的形态存在的。而操作系统根据资源访问权限的不同，体系架构可分为用户空间和内核空间；内核空间主要操作访问CPU资源、I/O资源、内存资源等硬件资源，为上层应用程序提供最基本的基础资源，用户空间呢就是上层应用程序的固定活动空间，用户空间不可以直接访问资源，必须通过“系统调用”、“库函数”或“Shell脚本”来调用内核空间提供的资源。

我们现在的计算机语言，可以狭义的认为是一种“软件”，它们中所谓的“线程”，往往是用户态的线程，和操作系统本身内核态的线程（简称KSE），还是有区别的。

Go并发编程模型在底层是由操作系统所提供的线程库支撑的，因此还是得从线程实现模型说起。

线程可以视为进程中的控制流。一个进程至少会包含一个线程，因为其中至少会有一个控制流持续运行。因而，一个进程的第一个线程会随着这个进程的启动而创建，这个线程称为该进程的主线程。当然，一个进程也可以包含多个线程。这些线程都是由当前进程中已存在的线程创建出来的，创建的方法就是调用系统调用，更确切地说是调用 pthread create函数。拥有多个线程的进程可以并发执行多个任务，并且即使某个或某些任务被阻塞，也不会影响其他任务正常执行，这可以大大改善程序的响应时间和吞吐量。另一方面，线程不可能独立于进程存在。它的生命周期不可能逾越其所属进程的生命周期。

线程的实现模型主要有3个，分别是:用户级线程模型、内核级线程模型和两级线程模型。它们之间最大的差异就在于线程与内核调度实体( Kernel Scheduling Entity,简称KSE)之间的对应关系上。顾名思义，内核调度实体就是可以被内核的调度器调度的对象。在很多文献和书中，它也称为内核级线程，是操作系统内核的最小调度单元。

2.1.1 内核级线程模型

用户线程与KSE是1对1关系(1:1)。大部分编程语言的线程库(如linux的pthread，Java的java.lang.Thread，C++11的std::thread等等)都是对操作系统的线程（内核级线程）的一层封装，创建出来的每个线程与一个不同的KSE静态关联，因此其调度完全由OS调度器来做。这种方式实现简单，直接借助OS提供的线程能力，并且不同用户线程之间一般也不会相互影响。但其创建，销毁以及多个线程之间的上下文切换等操作都是直接由OS层面亲自来做，在需要使用大量线程的场景下对OS的性能影响会很大。

moxing2

每个线程由内核调度器独立的调度，所以如果一个线程阻塞则不影响其他的线程。

优点：在多核处理器的硬件的支持下，内核空间线程模型支持了真正的并行，当一个线程被阻塞后，允许另一个线程继续执行，所以并发能力较强。

缺点：每创建一个用户级线程都需要创建一个内核级线程与其对应，这样创建线程的开销比较大，会影响到应用程序的性能。

2.1.2 用户级线程模型

用户线程与KSE是多对1关系(M:1)，这种线程的创建，销毁以及多个线程之间的协调等操作都是由用户自己实现的线程库来负责，对OS内核透明，一个进程中所有创建的线程都与同一个KSE在运行时动态关联。现在有许多语言实现的协程基本上都属于这种方式。这种实现方式相比内核级线程可以做的很轻量级，对系统资源的消耗会小很多，因此可以创建的数量与上下文切换所花费的代价也会小得多。但该模型有个致命的缺点，如果我们在某个用户线程上调用阻塞式系统调用(如用阻塞方式read网络IO)，那么一旦KSE因阻塞被内核调度出CPU的话，剩下的所有对应的用户线程全都会变为阻塞状态（整个进程挂起）。所以这些语言的**协程库**会把自己一些阻塞的操作重新封装为完全的非阻塞形式，然后在以前要阻塞的点上，主动让出自己，并通过某种方式通知或唤醒其他待执行的用户线程在该KSE上运行，从而避免了内核调度器由于KSE阻塞而做上下文切换，这样整个进程也不会被阻塞了。

moxing1

优点：这种模型的好处是线程上下文切换都发生在用户空间，避免的模态切换（mode switch），从而对于性能有积极的影响。

缺点：所有的线程基于一个内核调度实体即内核线程，这意味着只有一个处理器可以被利用，在多处理器环境下这是不能够被接受的，本质上，用户线程只解决了并发问题，但是没有解决并行问题。如果线程因为 I/O 操作陷入了内核态，内核态线程阻塞等待 I/O 数据，则所有的线程都将会被阻塞，用户空间也可以使用非阻塞而 I/O，但是不能避免性能及复杂度问题。

2.1.3 两级线程模型

用户线程与KSE是多对多关系(M:N)，这种实现综合了前两种模型的优点，为一个进程中创建多个KSE，并且线程可以与不同的KSE在运行时进行动态关联，当某个KSE由于其上工作的线程的阻塞操作被内核调度出CPU时，当前与其关联的其余用户线程可以重新与其他KSE建立关联关系。当然这种动态关联机制的实现很复杂，也需要用户自己去实现，这算是它的一个缺点吧。Go语言中的并发就是使用的这种实现方式，Go为了实现该模型自己实现了一个运行时调度器来负责Go中的"线程"与KSE的动态关联。此模型有时也被称为 混合型线程模型，即用户调度器实现用户线程到KSE的“调度”，内核调度器实现KSE到CPU上的调度。

moxing3

2.2 Go并发调度: G-P-M模型

在操作系统提供的内核线程之上，Go搭建了一个特有的两级线程模型。goroutine机制实现了M : N的线程模型，goroutine机制是协程（coroutine）的一种实现，golang内置的调度器，可以让多核CPU中每个CPU执行一个协程。

2.2.1 调度器是如何工作的

有了上面的认识，我们可以开始真正的介绍Go的并发机制了，先用一段代码展示一下在Go语言中新建一个“线程”(Go语言中称为Goroutine)的样子：

// 用go关键字加上一个函数（这里用了匿名函数）
// 调用就做到了在一个新的“线程”并发执行任务
go func() { 
    // do something in one new goroutine
}()

功能上等价于Java8的代码:

new java.lang.Thread(() -> { 
    // do something in one new thread
}).start();

理解goroutine机制的原理，关键是理解Go语言scheduler的实现。

Go语言中支撑整个scheduler实现的主要有4个重要结构，分别是M、G、P、Sched，前三个定义在runtime.h中，Sched定义在proc.c中。

Sched结构就是调度器，它维护有存储M和G的队列以及调度器的一些状态信息等。
M结构是Machine，系统线程，它由操作系统管理的，goroutine就是跑在M之上的；M是一个很大的结构，里面维护小对象内存cache（mcache）、当前执行的goroutine、随机数发生器等等非常多的信息。
P结构是Processor，处理器，它的主要用途就是用来执行goroutine的，它维护了一个goroutine队列，即runqueue。Processor是让我们从N:1调度到M:N调度的重要部分。
G是goroutine实现的核心结构，它包含了栈，指令指针，以及其他对调度goroutine很重要的信息，例如其阻塞的channel。

Processor的数量是在启动时被设置为环境变量GOMAXPROCS的值，或者通过运行时调用函数GOMAXPROCS()进行设置。Processor数量固定意味着任意时刻只有GOMAXPROCS个线程在运行go代码。

我们分别用三角形，矩形和圆形表示Machine Processor和Goroutine。

moxing4

在单核处理器的场景下，所有goroutine运行在同一个M系统线程中，每一个M系统线程维护一个Processor，任何时刻，一个Processor中只有一个goroutine，其他goroutine在runqueue中等待。一个goroutine运行完自己的时间片后，让出上下文，回到runqueue中。多核处理器的场景下，为了运行goroutines，每个M系统线程会持有一个Processor。

moxing5

在正常情况下，scheduler会按照上面的流程进行调度，但是线程会发生阻塞等情况，看一下goroutine对线程阻塞等的处理。

2.2.2 线程阻塞

当正在运行的goroutine阻塞的时候，例如进行系统调用，会再创建一个系统线程（M1），当前的M线程放弃了它的Processor，P转到新的线程中去运行。

moxing6

2.2.3 runqueue执行完成

当其中一个Processor的runqueue为空，没有goroutine可以调度。它会从另外一个上下文偷取一半的goroutine。

moxing7

其图中的G，P和M都是Go语言运行时系统（其中包括内存分配器，并发调度器，垃圾收集器等组件，可以想象为Java中的JVM）抽象出来概念和数据结构对象： G：Goroutine的简称，上面用go关键字加函数调用的代码就是创建了一个G对象，是对一个要并发执行的任务的封装，也可以称作用户态线程。属于用户级资源，对OS透明，具备轻量级，可以大量创建，上下文切换成本低等特点。 M：Machine的简称，在linux平台上是用clone系统调用创建的，其与用linux pthread库创建出来的线程本质上是一样的，都是利用系统调用创建出来的OS线程实体。M的作用就是执行G中包装的并发任务。Go运行时系统中的调度器的主要职责就是将G公平合理的安排到多个M上去执行。其属于OS资源，可创建的数量上也受限了OS，通常情况下G的数量都多于活跃的M的。 P：Processor的简称，逻辑处理器，主要作用是管理G对象（每个P都有一个G队列），并为G在M上的运行提供本地化资源。

从两级线程模型来看，似乎并不需要P的参与，有G和M就可以了，那为什么要加入P这个东东呢？其实Go语言运行时系统早期(Go1.0)的实现中并没有P的概念，Go中的调度器直接将G分配到合适的M上运行。但这样带来了很多问题，例如，不同的G在不同的M上并发运行时可能都需向系统申请资源（如堆内存），由于资源是全局的，将会由于资源竞争造成很多系统性能损耗，为了解决类似的问题，后面的Go（Go1.1）运行时系统加入了P，让P去管理G对象，M要想运行G必须先与一个P绑定，然后才能运行该P管理的G。这样带来的好处是，我们可以在P对象中预先申请一些系统资源（本地资源），G需要的时候先向自己的本地P申请（无需锁保护），如果不够用或没有再向全局申请，而且从全局拿的时候会多拿一部分，以供后面高效的使用。就像现在我们去政府办事情一样，先去本地政府看能搞定不，如果搞不定再去中央，从而提供办事效率。而且由于P解耦了G和M对象，这样即使M由于被其上正在运行的G阻塞住，其余与该M关联的G也可以随着P一起迁移到别的活跃的M上继续运行，从而让G总能及时找到M并运行自己，从而提高系统的并发能力。 Go运行时系统通过构造G-P-M对象模型实现了一套用户态的并发调度系统，可以自己管理和调度自己的并发任务，所以可以说Go语言**原生支持并发**。自己实现的调度器负责将并发任务分配到不同的内核线程上运行，然后内核调度器接管内核线程在CPU上的执行与调度。

可以看到Go的并发用起来非常简单，用了一个语法糖将内部复杂的实现结结实实的包装了起来。其内部可以用下面这张图来概述：

goroutine2

写在最后，Go运行时完整的调度系统是很复杂，很难用一篇文章描述的清楚，这里只能从宏观上介绍一下，让大家有个整体的认识。

// Goroutine1
func task1() {
    go task2()
    go task3()
}

假如我们有一个G(Goroutine1)已经通过P被安排到了一个M上正在执行，在Goroutine1执行的过程中我们又创建两个G，这两个G会被马上放入与Goroutine1相同的P的本地G任务队列中，排队等待与该P绑定的M的执行，这是最基本的结构，很好理解。关键问题是: a.如何在一个多核心系统上尽量合理分配G到多个M上运行，充分利用多核，提高并发能力呢？ 如果我们在一个Goroutine中通过**go**关键字创建了大量G，这些G虽然暂时会被放在同一个队列, 但如果这时还有空闲P（系统内P的数量默认等于系统cpu核心数），Go运行时系统始终能保证至少有一个（通常也只有一个）活跃的M与空闲P绑定去各种G队列去寻找可运行的G任务，该种M称为**自旋的M**。一般寻找顺序为：自己绑定的P的队列，全局队列，然后其他P队列。如果自己P队列找到就拿出来开始运行，否则去全局队列看看，由于全局队列需要锁保护，如果里面有很多任务，会转移一批到本地P队列中，避免每次都去竞争锁。如果全局队列还是没有，就要开始玩狠的了，直接从其他P队列偷任务了（偷一半任务回来）。这样就保证了在还有可运行的G任务的情况下，总有与CPU核心数相等的M+P组合在执行G任务或在执行G的路上(寻找G任务)。 b. 如果某个M在执行G的过程中被G中的系统调用阻塞了，怎么办？ 在这种情况下，这个M将会被内核调度器调度出CPU并处于阻塞状态，与该M关联的其他G就没有办法继续执行了，但Go运行时系统的一个监控线程(sysmon线程)能探测到这样的M，并把与该M绑定的P剥离，寻找其他空闲或新建M接管该P，然后继续运行其中的G，大致过程如下图所示。然后等到该M从阻塞状态恢复，需要重新找一个空闲P来继续执行原来的G，如果这时系统正好没有空闲的P，就把原来的G放到全局队列当中，等待其他M+P组合发掘并执行。

c. 如果某一个G在M运行时间过长，有没有办法做抢占式调度，让该M上的其他G获得一定的运行时间，以保证调度系统的公平性? 我们知道linux的内核调度器主要是基于时间片和优先级做调度的。对于相同优先级的线程，内核调度器会尽量保证每个线程都能获得一定的执行时间。为了防止有些线程"饿死"的情况，内核调度器会发起抢占式调度将长期运行的线程中断并让出CPU资源，让其他线程获得执行机会。当然在Go的运行时调度器中也有类似的抢占机制，但并不能保证抢占能成功，因为Go运行时系统并没有内核调度器的中断能力，它只能通过向运行时间过长的G中设置抢占flag的方法温柔的让运行的G自己主动让出M的执行权。说到这里就不得不提一下Goroutine在运行过程中可以动态扩展自己线程栈的能力，可以从初始的2KB大小扩展到最大1G（64bit系统上），因此在每次调用函数之前需要先计算该函数调用需要的栈空间大小，然后按需扩展（超过最大值将导致运行时异常）。Go抢占式调度的机制就是利用在判断要不要扩栈的时候顺便查看以下自己的抢占flag，决定是否继续执行，还是让出自己。运行时系统的监控线程会计时并设置抢占flag到运行时间过长的G，然后G在有函数调用的时候会检查该抢占flag，如果已设置就将自己放入全局队列，这样该M上关联的其他G就有机会执行了。但如果正在执行的G是个很耗时的操作且没有任何函数调用(如只是for循环中的计算操作)，即使抢占flag已经被设置，该G还是将一直霸占着当前M直到执行完自己的任务。

2020年2月12日
分类于计算机相关
需要 2 分钟阅读时间

ubuntu上部署hexo博客

之前这个个人博客一直挂在github pages或者coding pages下面，之前在百度云上买了一台云服务器，闲着也是闲着，就将个人博客转到这上面来吧。

本文从一个纯净的ubuntu系统开始，到最后的上线，主要涉及以下内容

云服务器上git环境的搭建
云服务器上nginx的设置
云服务器上https证书的设置
本地hexo提交到云服务器
云服务器git 钩子设置
设置图片防盗链

一步一步来，我买的是ubuntu 18.04 x64

一、云服务器上git环境的搭建

1.1 安装git

1 2	`# apt-get update # apt-get install git`

1.2 初始化git仓库

root@instance-tgmmsl5q:~# mkdir myblog
root@instance-tgmmsl5q:~# chown -R $USER:$USER myblog/
root@instance-tgmmsl5q:~# chmod -R 755 myblog/
root@instance-tgmmsl5q:~# cd myblog/
root@instance-tgmmsl5q:~/myblog# git init --bare hexo_blog.git
Initialized empty Git repository in /root/myblog/hexo_blog.git/

这时我们就创建了一个空的git仓库

二、设置nginx环境

2.1 安装nginx

1 2	`# apt-get update # apt-get install nginx`

2.2 设置nginx环境

我们将hexo的index目录设置为 /var/www/myblog

root@instance-tgmmsl5q:~/myblog# cd /var/www/
root@instance-tgmmsl5q:/var/www# mkdir myblog
root@instance-tgmmsl5q:/var/www# chown -R $USER:$USER myblog/
root@instance-tgmmsl5q:/var/www# chmod -R 755 myblog/

2.3 绑定域名

需要将www.yangyanxing.com 的域名指向/var/www/myblog

在/etc/nginx/sites-available创建yangyanxing.com文件，写入

server {
        listen 80;
        listen [::]:80;

        server_name www.yangyanxing.com;

        root /var/www/myblog;
        index index.html;

        location / {
                try_files $uri $uri/ =404;
        }

    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
        access_log off;
        expires 1d;
    }
    location ~ \.(js|css) {
       access_log off;
       expires 1d;
    }
}

然后创建一个链接文件 ln -s /etc/nginx/sites-available/yangyanxing.com /etc/nginx/sites-enabled/

重启nignx sytemctl restart nginx ，在/var/www/myblog 目录下写一个index.html文件，然后再访问一下www.yangyanxing.com 查看nginx域名设置是否生效，如果是你设置的index.html则说明生效了.

三、云服务器上https证书的设置

添加 certbot 源

1	`add-apt-repository ppa:certbot/certbot`

安装certbot

apt-get update && apt-get install python-certbot-nginx -y

生成证书，会有几个步骤

输入邮箱，随意填
是否同意许可，Y
是否分享你的电子邮件 N
选择哪个域名需要添加证书，这里输入列出的编号
是否将http强制跳转到https，我选是 2

执行完脚本以后，我们再浏览器中刷新一下，之前的http就自动跳转到了https则说明设置https成功。

Let's Encrypt 签发的 SSL 证书有效期只有 90 天，所以在过期之前，需要自动更新 SSL 证书。最新版 certbot 会自动添加更新脚本到 /etc/cron.d 里，此脚本每隔 12 小时运行一次，并将续订任何在30天内到期的证书。输入以下命令检测自动续签是否工作：

certbot renew --dry-run

命令运行后如果没有报错，即说明自动续签可以正常工作。

四、本地hexo提交到云服务器

在第一步中初始化git仓库以后，服务器上的地址为/root/myblog/hexo_blog.git

我们是可以得到git的地址为你的服务器用户名@云服务器的IP地址:/root/myblog/hexo_blog.git

先本地clone一下这个项目，前提是需要将本机的公钥文件id_rsa.pub 复制到云服务器中的authorized_keys 文件里。

设置本地hexo的_config.yml 文件

deploy:
-  type: git
   repo: `你的服务器用户名@云服务器的IP地址:/root/myblog/hexo_blog.git`
   branch: master

然后就可以使用hexo d 来提交部署，如果没有报错，则继续往下走。

五、云服务器git 钩子设置

云服务器上的git的钩子设置是为了将提交上来的文件，将其拷贝到第二步中nginx设置的域名目录

创建 /root/myblog/hexo_blog.git/hooks/post-receive

设置为

#!/bin/bash
git --work-tree=/var/www/myblog --git-dir=/root/myblog/hexo_blog.git checkout -f

保存退出，并添加执行权限，之后再hexo d 提交一下，看看是否可以正常自动部署了！

六、设置图片防盗链

其实经过上面几步的操作以后，基本上已经完成了hexo向云服务器自动部署了，但是可以再做一些优化，比如图片防盗链.

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
        access_log off;
        expires 1d;
        valid_referers none server_names *.yangyanxing.com;
        if ($invalid_referer){
            rewrite ^/ http://ww1.sinaimg.cn/large/795ab47fly1g4a6llk7wjj20c808174s.jpg;
        }
    }

valid_referers 这行的作用是配置可以识别 refer，即可以正常获取资源文件的请求，在这里配置加入白名单的请求 refer 域名。参数说明：

none 代表请求的 refer 为空，也就是直接访问，比如在浏览器中直接访问图片 www.yangyanxing.com/test1.png，直接访问时，refer 会为空。
blocked refer 来源不为空，但是里面的值被代理或者防火墙删除了
server_names refer 来源包含当前的 server_names 即 location 的父节点 server 节点的 server_name 的值。
字符串 定义服务器名称，比如 *.test1.com，配置后，来源是从 test1.com 就会被认为是合法的请求。
正则表达式 匹配合法请求来源，如 ~\.test2\.

当请求的 refer 是合法的，即可以被后面任一参数所匹配， $invalid_referer 的值为0，若不匹配则值为 1，进入 if 的代码中。我这里的设置是，如果是不合法的请求，就统一返回一张图片，也可以直接返回 403。

参考文章

在Ubuntu18.04服务器上部署Hexo博客

图片防盗链

2020年2月11日
分类于 k8s
需要 3 分钟阅读时间

kubernetes中使用dns来访问服务

之前的文章kubernetes中pod间的通信中，我们使用环境变量来解析服务的IP，但是可以使用环境变量有一个限制，所有的pods须在一个namespace中，也就是说在同一个namespace中的pod才会共享环境变量，如果不在同一个namespace该如何访问呢？我们还是一个python的flask应用为例，这次我们将redis放到default的namespace中，flask的应用放到yyxtest的namespace中。

创建redis的pod与service

redis.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: redis
  name: redis-master
spec:
  selector:
    matchLabels:
      app: redis
  replicas: 1
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - image: redis
        name: redis-master2
        ports:
        - containerPort: 6379

redis-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: redis-master-sr
  labels:
    name: redis-master
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis

查看pod与service信息

# kubectl get pods
NAME                            READY   STATUS      RESTARTS   AGE
redis-master-wjq6t              1/1     Running     0          8m55s

C:\Users\54523\Desktop\k8stest>kubectl get service
NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
redis-master-sr   ClusterIP   10.97.140.58     <none>        6379/TCP         3m3s

创建python应用

#-*- coding:utf-8 -*-
# author:Yang
# datetime:2020/2/10 16:07
# software: PyCharm

from flask import Flask
from flask_redis import FlaskRedis
import time
import os

if os.environ.get("envname") == "k8s": # 说明是在k8s中
    redis_server = os.environ.get("REDIS_MASTER_SR_SERVICE_HOST")
    redis_port = os.environ.get("REDIS_MASTER_SR_SERVICE_PORT")
    REDIS_URL = "redis://{}:{}/{}".format(redis_server, redis_port, 1)
else:
    REDIS_URL = "redis://{}:{}/{}".format('127.0.0.1', 6380, 1)


app = Flask(__name__)
app.config['REDIS_URL'] = REDIS_URL
redis_client = FlaskRedis(app)

@app.route("/")
def index_handle():
    redis_client.set("reidstest",time.strftime("%Y-%m-%d %H:%M:%S",time.localtime(time.time())))
    name = redis_client.get("reidstest").decode()
    return "hello %s"% name

app.run(host='0.0.0.0', port=6000, debug=True)

上面是之前的代码，采用环境变量的方式，获取到redis_server和redis_port，之前创建flask的应用的pod和service都没有指定namespace,如果没有指定的话，默认是创建在了default的namespace，由于redis也没有指定，所以它们之间是可以通过共享环境变量来解决服务地址的，那现在我们将python应用创建在yyxtest的namespace中，看看情况如何。

将先之前python应用打包 docker build -t flaskk8s:dns .

创建deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: flasktest
  name: flasktest
  namespace: yyxtest
spec:
  selector:
    matchLabels:
      app: flasktest
  replicas: 2
  template:
    metadata:
      labels:
        app: flasktest
    spec:
      containers:
      - image: flaskk8s:dns
        name: flaskweb
        imagePullPolicy: Never
        ports:
        - containerPort: 6000

再创建service.yaml

apiVersion: v1
kind: Service
metadata:
  name: flask-service
  labels:
    name: flaskservice
  namespace: yyxtest
spec:
  type: NodePort
  ports:
  - port: 6000
    nodePort: 30003
  selector:
    app: flasktest

这次在deployment和service中的metadata中都添加了namespace: yyxtest ，它们将会被创建到 yyxtest的namespace中

使用kubectl get pods --namespace=yyxtest 来查看pods，此时pods直接显示error了，通过查看pods里的日志发现，redis_port = os.environ.get("REDIS_MASTER_SR_SERVICE_PORT") 这行代码没有获取到REDIS_MASTER_SR_SERVICE_PORT的值，返回的是个None，所以在之后的redis初始化时就报错失败了，这也说明，在yyxtesxt的名称空间中的pod里是没有REDIS_MASTER_SR_SERVICE_PORT 这个环境变量的。

我们同样在default的namespace中也创建flask的pod和service，此时就可以正常的访问。

我们使用kubectl exec命令分别进入到两个namespace空间中的flask应用的pod中

在default的名称空间中

# env
...
FLASK_SERVICE_SERVICE_HOST=10.109.55.91
REDIS_MASTER_SR_SERVICE_PORT=6379
...

它包含有这两个环境变量，但是在yyxtest的pod中却没有这两个环境变量，这也就说明，原来的代码在非default空间(准确的说是和redis不在同一个空间中)是不能正常运行的。

使用dns来解析服务地址

除了可以使用环境变量来解析服务地址，用的更多的应该是使用dns来解析了，在创建redis的service时，Kubernetes 会创建一个相应的 DNS 条目，该条目的形式是 <service-name>.<namespace-name>.svc.cluster.local，这意味着如果容器只使用 <service-name>，它将被解析到本地命名空间的服务。比如在yaml文件中设置了

metadata:
  name: redis-master-sr

则会创建一个 redis-master-sr.default.svc.cluster.local的记录, 我们在default名称空间中的pod试一下

# ping redis-master-sr
PING redis-master-sr.default.svc.cluster.local (10.97.140.58) 56(84) bytes of data.

在yyxtest名称空间中的pod再试一下

# ping redis-master-sr
ping: redis-master-sr: Name or service not known

说明服务名只能中它所在的空间中(本例中的default)有dns记录，不在它的空间(本例中的yyxtest)中则不存在，但是我们注意中，在default空间中 redis-master-sr解析到了redis-master-sr.default.svc.cluster.local ,那么在非default空间中是否可以正常解析redis-master-sr.default.svc.cluster.local 这个名称呢？

在yyxtest的pod中执行

ping redis-master-sr.default.svc.cluster.local
PING redis-master-sr.default.svc.cluster.local (10.97.140.58) 56(84) bytes of data.

也是可以正常解析的，所以这时我们来修改一下python的代码

if os.environ.get("envname") == "k8s": # 说明是在k8s中
    REDIS_URL = "redis://{}:{}/{}".format("redis-master-sr.default.svc.cluster.local", 6379, 1)
else:
    REDIS_URL = "redis://{}:{}/{}".format('127.0.0.1', 6380, 1)

这时，我们就可以和redis不同的名称空间创建应用了。

参考文章

命名空间

2020年2月10日
分类于 k8s
需要 6 分钟阅读时间

kubernetes中pod间的通信

我们如果创建了一些pod，那么它们之间是怎么通信的呢？因为pod的ip地址是有可能变化的，这里我们主要讨论几个场景

同一网络下的不同pod间是怎么通信的？
同一个pod中不同的容器是怎么通信的？
不同的网络下不同的pod是怎么通信的？

2020年2月7日
分类于 k8s
需要 2 分钟阅读时间

kubernetes中的服务类型

当我们使用deployment或者RS创建了一些pod时，比如创建了一个nginx的pod，该pod中有三个replicas，此时，如果我们查看pod状态大概是这个样子的

2020年2月6日
分类于 javascript
需要 1 分钟阅读时间

javascript中的列表与对象遍历

工作中不是经常会写javascript，所以每次遇到写js代码的时候，都要上网上各种查，这里先总结一下，经常用的，之后再慢慢添加。

2020年2月5日
分类于 k8s
需要 4 分钟阅读时间

使用kubernetes搭建简单的应用

最近在看kubernetes的相关内空，参考《Kubernetes权威指南》第一章，搭建一个简单的应用，它里面使用的是RC，我直接使用RS来搭建。

项目架构

我们通过kubernetes来部署一个应用，这个应用后台是一个php网站，数据库使用redis，redis采用一主两从的部署方式，做到读写分离，写操作走redis主库，读操作走reids从库。并且启动多个应用副本，达到负载均衡，总体的应用架构如下图

创建redis-master 服务

老版本的kubernetes使用RC(ReplicationController)来创建pod，但是随着RS(ReplicationSet)的出现，已经取代了RC，所以我们直接采用RS来创建pod，创建redis-master.yaml文件

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: redis-master
  labels:
    name: redis-master
spec:
  replicas: 1
  selector:
    matchLabels:
      name: redis-master
  template:
    metadata:
      labels:
        name: redis-master
    spec:
      containers:
      - name: r-master
        image: kubeguide/redis-master
        ports: 
        - containerPort: 6379

yaml文件的编写很是麻烦，尤其是apiVersion: apps/v1 的选择，不同的apiVersion 对应下面的指令不同，写好的yaml文件可以在 https://kubeyaml.com/ 这个网站上校验一下。

通过 kubectl create -f redis-master.yaml 命令创建ReplicaSet, 使用 kubectl get pod 来查看pod的创建情况

# kubectl get pod
NAME                 READY   STATUS              RESTARTS   AGE
redis-master-n6wbp   0/1     ContainerCreating   0          11s

过一会就可以创建成功了，过程中通过status查看状态，有时会创建失败，失败的原因很多，遇到到在网上搜索一下吧。到时候再进行总结。

创建完pod以后，如果没有创建与之对应的service，则该pod也无法正常工作，接下来先创建这个service

apiVersion: v1
kind: Service
metadata:
  name: redis-master
  labels:
    name: redis-master
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    name: redis-master

使用 kubectl create -f redis-master-service.yaml 创建service，使用kubectl get services 查看service状态。

# kubectl create -f redis-master-service.yaml 
service/redis-master created
# kubectl get services
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes     ClusterIP   10.96.0.1        <none>        443/TCP    10d
redis-master   ClusterIP   10.109.162.197   <none>        6739/TCP   10s

看到redis-master使用了10.109.162.197 这个虚拟的ip，之后创建的pod可以使用这个ip和端口访问这个redis服务。

通过kubernetes创建的pod，虚拟IP是动态的，如果重启以后可能就会变了，所以其它的服务如redis-slave要同步的话是不能使用这个虚拟IP的，kubernetes通过环境变量来记录从服务到虚拟IP的关系。

创建redis-slave 服务

创建redis-slave.yaml文件

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: redis-slave
  labels:
    name: redis-slave
spec:
  replicas: 2 #创建两个副本
  selector:
    matchLabels:
      name: redis-slave
  template:
    metadata:
      labels:
        name: redis-slave
    spec:
      containers:
      - name: r-slave
        image: kubeguide/guestbook-redis-slave
        env: #添加环境变量
        - name: GET_HOSTS_FROM 
          value: env
        ports: 
        - containerPort: 6379

# kubectl create -f redis-slave.yaml 
replicaset.apps/redis-slave created
# kubectl get pod
NAME                 READY   STATUS              RESTARTS   AGE
redis-master-n6wbp   1/1     Running             0          37m
redis-slave-7zj5x    0/1     ContainerCreating   0          12s
redis-slave-hp2pt    0/1     ContainerCreating   0          12s

我们来查看一下redis-slave中的环境变量

# kubectl get pod
NAME                 READY   STATUS    RESTARTS   AGE
redis-master-n6wbp   1/1     Running   0          39m
redis-slave-7zj5x    1/1     Running   0          2m7s
redis-slave-hp2pt    1/1     Running   0          2m7s
root@kubernetes-master:/usr/local/docker/kubernetes/yaml/phpredis# kubectl exec redis-slave-7zj5x env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=redis-slave-7zj5x
GET_HOSTS_FROM=env
REDIS_MASTER_SERVICE_HOST=10.109.162.197
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT_6739_TCP=tcp://10.109.162.197:6739
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
REDIS_MASTER_PORT_6739_TCP_PORT=6739
REDIS_MASTER_PORT_6739_TCP_ADDR=10.109.162.197
KUBERNETES_SERVICE_PORT=443
REDIS_MASTER_PORT_6739_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
REDIS_MASTER_PORT=tcp://10.109.162.197:6739
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_PORT=tcp://10.96.0.1:443
REDIS_VERSION=3.0.3
REDIS_DOWNLOAD_URL=http://download.redis.io/releases/redis-3.0.3.tar.gz
REDIS_DOWNLOAD_SHA1=0e2d7707327986ae652df717059354b358b83358
HOME=/root

可以看到

REDIS_MASTER_SERVICE_HOST=10.109.162.197
REDIS_MASTER_SERVICE_PORT=6379

可以通过这两个环境变量来动态获取上面redis-master的IP与PORT

然后再创建与redis-slave对应的service服务

apiVersion: v1
kind: Service
metadata:
  name: redis-slave
  labels:
    name: redis-slave
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    name: redis-slave

通过kubectl get service 看到现在已经有三个服务了。

# kubectl get service
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes     ClusterIP   10.96.0.1        <none>        443/TCP    10d
redis-master   ClusterIP   10.109.162.197   <none>        6379/TCP   31m
redis-slave    ClusterIP   10.104.211.17    <none>        6379/TCP   18s

创建PHP应用

yaml文件如下

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: phpserver
  labels:
    name: phpserver
spec:
  replicas: 3
  selector:
    matchLabels:
      name: phpserver
  template:
    metadata:
      labels:
        name: phpserver
    spec:
      containers:
      - name: phpfront
        image: kubeguide/guestbook-php-frontend
        env:
        - name: GET_HOSTS_FROM
          value: env
        ports: 
        - containerPort: 80

创建pod，并查看pod状态

# kubectl create -f phpfront.yaml 
replicaset.apps/phpserver created
# kubectl get pods
NAME                 READY   STATUS              RESTARTS   AGE
phpserver-5bwzh      0/1     ContainerCreating   0          7s
phpserver-6v4dd      0/1     ContainerCreating   0          7s
phpserver-dbdmn      0/1     ContainerCreating   0          7s
redis-master-n6wbp   1/1     Running             0          53m
redis-slave-7zj5x    1/1     Running             0          16m
redis-slave-hp2pt    1/1     Running             0          16m

创建相应的service

apiVersion: v1
kind: Service
metadata:
  name: phpservice
  labels:
    name: phpservice
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30001
  selector:
    name: phpserver

运行创建命令并且查看services

# kubectl create -f phpservice.yaml 
service/phpservice created
# kubectl get services
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes     ClusterIP   10.96.0.1        <none>        443/TCP        10d
phpservice     NodePort    10.100.94.114    <none>        80:30001/TCP   9s
redis-master   ClusterIP   10.109.162.197   <none>        6739/TCP       45m
redis-slave    ClusterIP   10.104.211.17    <none>        6739/TCP       14m

注意到phpservice的type为NodePort，ports为80:30001/TCP，则这时可以通过主机的30001端口来访问该应用

访问 http://192.168.206.128:30001/ 来访问应用

应用更新

应用回滚

动态调整资源

可以手工的调整pod资源数量，如网站今天要做活动，预料到流量会增加，需要增加一些副本，则可以使用

kubectl scale rs rsname --replicas=4 命令来改变副本的数量，--replicas 值为要修改的量，当活动结束以后再手工的改回来。

当然对于这种纯手工的来修改副本数，还是不够智能，我们真正希望的是，当一个网站流量变大的时候可以自动的扩容，当网站的流量减少的时候，可以自动的缩容。

这个可以通过 HPA 来实现

一些问题

环境变量是怎么传递的
spec.type的类型

Kubernetes的三种外部访问方式

2020年2月4日
分类于 python
需要 2 分钟阅读时间

flask中跳转的同时设置cookie

最近在使用flask的时候，有一个比较麻烦的事情，在跳转网页的时候需要设置cookie，使用单独设置cookie与单独跳转都比较简单，

跳转网页

from flask import  redirect

@app.route("/redirect")
def redirecttest():
    return redirect("/test")

from flask import Flask,make_response

app = Flask(__name__)

@app.route("/set_cookie")
def set_cookie():
    #先创建响应对象
    resp = make_response("set cookie test")
    # 设置cookie  cookie名 cookie值 默认临时cookie浏览器关闭即失效
    # 通过max_age控制cookie有效期, 单位:秒
    resp.set_cookie("display","yangyanxing",max_age=3600) 
    return resp

可以看到，设置cookie的response 最后是通过return 回来的，但是上面的网页跳转则是通过redirect() 函数返回的，所以这两个没法同时的使用。

查看redirect() 的源码

def redirect(location, code=302, Response=None):    
    if Response is None:
        from .wrappers import Response

    display_location = escape(location)
    if isinstance(location, text_type):
        # Safe conversion is necessary here as we might redirect
        # to a broken URI scheme (for instance itms-services).
        from .urls import iri_to_uri

        location = iri_to_uri(location, safe_conversion=True)
    response = Response(
        '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n'
        "<title>Redirecting...</title>\n"
        "<h1>Redirecting...</h1>\n"
        "<p>You should be redirected automatically to target URL: "
        '<a href="%s">%s</a>.  If not click the link.'
        % (escape(location), display_location),
        code,
        mimetype="text/html",
    )
    response.headers["Location"] = location
    return response

可以看到，其实redirect函数也是通过构造一个response最后再将这个resonse return 出去，所以我们是否可以构造一个类似于redirect函数中的response对象，然后设置好status code是不是就可以了呢？

from flask import Flask,make_response,escape
app = Flask(__name__)

@app.route("/test")
def test():
    response = make_response(
        '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n'
        "<title>Redirecting...</title>\n"
        "<h1>Redirecting...</h1>\n"
        "<p>You should be redirected automatically to target URL: "
        '<a href="%s">%s</a>.  If not click the link.'
        % (escape("https://www.baidu.com"),
           escape("https://www.baidu.com")), 302)
    response.set_cookie('display',"yangyanxing")
    return respose

运行上面的代码，发现停留在/test 页面，显示上面的make_response的文字，并没有跳转，但是cookie中已经有display的cookie了，说明设置cookie成功了，跳转也成功了一半，只是它没有真正的跳转，还需要在网页上点击一下。

redirect函数中是通过 response.headers["Location"] = location 来设置的，在make_response 的返回响应对象中是通过response.location = 'xxxx' 来设置的

from flask import Flask,make_response,escape
app = Flask(__name__)

@app.route("/test")
def test():
    response = make_response(
        '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n'
        "<title>Redirecting...</title>\n"
        "<h1>Redirecting...</h1>\n"
        "<p>You should be redirected automatically to target URL: "
        '<a href="%s">%s</a>.  If not click the link.'
        % (escape("https://www.baidu.com"),
           escape("https://www.baidu.com")), 302)
    response.set_cookie('display',"yangyanxing")
    `response.location = escape("https://www.baidu.com")
    return respose

这时就可以正常的跳转了