1 Nginx优化之worker_processes,worker_connections

worker_processes与worker_connections 设置好合适大小，可以提示nginx处理性能，非常重要。

1
2
3
4
5
6
7
8
9
10
11
12

原作者的话：
As a general rule you need the only worker with large number of worker_connections, say 10,000 or 20,000.
However, if nginx does CPU-intensive work as SSL or gzipping and you have 2 or more CPU, then you may 
set worker_processes to be equal to CPU number.
Besides, if you serve many static files and the total size of the files is bigger than memory, then you may 
increase worker_processes to utilize a full disk bandwidth.
Igor Sysoev

翻译：
一般一个进程足够了，你可以把连接数设得很大。（worker_processes: 1，worker_connections: 10,000）
如果有SSL、gzip这些比较消耗CPU的工作，而且是多核CPU的话，可以设为和CPU的数量一样。(worker_processes: CPU核心数)
或者要处理很多很多的小文件，而且文件总大小比内存大很多的时候，也可以把进程数增加，以充分利用IO带宽（主要似乎是IO操作有block）

worker_processes，工作进程数

1. 默认：worker_processes: 1
2. 调大：worker_processes: CPU核心数，(双核4线程，可以设置为4)

worker_connections，单个工作进程可以允许同时建立外部连接的数量
数字越大，能同时处理的连接越多

1. 默认：worker_connections: 1024
2. 调大：worker_connections: 100000，（调大到10万连接）

worker_connections解析

1. connections不是随便设置的，而是与两个指标有重要关联，一是内存，二是操作系统级别的“进程最大可打开文件数”。
2. 内存：每个连接数分别对应一个read_event、一个write_event事件，一个连接数大概占用232字节，2个事件总占用96字节，那么一个连接总共占用328字节，通过数学公式可以算出100000个连接数大概会占用 31M = 100000 * 328 / 1024 / 1024，当然这只是nginx启动时，connections连接数所占用的nginx。
3. 进程最大可打开文件数：进程最大可打开文件数受限于操作系统，可通过 ulimit -n 命令查询，以前是1024，现在是65535,
   nginx提供了worker_rlimit_nofile指令，这是除了ulimit的一种设置可用的描述符的方式。 该指令与使用ulimit对用户的设置是同样的效果。此指令的值将覆盖ulimit的值，如：worker_rlimit_nofile 20960;
   设置ulimits：ulimit -SHn 65535

1
2
3
4
5
6

worker_processes 2; 
worker_rlimit_nofile 65535;
#pid logs/nginx.pid; 
events { 
   worker_connections 65535; 
}

[TOC]

0 参考

• https://www.cnblogs.com/wdliu/p/8312543.html

1 settings.xml详解

1.1 声明规范

1
2
3

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

1.2 localRepository

1
2

<!-- 本地仓库的路径。默认值为 -->
<localRepository>/opt/repository</localRepository>

1.3 interactiveMode

1
2

<!--Maven是否需要和用户交互以获得输入。如果Maven需要和用户交互以获得输入，则设置成true，反之则应为false。默认为true。-->
<interactiveMode>true</interactiveMode>

1.4 usePluginRegistry

1
2

<!--Maven是否需要使用plugin-registry.xml文件来管理插件版本。如果需要让Maven使用文件来管理插件版本，则设为true。默认为false。-->
<usePluginRegistry>false</usePluginRegistry>

1.5 offline

1
2

<!--表示Maven是否需要在离线模式下运行。如果构建系统需要在离线模式下运行，则为true，默认为false。当由于网络设置原因或者安全因素，构建服务器不能连接远程仓库的时候，该配置就十分有用。 -->
<offline>false</offline>

[toc]

0 参考

• https://blog.csdn.net/weixin_38569499/article/details/91456988

1 maven项目目录结构

pom文件定于了一个maven项目的maven配置，一般pom文件的放在项目或者模块的根目录下。

maven的遵循约定大于配置，约定了如下的目录结构：

[TOC]

0 参考

• https://kubernetes.io/docs/concepts/storage/storage-classes/
• http://tingcream.com/blogArticle/detail/28acd1174a49432ba733cf6bbfa077a5

1 简介

Kubernetes集群管理员通过提供不同的存储类，可以满足用户不同的服务质量级别、备份策略和任意策略要求的存储需求。动态存储卷供应使用StorageClass进行实现，其允许存储卷按需被创建。如果没有动态存储供应，Kubernetes集群的管理员将不得不通过手工的方式类创建新的存储卷。通过动态存储卷，Kubernetes将能够按照用户的需要，自动创建其需要的存储。

