樱桃沟夹事

Timo's life

发表于 更新于 分类于 本文字数： 769 阅读时长 ≈ 1 分钟

上一篇主要就是css的一些常用的指定方式。但是看着就是很简单的一种语言，甚至都不需要缩写。

但是看了书发现还是有一些高级用法的。

根据屏幕大小来指定使用哪个css，这个不就可以用在定义手机端样式和pc端样式啊。

1
<link href="lounge-mobile.css" rel="sytlesheet" media="screen and (max-device-width: 480px)">

这里就是指定了这个css只有在有屏幕的设备同时设备屏幕宽度不能超过480像素。

当然我们可以不在link标记内使用，原生css里也可以指定

阅读全文 »

发表于 更新于 分类于 本文字数： 3.2k 阅读时长 ≈ 3 分钟 
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
body {
  background-color: #b5a789;
  font-family:      Georgia, "Times New Roman", Times, serif;
  font-size:        small;
  margin:           0px;
}

/*
	height messes up the headers in the blog in the articles
	it's only appropriate for the top header.
	add a class (new with blog)
	Affects the 3 #header rules for the main header below
	In HTML: add class="top" to main header in index.html and blog.html
*/

header.top {
  background-color: #675c47;
  margin: 10px 10px 0px 10px;
  height:           108px;
}

header.top img#headerSlogan {
	float: right;
}


div#tableContainer {
	display: table;
	border-spacing: 10px;
}

div#tableRow {
	display: table-row;
}

section#drinks {
    display: table-cell;
    background-color: #efe5d0;
    width: 20%;
    padding: 15px;
    vertical-align: top;
}

/* added section#blog for blog */
section#main, section#blog {
  display: table-cell;
  background:       #efe5d0 url(images/background.gif) top left;
  font-size:        105%;
  padding:          15px;
  vertical-align: top;
}

aside {
  display: table-cell;
  background:       #efe5d0 url(images/background.gif) bottom right;
  font-size:        105%;
  padding:          15px;
  vertical-align: top;
}

footer {
  background-color: #675c47;
  color:            #efe5d0;
  text-align:       center;
  padding:          15px;
  margin: 0px 10px 10px 10px;
  font-size:        90%;
}

h1 {
  font-size:        120%;
  color:            #954b4b;
}

h2 { font-size: 110%; }

