今天继续复习了一下12Factor方法论，更深一步了解其精华所在：
1.微服务。标准：子系统以及其代码，可以独立部署。
2.依赖声明与环境隔离。很多研发很不讲究“代码卫生”，这点作为SRE非常bs。
3.配置存储在Unix环境变量中。这点在现实中实现起来有好有坏，研发人员对配置变量的管理和规划需要提前做出存储计划。
4.外部db、cache以及其他子系统的依赖声明成资源。需要研发人员有整体全局意识，不能只顾某个算法的实现、某个串的序列号结果。而不顾全大局。
5.严格区分打包和运行环境。
6.应用作为无状态的进程运行。sticky session必须被避免哦
7.通过绑定端口对外提供服务。
8.通过多进程模型进行扩容。
9.快速启动，优雅关闭。最小化短时间启动，以前有个恶劣的程序员写了个程序，每次启动要30-45分钟左右，简直是灾难。
10.开发、测试、部署环境尽量接近。
11.log当事件流集中处理。
12.一次性的系统管理任务。
为什么需要http2背景
从 2015 年 5 月 14 日 HTTP/2 协议正式版的发布到现在已经快有一年了，越来越多的网站部署了 HTTP2，HTTP2 的广泛应用带来了更好的浏览体验，只要是 Modern 浏览器都支持，所以部署 HTTP2 并不会带来太多困扰。
虽然 h2 有 h2c （HTTP/2 Cleartext） 可以通过非加密通道传输，但是支持的浏览器初期还是比较少的，所以目前部署 h2 还是需要走加密的，不过由于 Let’s Encrypt 大力推行免费证书和证书的廉价化，部署 h2 的成本并不高。
HTTP 2.0即超文本传输协议 2.0，是下一代HTTP协议。是由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。
HTTP/2 协议是从 SPDY 演变而来，SPDY 已经完成了使命并很快就会退出历史舞台（例如 Chrome 将在「2016 年初结束对 SPDY 的支持」；Nginx、Apache 也已经全面支持 HTTP/2 ，并也不再支持 SPDY）。
一般的大家把 HTTP2 简称为 h2，尽管有些朋友可能不怎么愿意，但是这个简称已经默认化了，特别是体现在浏览器对 HTTP2 都是这个简写的。
配置
普通的 HTTPS 网站浏览会比 HTTP 网站稍微慢一些，因为需要处理加密任务，而配置了 h2 的 HTTPS，在低延时的情况下速度会比 HTTP 更快更稳定！
现在电信劫持事件频发，网站部署了 HTTPS 加密后可以杜绝大部分劫持，但不是完全。像电子商务行业对 HTTPS 加密可是标配啊，因此部署 h2 更是势在必行。 继续阅读
在一个后台系统中，流量控制属于基础组件的功能，其实，在很久之前的通讯时代，流量控制就已经非常成熟了，在路由器交换机上面几乎都有全面的流量控制的解决方案，像QoS这类流量整形的方案，都已经是在网络模型的各个层来进行流量的控制和分发了，可以按照通道，按照端口，IP，MAC，业务类型等各个维度对流量进行整形和控制，比如让语音类的这种高优先级的流量优先通过，而视频聊天这种丢了几帧数据其实没什么影响的低优先级流量慢点通过。对于流量控制，在中后台系统中，一般分成两个类型吧，一种是对连接数进行控制，保证一个机器有可控的连接数，一种是对真实流量的控制，保证机器能通过的流量有多少。流量控制和缓存一样，实际上是对后端的服务起到一个保护的作用，不至于把后端的服务击穿，不同的地方在于缓存保护的主要是读操作，如果用缓存来保护写操作的话，也是一个异步的过程，像下面这个图一样。 继续阅读
什么是 DNS
DNS（Domain Name System，域名系统），DNS 服务用于在网络请求时，将域名转为 IP 地址。能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。
传统的基于 UDP 协议的公共 DNS 服务极易发生 DNS 劫持，从而造成安全问题。 继续阅读
Ansible常用模块
Ansible通过模块的方式来完成一些远程的管理工作。可以通过ansible-doc -l查看所有模块，可以使用ansible-doc -s module来查看某个模块的参数，也可以使用ansible-doc help module来查看该模块更详细的信息。下面列出一些常用的模块：
1. setup
可以用来查看远程主机的一些基本信息：
ansible -i /etc/ansible/hosts test -m setup
就像我们在自己电脑上搭建了一个论坛的网站，应用程序（例如Apache服务器）、数据库等都部署在我们自己的电脑上的。就可以正常运行了。
我们的论坛越来越受欢迎，用户越来越多，论坛也十分越活。但是面临的问题是数据库中的信息越来越多，存储不够了。这个时候我们又多弄了几台服务器，应用程序（Apache服务器）、数据库和保存用户上传的文件（图片）单独部署在不同的服务器上。
应用服务器处理大量的业务逻辑，所以需要更好的CPU
数据库服务器需要完成数据的快速查询，所以需要更大的硬盘和内存
文件服务器保存用户上传的图片等文件，所以需要更大的硬盘
我们的论坛用户继续快速增涨，我们发现访问速度越来越慢，原因就是很多请求都要访问数据库（例如，读取用户的个人信息，打个不恰当的比喻，每次进入一个话题，该话题中的每一个发言用户的信息都要从数据库中读取）。这个时候如果我们能缓存这些用户信息，每次从缓存中读取，这样对数据库的压力会大大降低，并且读取的性能也提升了很多。
使用缓存后，又出现问题了，在论坛使用高峰的时候，单一应用服务器处理请求连接有限，这个时候就需要部署应用服务器集群，然后在使用一个负载均衡服务器（例如Nginx,apache Server)。
用户继续增加，使用缓存后，虽然大部分读的操作都不会直接访问数据库，但是还是有一些读操作（缓存未命中，缓存过期）和全部的写操作还是必须操作数据库。当用户达到一定规模，数据库又成了系统的性能瓶颈。
在原来单一数据库的模式上，设置一个主数据库和从数据库，写操作的时候写入主数据库，然后从主数据库同步到从数据库中。读操作就在从数据库中读。当然我们需要一个数据访问的模块来处理这些逻辑
论坛用户反应，打开你们的论坛速度太慢了，再不改善我就不用了。
原因也很简单，一个访问请求中，也许存在很多静态资源（CSS，图片）等，又或者用户的使用的联通，我们的服务器在电信。适应反向代理和CDN技术可以大大改善用户请求的响应速度
虽然数据库进行读写分离以后，但是在我们论坛疯狂增涨下，任何强大的单一服务器的性能都是有限的，只有使用分布式系统，才能在业务不断增涨进行横向扩展。这个是我们最后手段了，使用之前应该先考虑能否根据业务不同来拆分数据库。例如我们论坛的包括了不同主题（汽车、房子、以及你懂的话题），如果按照这些主题来区分数据库，也是好的选择。（注意这个虽然也是要使用多个数据库，但和分布式数据库的概念是有很大区别的）
论坛中，要搜索一些帖子，如果每次进行数据库查询，在数据量十分大的情况，显然是不可取的。还有就是对数据存储的要求，需要使用搜索引擎（例如lucene）。
NoSql主要是对一些特殊需求的数据进行存储，例如配置信息可以放redis中（也算是缓存），日志信息可以存储在Hbase上等等。
为了以后以后的发展，我们的业务需要扩展，我们需要增加即时通讯的业务（类似微信），知识问答（类似知乎）。但是这些业务是分开开发的，如果和原有的论坛业务耦合在一起，在代码发布的时候，就会十分麻烦。这个时候，根据不同的业务，分别进行部署和发布。
虽然按照业务进行拆分以后，虽然不同业务之间的管理隔离开来，但是问题又出现了，但我们部署了上万台服务器的时候，每个服务器都保持有与数据库的连接，这样会导致数据集的连接资源不够。而且还有个问题就是对一些基础功能每个业务之间有重复开发的问题。
所以，我们把一些基础业务功能提取出来，做成基础服务独立部署（登录服务、用户信息管理，日志功能等）。这样上层只用关系自己的业务逻辑，调用底层统一的基础服务。
在早期的计算机领域，限流技术(time limiting)被用作控制网络接口收发通信数据的速率。 可以用来优化性能，减少延迟和提高带宽等。 现在在互联网领域，也借鉴了这个概念， 用来为服务控制请求的速率， 如果双十一的限流， 12306的抢票等。 即使在细粒度的软件架构中，也有类似的概念。
两种常用算法
令牌桶(Token Bucket)和漏桶(leaky bucket)是 最常用的两种限流的算法。
漏桶算法
它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。 漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 用说人话的讲：
漏桶算法思路很简单，水（数据或者请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。
在某些情况下，漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使某一个单独的流突发到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法可以结合起来为网络流量提供更大的控制。
令牌桶算法
令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。 令牌桶的另外一个好处是可以方便的改变速度。 一旦需要提高速率，则按需提高放入桶中的令牌的速率。 一般会定时(比如100毫秒)往桶中增加一定数量的令牌， 有些变种算法则实时的计算应该增加的令牌的数量, 比如华为的专利”采用令牌漏桶进行报文限流的方法“(CN 1536815 A),提供了一种动态计算可用令牌数的方法， 相比其它定时增加令牌的方法， 它只在收到一个报文后，计算该报文与前一报文到来的时间间隔内向令牌漏桶内注入的令牌数， 并计算判断桶内的令牌数是否满足传送该报文的要求。
从最终用户访问安全的角度看，设想有人想暴力碰撞网站的用户密码；或者有人攻击某个很耗费资源的接口；或者有人想从某个接口大量抓取数据。大部分人都知道应该增加 Rate limiting，做请求频率限制。从安全角度，这个可能也是大部分能想到，但不一定去做的薄弱环节。
从整个架构的稳定性角度看，一般 SOA 架构的每个接口的有限资源的情况下，所能提供的单位时间服务能力是有限的。假如超过服务能力，一般会造成整个接口服务停顿，或者应用 Crash，或者带来连锁反应，将延迟传递给服务调用方造成整个系统的服务能力丧失。有必要在服务能力超限的情况下 Fail Fast。
另外，根据排队论，由于 API 接口服务具有延迟随着请求量提升迅速提升的特点，为了保证 SLA 的低延迟，需要控制单位时间的请求量。这也是 Little’s law 所说的。
还有，公开 API 接口服务，Rate limiting 应该是一个必备的功能，否则公开的接口不知道哪一天就会被服务调用方有意无意的打垮。
所以，提供资源能够支撑的服务，将过载请求快速抛弃对整个系统架构的稳定性非常重要。这就要求在应用层实现 Rate limiting 限制。
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /search/ {
limit_req zone=one burst=5;
}
详细参见： ngx_http_limit_req_module
详细参见： Haproxy Rate limit 模块
RateLimiters是令牌桶和漏桶在.NET 中实现。这些策略可用于速率限制请求不同的网站中，后端或 API 调用等场景。
ASP.NET Web API rate limiter for IIS and Owin hosting
这个在 Redis 官方文档有非常详细的实现。一般适用于所有类型的应用，比如 PHP、Python 等等。Redis 的实现方式可以支持分布式服务的访问频率的集中控制。Redis 的频率限制实现方式还适用于在应用中无法状态保存状态的场景。
网上有众多关于这方面的文章，这里列出了本文参考的一些文档。
nginx支持在线播放mp4
1.安装nginx时加参数
–prefix=/opt/nginx –with-http_gzip_static_module –with-http_flv_module –with-http_mp4_module
2.匹配处理
location ~* .*.mp4$ {
mp4;
}
3.mime类型增加
video/mp4 mp4;
chrome就直接支持访问mp4的url直接播放了。
加速 ubuntu启动
sed -i ‘s/20\|40\|59/1/g’ /etc/init/failsafe.conf