比如，我们可能会在kubernetes集群中安装一些带持久化数据功能的服务，例如redis、mysql、mq、es等。因此，当有这类需求时，我们必须给整个集群给定一个特定的存储方案。本章我们是NFS的网络存储方案

[TOC]

0 转载

• http://www.ruanyifeng.com/blog/2016/04/cors.html

1 简介

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

[TOC]

0 参考文章

• https://www.jianshu.com/p/b06944c92228
• http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

1 什么是OAuth

官网这样说…

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

• OAuth 即 Open standard for Authorization
• OAuth就是一个网络开放协议。为保证用户资源的安全授权提供了简易的标准
• 在知乎上看到了一个比较直观的比喻，有助于初学者理解。知乎话题链接

2 OAuth历史版本

2007-12 OAuth 1.0发布并迅速成为工业标准。

2008-06 OAuth 1.0 Revision A发布，这是个稍作修改的修订版本，主要修正一个安全方面的漏洞。

2010-04，OAuth 1.0 协议发布为 RFC 5849

2011-05 OAuth 2.0 草案发布

2012-10 OAuth 2.0 协议发布为 RFC 6749

[TOC]

参考

• https://blog.csdn.net/qianghaohao/article/details/99354304
• https://github.com/kubernetes/ingress-nginx
• https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md
• https://kubernetes.github.io/ingress-nginx/

1 k8s 对外暴露服务的方法

向 k8s 集群外部暴露服务的方式有三种： nodePort，LoadBalancer 和本文要介绍的 Ingress。每种方式都有各自的优缺点，nodePort 方式在服务变多的情况下会导致节点要开的端口越来越多，不好管理。而 LoadBalancer 更适合结合云提供商的 LB 来使用，但是在 LB 越来越多的情况下对成本的花费也是不可小觑。Ingress 是 k8s 官方提供的用于对外暴露服务的方式，也是在生产环境用的比较多的方式，一般在云环境下是 LB + Ingress Ctroller 方式对外提供服务，这样就可以在一个 LB 的情况下根据域名路由到对应后端的 Service，有点类似于 Nginx 反向代理，只不过在 k8s 集群中，这个反向代理是集群外部流量的统一入口。

2 Ingress 及 Ingress Controller 简介

Ingress 是 k8s 资源对象，用于对外暴露服务，该资源对象定义了不同主机名（域名）及 URL 和对应后端 Service（k8s Service）的绑定，根据不同的路径路由 http 和 https 流量。而 Ingress Contoller 是一个 pod 服务，封装了一个 web 前端负载均衡器，同时在其基础上实现了动态感知 Ingress 并根据 Ingress 的定义动态生成 前端 web 负载均衡器的配置文件，比如 Nginx Ingress Controller 本质上就是一个 Nginx，只不过它能根据 Ingress 资源的定义动态生成 Nginx 的配置文件，然后动态 Reload。个人觉得 Ingress Controller 的重大作用是将前端负载均衡器和 Kubernetes 完美地结合了起来，一方面在云、容器平台下方便配置的管理，另一方面实现了集群统一的流量入口，而不是像 nodePort 那样给集群打多个孔。

所以，总的来说要使用 Ingress，得先部署 Ingress Controller 实体（相当于前端 Nginx），然后再创建 Ingress （相当于 Nginx 配置的 k8s 资源体现），Ingress Controller 部署好后会动态检测 Ingress 的创建情况生成相应配置。Ingress Controller 的实现有很多种：有基于 Nginx 的，也有基于 HAProxy的，还有基于 OpenResty 的 Kong Ingress Controller 等，更多 Controller 见：https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/，本文使用基于 Nginx 的 Ingress Controller：ingress-nginx。

[TOC]

参考

• https://www.cnblogs.com/yyds/p/6901864.html
• https://www.cnblogs.com/yuanyongqiang/p/11913812.html
• https://www.cnblogs.com/nancyzhu/p/8551506.html

日志相关概念

日志是一种可以追踪某些软件运行时所发生事件的方法。软件开发人员可以向他们的代码中调用日志记录相关的方法来表明发生了某些事情。一个事件可以用一个可包含可选变量数据的消息来描述。此外，事件也有重要性的概念，这个重要性也可以被称为严重性级别（level）。

日志的作用