.slogan { color: #954b4b; }

.beanheading {
  text-align:       center;
  line-height:      1.8em;
}

a:link {
  color:            #b76666;
  text-decoration:  none;
  border-bottom:    thin dotted #b76666;
}
a:visited {
  color:            #675c47;
  text-decoration:  none;
  border-bottom:    thin dotted #675c47;
}


nav {
    background-color: #efe5d0;
	margin: 10px 10px 0px 10px;
}
nav ul {
	margin: 0px;
	list-style-type: none;
	padding: 5px 0px 5px 0px;
}
nav ul li {
	display: inline;
	padding: 5px 10px 5px 10px;
}
nav ul li a:link, nav ul li a:visited {
	color: #954b4b;
	border-bottom: none;
	font-weight: bold;

/*
	text-shadow: 1px 1px 3px #e2c2c2;
	text-transform: uppercase;
*/
}
nav ul li.selected {
	background-color: #c8b99c;
}

上面这个是「Head first html与css」第二版里第12章的一个css文件实例。第一次看还是有点头大，其实我们只需要理解这些符号的含义就行。

同时要特别注意大小写，这个是对大小写敏感的。

因为css作用域就是整个html文件，所以上面这些符号其实描述的就是html的标签。

  1. body 这个其实就是定义了这个html里<body>………………</body>范围内的所有的定义，同理什么p nav a 这些都是这样的, 只要是html里元素都直接用，不需要加任何的。
  2. #headerSlogan 这种其实定义了 某个标签内id为headSlogan 里的内容。
  3. .top 这种定义了 某个标签内class为top 里的内容。
  4. nav ul li 这种是定义了nav标签内ul标签内li这个标签的内容，是上下级关系。
  5. a,p 这种就是定义了a标签和p这个标签内的内容，两者是同等关系，不存在上下级。
  6. a:link 这种就是定义了标签为a下的伪类link的内容。

这里的伪类是什么意思？都包含哪些呢？查了一下 https://zhuanlan.zhihu.com/p/19743782 这里说的还是很明白的，比我自己总结的要好。

阅读全文 »

发表于 更新于 分类于 本文字数： 5.4k 阅读时长 ≈ 5 分钟

docker的文件系统演进了很多代了。
从aufs，devicemapper，overlay，overlay2不一而足。

但是分层的思想是一致的。

aufs本质上一种Union File
System。就是把多个目录合并到一起。但是默认只有参数第一个的第一个目录是可读写的，当然你可以都设置为可读写。

耗子叔写了一篇很好的说明aufs的文章。
https://coolshell.cn/articles/17061.html

但是aufs没有被接纳进Linux主干分支，据说Linus觉得Junjiro Okajima（岡島順治郎）的代码实在写的太烂了。
https://en.wikipedia.org/wiki/Aufs 居然连wiki里都写了。

阅读全文 »

发表于 更新于 分类于 本文字数： 2.1k 阅读时长 ≈ 2 分钟

本文参考自：
https://clsn.io/clsn/lx1473.html
「Docker进阶与实战」– 华为Docker实践小组 著

docker实际上是对cgroup，namespace，lxc的封装。仅仅是进程本身跟其他进程的隔离，完全是通过软件层面来实现的。

因为仅仅是多开个进程，因此一个服务器就可以开几十个上百个docker容器都没有问题，无非就是多点进程，如果都不是费IO的，那应该都可以。

而且docker可以做到秒级的启动。毕竟就跟平时启动进程没多大区别。

那这里好像都是docker的优势，那缺点必然伴随而来。那就是docker并不是完整的操作系统，不能像虚拟机那样做到对资源的彻底隔离。

那再说下虚拟化，老人肯定知道以前要安装虚拟机是不是还要查下自己CPU的指令集是否支持，特别是2005年前后的时候。 Intel CPU 的 vmx 或者 AMD CPU 的 svm

阅读全文 »

发表于 更新于 分类于 本文字数： 2.2k 阅读时长 ≈ 2 分钟

国内公有云第一家商用VPC的是青云，可惜是给大家趟了水。

国外的aws从2009年就开始了。但是那时候大宋还没法跟上。阿里云早期都是拿着经典网络搞云计算。当然问题也都产生了很多问题。最著名的就是陈浩的那篇文章了。
https://weibo.com/ttarticle/p/show?id=2309404079841686247162

知乎上也有很多关于这个的讨论
https://www.zhihu.com/question/56524172

那我们现在继续说下公有云的基础，那就是如何进行资源隔离，这里就涉及到网络，cpu，内存，磁盘io这些。
这里的隔离千万别就只想到cgroup和namespace这些。

个人觉得这个主要是3个基础：网络基础(vxlan)，虚拟化, 存储。

网络基础这里主要是参考了：
https://zhuanlan.zhihu.com/p/36165475
https://zhuanlan.zhihu.com/p/33658624

阅读全文 »

发表于 更新于 分类于 本文字数： 527 阅读时长 ≈ 1 分钟

菊花厂有个规定是所有服务都不能用默认端口，什么zk，redis都有这种要求。公开说法就是安全。

但是我是不太认同这种观点，而且是突增烦恼。你要说防止扫描出来，那难道换了个端口就扫描不出来了吗？

说白了端口号就是你的门牌号，大家默认都这样遵守。比如你80就是http，你当然也可以改成81端口，但是那样你所有http请求就要加上对应的端口号。

那zk的2181和redis的6379也是如此啊。你要做好的是把zk和redis服务本身的安全性做好，该加密码加密码，该用ip白名单用ip白名单。但是你把门牌号改了，本身安全不做好，不也一样该出事就出事。

于是就找菊花厂的伪军去协调沟通下，哪知伪军连问都不敢问。原因无非就是怕砸了自己的饭碗，给皇军添麻烦，最后万一惹恼皇军就砸了自己的饭碗了。

伪军讲话，皇军才是最终的裁判。伪军还说皇军人太多了，太多了就得全部走流程走制度。

阅读全文 »

发表于 更新于 分类于 本文字数： 685 阅读时长 ≈ 1 分钟

他司由于费用的原因，从腾讯企业邮箱切换到了阿里邮箱。
切换过程就不说了，人都有迁移后台。说说使用的感受吧。

腾讯邮箱是支持微信接收和登录，也可以直接在小程序里收发。这个阿里的先天劣势。

主要是一些web感受。

腾讯邮箱只有一个页面，而阿里邮箱却人为的分为了很多tab。对于我这种vim党实在是麻烦。

单击邮件，只用了屏幕30%的空间去显示，那种小邮件还行。

然后如果是双击那封邮件，是在邮箱内部新的tab页面去显示，但是默认显示的是缩略，我要看全文还得点击一下，也不知道是哪个脑残设计的，为了省流量也不要这样啊。

阅读全文 »

发表于 更新于 分类于 本文字数： 4.8k 阅读时长 ≈ 4 分钟

本文主要翻译自 https://mesosphere.github.io/marathon/docs/constraints.html

我司从2015年就开始使用Mesos+marathon的集群框架，应该说这套系统还是相当的成熟，至于后面跟K8s比，那得看在什么层面上了。至少稳定性比K8s强太多了。

由于我们现有的集群都是在云上面的。这在同一城市会分布很多的机房，从A一直到H都有。因此当我们进行部署分布式任务的时候最好就分布到A到H之间的3个机房。

这样的好处就是保证了一个机房宕掉而不影响全局。而从mesos 1.5版本开始就已经支持domain,region这样的参数了。 具体可以参考http://mesos.apache.org/documentation/latest/fault-domains/

所以这个文档其实是要基于mesos1.5之后说的。现在mesos已经到1.9.0了，但是生产环境建议还是1.7.2

好了，开始了。特别注意CLUSTER, LIKE这样的操作符都是大写，不能小写。

阅读全文 »

发表于 更新于 分类于 本文字数： 1.5k 阅读时长 ≈ 1 分钟

问题是我们需要做一个统一的限流层，而这个限流层肯定不是单机可以完成，必定是一个多级多机的集群来处理。
因此肯定会涉及到共享存储的事情。我们一般都使用redis，但是其实redis涉及到单核上限的问题，其实更好的应该还是memcache，很多公司都改良过memecache也都开源出来的。

限流性能考量

现有的开源方案

网上有一堆关于nginx限流的文章。

主要看的就是
https://www.upyun.com/opentalk/417.html
https://blog.cloudflare.com/counting-things-a-lot-of-different-things/
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

用到的算法基本就两种，漏桶算法和令牌桶算法。

阅读全文 »

发表于 更新于 分类于 本文字数： 1.7k 阅读时长 ≈ 2 分钟

就说说从技术角度来考虑线上SLA的主要问题。

几个大部分就是： 发布， 手动操作， 流量， 安全

首先还是要统计下这4个在SLA事故里的占比。

发布

发布和更新在一般意义上是影响线上sla最大部分。

回归测试

阅读全文 »
0%