通过log的分析，可以方便用户了解系统或软件、应用的运行情况；如果你的应用log足够丰富，也可以分析以往用户的操作行为、类型喜好、地域分布或其他更多信息；如果一个应用的log同时也分了多个级别，那么可以很轻易地分析得到该应用的健康状况，及时发现问题并快速定位、解决问题，补救损失。
简单来讲就是，我们通过记录和分析日志可以了解一个系统或软件程序运行情况是否正常，也可以在应用程序出现故障时快速定位问题。比如，做运维的同学，在接收到报警或各种问题反馈后，进行问题排查时通常都会先去看各种日志，大部分问题都可以在日志中找到答案。再比如，做开发的同学，可以通过IDE控制台上输出的各种日志进行程序调试。对于运维老司机或者有经验的开发人员，可以快速的通过日志定位到问题的根源。可见，日志的重要性不可小觑。日志的作用可以简单总结为以下3点：

• 程序调试
• 了解软件程序运行情况，是否正常
• 软件程序运行故障分析与问题定位

如果应用的日志信息足够详细和丰富，还可以用来做用户行为分析，如：分析用户的操作行为、类型洗好、地域分布以及其它更多的信息，由此可以实现改进业务、提高商业利益。

日志的等级

我们先来思考下下面的两个问题：

• 作为开发人员，在开发一个应用程序时需要什么日志信息？在应用程序正式上线后需要什么日志信息？
• 作为应用运维人员，在部署开发环境时需要什么日志信息？在部署生产环境时需要什么日志信息？

在软件开发阶段或部署开发环境时，为了尽可能详细的查看应用程序的运行状态来保证上线后的稳定性，我们可能需要把该应用程序所有的运行日志全部记录下来进行分析，这是非常耗费机器性能的。当应用程序正式发布或在生产环境部署应用程序时，我们通常只需要记录应用程序的异常信息、错误信息等，这样既可以减小服务器的I/O压力，也可以避免我们在排查故障时被淹没在日志的海洋里。那么，怎样才能在不改动应用程序代码的情况下实现在不同的环境记录不同详细程度的日志呢？这就是日志等级的作用了，我们通过配置文件指定我们需要的日志等级就可以了。

不同的应用程序所定义的日志等级可能会有所差别，分的详细点的会包含以下几个等级：

• DEBUG
• INFO
• NOTICE
• WARNING
• ERROR
• CRITICAL
• ALERT
• EMERGENCY

日志字段信息与日志格式

本节开始问题提到过，一条日志信息对应的是一个事件的发生，而一个事件通常需要包括以下几个内容：

• 事件发生时间
• 事件发生位置
• 事件的严重程度–日志级别
• 事件内容

上面这些都是一条日志记录中可能包含的字段信息，当然还可以包括一些其他信息，如进程ID、进程名称、线程ID、线程名称等。日志格式就是用来定义一条日志记录中包含那些字段的，且日志格式通常都是可以自定义的。

说明：

输出一条日志时，日志内容和日志级别是需要开发人员明确指定的。对于而其它字段信息，只需要是否显示在日志中就可以了。

日志功能的实现

几乎所有开发语言都会内置日志相关功能，或者会有比较优秀的第三方库来提供日志操作功能，比如：log4j，log4php等。它们功能强大、使用简单。Python自身也提供了一个用于记录日志的标准库模块–logging。

logging模块简介

logging模块定义的函数和类为应用程序和库的开发实现了一个灵活的事件日志系统。logging模块是Python的一个标准库模块，由标准库模块提供日志记录API的关键好处是所有Python模块都可以使用这个日志记录功能。所以，你的应用日志可以将你自己的日志信息与来自第三方模块的信息整合起来。

[TOC]

参考

• https://itopic.org/python-time-module.html
• https://www.liaoxuefeng.com/wiki/1016959663602400/1017648783851616
• https://blog.csdn.net/watfe/article/details/84943732

python变量下划线小结

下划线类型

在python模块或类里面，一些变量的命名上有时会有下划线，表示了变量的特性和被访问限制

什么是__name__

一个python脚本，比如 hello.py，就是一个模块，这个模块的名字叫hello；一个模块既可以被其它模块导入（importable），也可以被直接执行（executable）.

__name__是python的内置变量。如果一个模块是被直接执行的话，那么这个模块的__name__变量的值就是 __main__值；而如果这个模块是被其它模块导入的，那么这个模块的__name__变量的值就是模块的名字。