分类目录归档:article

ASP.NET Core 性能对比评测(ASP.NET,Python,Java,NodeJS)

测试结果的汇总统计:

编号 对比方 系统环境 宿主环境 测试结果(QPS)
1 ASP.NET Core vs ASP.NET Core Windows Kestrel vs IIS 45.6k vs 15.2k
2 ASP.NET Core vs ASP.NET Windows IIS vs IIS 15.2k vs 18.2k
3 ASP.NET Core vs ASP.NET Windows Kestrel vs IIS 45.6k vs 18.2k
4 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 26.7k vs 1.57k
5 ASP.NET Core vs Java Servlet Linux Kestrel vs Tomcat 26.7k vs 18.3k
6-1 ASP.NET Core vs NodeJS Express Linux Kestrel vs self host 26.7k vs 15.6k
6-2 ASP.NET Core vs NodeJS Koa Linux Kestrel vs self host 26.7k vs 17.5k

作为微软的下一代 ASP.NET 框架,ASP.NET Core没有让我们失望,通过本次测试,我们大概对ASP.NET Core的性能心里有底了。一个圈子的良好发展需要社区的共同参与,也希望大家共同为.NET Core社区贡献自己的力量,同时也希望看到本篇文章的CTOs们以后在平台和框架选择的过程中考虑一下ASP.NET Core,因为她真的很优秀。

 

 

 

原文:https://www.cnblogs.com/savorboard/archive/2016/10/17/dotnet-benchmarks.html

 

 

 

 

 

 

Raft 更易理解的分布式一致性算法

一致性问题可以算是分布式领域的一个圣殿级问题了,关于它的研究可以回溯到几十年前。

拜占庭将军问题

Leslie Lamport 在三十多年前发表的论文《拜占庭将军问题》(参考[1])。

拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息。在战争的时候,拜占庭军队内所有将军必需达成 一致的共识,决定是否有赢的机会才去攻打敌人的阵营。但是,在军队内有可能存有叛徒和敌军的间谍,左右将军们的决定又扰乱整体军队的秩序,在进行共识时,结果并不代表大多数人的意见。这时候,在已知有成员不可靠的情况下,其余忠诚的将军在不受叛徒或间谍的影响下如何达成一致的协议,拜占庭问题就此形成。拜占庭假设是对现实世界的模型化,由于硬件错误、网络拥塞或断开以及遭到恶意攻击,计算机和网络可能出现不可预料的行为。

Lamport 一直研究这类问题,发表了一系列论文。但综合总结一下就是回答下面三个问题:

  1. 类似拜占庭将军这样的分布式一致性问题是否有解?
  2. 如果有解的话需要满足什么样的条件?
  3. 在特定前提条件的基础上,提出一种解法。

前两个问题 Lamport 在论文《拜占庭将军问题》已经回答,而第三个问题在后来的论文 《The Part-Time Parliament》中提出了一种算法并命名为 Paxos。这篇论文使用了大量的数学证明,而我基本就看不懂了(数学符号都认不全-。-;),考虑到大家理解起来都比较困难,后来 Lamport 又写了另外一篇论文 《Paxos Made Simple》完全放弃了所有数学符号的证明,使用纯英文的逻辑推导。我勉强逐字看了一遍,然后感觉若有所悟,但你问我搞懂了吗,我的标准应该还是没懂。对我来说理解一个算法有个明确的标准,就是真的懂了会在头脑里能将算法映射为代码,而看完后面一篇论文仅仅是若有所悟还达不到能映射为代码的清晰度。

虽然 Lamport 认为 Paxos 很 simple,但也许只是针对他的头脑而言。事实是大家理解起来都还是很困难,所以 Raft 就是建立在希望得到一个更易于理解的 Paxos 算法的替代品。把可理解性作为算法的主要目标之一,从论文题目就可看出来《In Search of an Understandable Consensus Algorithm》。

在进入正题前,我想起一个旧故事可以很直观的感受对一个问题不同的思维视角在可理解性上的差异。

不同视角的可理解性

依稀记得大约在二十年前,我还在读初中时在一本可能大概叫《数学中的发散思维》(不能很清晰记得书名了)的书中看到这么一个有趣的问题。

甲乙两人轮流在一张圆桌上平放黑白围棋子,每次放一子,棋子不许重叠,谁先没有地方放就输。
请问怎样放才能赢?

这个问题有两层意思,第一,有没有一种放法保证必赢?第二,如果有怎么证明?这里先停顿下,思考十秒钟。

上面的图回答了这个问题,就是先行者必胜,这里使用了三种不同的思维方式。

  1. 假如桌子只有一个围棋子那么大。
  2. 假如桌子无限大,先行者先占住圆心,由于圆是对称图形,所以只要对手还能找到位置放,你总能在对称的另一面找到位置放。
  3. 一个圆中可画单数个直径相等且互切的小圆。

三种不同的思维方式在可理解性难度上逐渐加深。第一种是极简化思维,但数学上是不严谨的。第二种是极限思维,和第一种结合起来就是数学归纳法了,在数学上是严谨的。第三种是形象思维,使用了几何学概念,但对于没有几何学基础知识的人就很难理解了。

Raft 协议的易理解性描述

虽然 Raft 的论文比 Paxos 简单版论文还容易读了,但论文依然发散的比较多,相对冗长。读完后掩卷沉思觉得还是整理一下才会更牢靠,变成真正属于自己的。这里我就借助前面黑白棋落子里第一种极简思维来描述和概念验证下 Raft 协议的工作方式。

在一个由 Raft 协议组织的集群中有三类角色:

  1. Leader(领袖)
  2. Follower(群众)
  3. Candidate(候选人)

就像一个民主社会,领袖由民众投票选出。刚开始没有领袖,所有集群中的参与者都是群众,那么首先开启一轮大选,在大选期间所有群众都能参与竞选,这时所有群众的角色就变成了候选人,民主投票选出领袖后就开始了这届领袖的任期,然后选举结束,所有除领袖的候选人又变回群众角色服从领袖领导。这里提到一个概念「任期」,用术语 Term 表达。关于 Raft 协议的核心概念和术语就这么多而且和现实民主制度非常匹配,所以很容易理解。三类角色的变迁图如下,结合后面的选举过程来看很容易理解。

Leader 选举过程

在极简的思维下,一个最小的 Raft 民主集群需要三个参与者(如下图:A、B、C),这样才可能投出多数票。初始状态 ABC 都是 Follower,然后发起选举这时有三种可能情形发生。下图中前二种都能选出 Leader,第三种则表明本轮投票无效(Split Votes),每方都投给了自己,结果没有任何一方获得多数票。之后每个参与方随机休息一阵(Election Timeout)重新发起投票直到一方获得多数票。这里的关键就是随机 timeout,最先从 timeout 中恢复发起投票的一方向还在 timeout 中的另外两方请求投票,这时它们就只能投给对方了,很快达成一致。

选出 Leader 后,Leader 通过定期向所有 Follower 发送心跳信息维持其统治。若 Follower 一段时间未收到 Leader 的心跳则认为 Leader 可能已经挂了再次发起选主过程。

Leader 节点对一致性的影响

Raft 协议强依赖 Leader 节点的可用性来确保集群数据的一致性。数据的流向只能从 Leader 节点向 Follower 节点转移。当 Client 向集群 Leader 节点提交数据后,Leader 节点接收到的数据处于未提交状态(Uncommitted),接着 Leader 节点会并发向所有 Follower 节点复制数据并等待接收响应,确保至少集群中超过半数节点已接收到数据后再向 Client 确认数据已接收。一旦向 Client 发出数据接收 Ack 响应后,表明此时数据状态进入已提交(Committed),Leader 节点再向 Follower 节点发通知告知该数据状态已提交。

在这个过程中,主节点可能在任意阶段挂掉,看下 Raft 协议如何针对不同阶段保障数据一致性的。

1. 数据到达 Leader 节点前

这个阶段 Leader 挂掉不影响一致性,不多说。

2. 数据到达 Leader 节点,但未复制到 Follower 节点

这个阶段 Leader 挂掉,数据属于未提交状态,Client 不会收到 Ack 会认为超时失败可安全发起重试。Follower 节点上没有该数据,重新选主后 Client 重试重新提交可成功。原来的 Leader 节点恢复后作为 Follower 加入集群重新从当前任期的新 Leader 处同步数据,强制保持和 Leader 数据一致。

3. 数据到达 Leader 节点,成功复制到 Follower 所有节点,但还未向 Leader 响应接收

这个阶段 Leader 挂掉,虽然数据在 Follower 节点处于未提交状态(Uncommitted)但保持一致,重新选出 Leader 后可完成数据提交,此时 Client 由于不知到底提交成功没有,可重试提交。针对这种情况 Raft 要求 RPC 请求实现幂等性,也就是要实现内部去重机制。

4. 数据到达 Leader 节点,成功复制到 Follower 部分节点,但还未向 Leader 响应接收

这个阶段 Leader 挂掉,数据在 Follower 节点处于未提交状态(Uncommitted)且不一致,Raft 协议要求投票只能投给拥有最新数据的节点。所以拥有最新数据的节点会被选为 Leader 再强制同步数据到 Follower,数据不会丢失并最终一致。

5. 数据到达 Leader 节点,成功复制到 Follower 所有或多数节点,数据在 Leader 处于已提交状态,但在 Follower 处于未提交状态

这个阶段 Leader 挂掉,重新选出新 Leader 后的处理流程和阶段 3 一样。

6. 数据到达 Leader 节点,成功复制到 Follower 所有或多数节点,数据在所有节点都处于已提交状态,但还未响应 Client

这个阶段 Leader 挂掉,Cluster 内部数据其实已经是一致的,Client 重复重试基于幂等策略对一致性无影响。

7. 网络分区导致的脑裂情况,出现双 Leader

网络分区将原先的 Leader 节点和 Follower 节点分隔开,Follower 收不到 Leader 的心跳将发起选举产生新的 Leader。这时就产生了双 Leader,原先的 Leader 独自在一个区,向它提交数据不可能复制到多数节点所以永远提交不成功。向新的 Leader 提交数据可以提交成功,网络恢复后旧的 Leader 发现集群中有更新任期(Term)的新 Leader 则自动降级为 Follower 并从新 Leader 处同步数据达成集群数据一致。

综上穷举分析了最小集群(3 节点)面临的所有情况,可以看出 Raft 协议都能很好的应对一致性问题,并且很容易理解。

总结

就引用 Raft 论文最后的一节的综述来总结本文吧。

算法以正确性、高效性、简洁性作为主要设计目标。
虽然这些都是很有价值的目标,但这些目标都不会达成直到开发者写出一个可用的实现。
所以我们相信可理解性同样重要。

深以为然,想想 Paxos 算法是 Leslie Lamport 在 1990 年就公开发表在了自己的网站上,想想我们是什么时候才听说的?什么时候才有一个可用的实现?而 Raft 算法是 2013 年发表的,大家在参考[5]上面可以看到有多少个不同语言开源的实现库了,这就是可理解性的重要性。

参考

[1]. LESLIE LAMPORT, ROBERT SHOSTAK, MARSHALL PEASE. The Byzantine General Problem. 1982
[2]. Leslie Lamport. The Part-Time Parliament. 1998
[3]. Leslie Lamport. Paxos Made Simple. 2001
[4]. Diego Ongaro and John Ousterhout. Raft Paper. 2013
[5]. Raft Website. The Raft Consensus Algorithm
[6]. Raft Demo. Raft Animate Demo

 

文章来源:

https://www.cnblogs.com/mindwind/p/5231986.html

 

 

 

iptables SNAT DNAT

一、SNAT源地址转换

1、原理:在路由器后(PSOTROUTING)将内网的ip地址修改为外网网卡的ip地址。

2、应用场景:共享内部主机上网。

3、设置SNAT:网关主机进行设置。

(1)设置ip地址等基本信息。

(2)开启路由功能:

sed -i '/ip-forward/s/0/1/g'

sysctl -p

(3)编写规则:

iptables -t nat -I POSTROUTING -o 外网网卡 -s 内网网段 -j SNAT --to-source 外网ip地址  #适用于外网ip地址固定场景

iptables -t nat -I POSTROUTING -o 外网网卡 -s 内网网段 -j MASQUERADE  #适用于共享动态ip地址上网(如adsl拨号,dhcp获取外网ip)

(4)做好安全控制:使用FORWARD时机进行控制,严格设置INPUT规则。

 

二、DNAT目的地址转换:

1、原理:在路由前(PREROUTING)将来自外网访问网关公网ip及对应端口的目的ip及端口修改为内部服务器的ip及端口,实现发布内部服务器。

2、应用场景:发布内部主机服务。

3、设置DNAT:网关主机上设置。

(1)设置ip、开启路由、设置SNAT

(2)编写防火墙规则:

iptables -t nat -I PREROUTING -i 外网网卡 -d 外网ip tcp --dport 发布的端口 -j DNAT --to-destination 内网服务ip:端口

NAT network address translation

仅从报文请求来看,可以分为:

SNAT 源地址转换

DNAT 目标地址转换

PNAT 端口转换

NAT server:能根据需要实现SNAT DNAT PNAT

并非是用户空间的进程完成转换功能,靠的是内核中的地址转换规则

私有IP客户端访问互联网的方法

SNAT 、PROXY

SNAT:主要用于实现内网客户端访问外部主机时使用(局域网上网用)

定义在POSTROUTING链上

iptables -t nat -A postrouting -s 内部网络地址或主机地址 -j SNAT --to-source NAT服务器上的某外部地址

另外一个target

MASQUERADE地址伪装(适用于PPPOE拨号上网,假设eth1是出口)

iptables -t nat -A postrouting -s 内部网络或主机地址 -o eth1 -j MASQUERADE

DNAT:主要用于内部服务器被外网访问(发布服务)

定义在PREROUTING

iptables -t nat -A PREROUTING -d NAT服务器的某外部地址 -p 某协议 --dport 某端口 -j DNAT --to-destination 内网服务器地址[:port]

注意:NAT服务器需要打开数据转发

echo 1 > /proc/sys/net/ipv4/ip_forward

或者修改/etc/sysctl.conf net.ipv4.ip_forward = 1

实验操作

SNAT、DNAT

 

实验一:

SNAT

规划主机A 作为SNAT server

eth0 ip地址172.20.1.10(外部地址),eth1 192.168.1.1(内部地址)

主机B当做局域网内主机

eth0 ip地址192.168.1.2 默认路由要指向192.168.1.1

SNAT server:

[root@localhost ~]# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 172.20.1.10

#上面和我们实例操作相同

[root@localhost ~]# echo 1 > /proc/sys/net/ipv4/ip_forward

主机B ping外部的其它主机(172.20.1.20模拟互联网上的主机)

DNAT

[root@nat ~]# iptables -t filter -F

[root@nat ~]# iptables -t nat -F

[root@nat ~]# iptables -t nat -A PREROUTING -d 10.1.249.125 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.4

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination

DNAT       tcp  --  0.0.0.0/0            10.1.249.125        tcp dpt:80 to:192.168.2.4

[root@nat ~]# netstat -tln | grep "\<80\>"  此时本机上并没有开放80端口

[root@wai ~]# curl http://10.1.249.125

hello  --> 此时我们访问为 nat 主机上的80端口  由上面可知,此服务器上并没有开放80,而是将请求送往 后端服务器

 

实体案例

我们有一台机器A可以上外网,配置eth0=192.168.1.1,eth1=222.13.56.192

有6台机器只有内网IP ,分别是192.168.1.102~192.168.1.108,想让这6台机器通过机器A上网

在机器A 防火墙上配置如下即可

/sbin/iptables -t nat -I POSTROUTING -s 192.168.1.101 -j SNAT --to-source 222.13.56.192

/sbin/iptables -t nat -I POSTROUTING -s 192.168.1.102 -j SNAT --to-source 222.13.56.192

/sbin/iptables -t nat -I POSTROUTING -s 192.168.1.103 -j SNAT --to-source 222.13.56.192

/sbin/iptables -t nat -I POSTROUTING -s 192.168.1.104 -j SNAT --to-source 222.13.56.192

/sbin/iptables -t nat -I POSTROUTING -s 192.168.1.105 -j SNAT --to-source 222.13.56.192

/sbin/iptables -t nat -I POSTROUTING -s 192.168.1.108 -j SNAT --to-source 222.13.56.192

在 6台机器上路由显示

route  -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 em1

169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 em1

0.0.0.0         192.168.1.1   0.0.0.0         UG    0      0        0 em1

形容智慧语与句

形容智慧的成语

1) 悉心竭力:悉心:尽心;竭力:用尽全力。竭尽智慧和力量。

2) 目达耳通:形容感觉灵敏,非常聪明。

3) 七窍玲珑:形容聪明灵巧。相传心有七窍,故称。

4) 颖悟绝伦:颖悟:聪颖。绝伦:超过同辈。聪明过人。亦作“颖悟绝人”。

5) 姱容修态:姱:美好;修:长远;态:志向。美丽的容貌,长远的智慧。

6) 矜智负能:矜:夸耀。夸耀智慧和才能。

7) 材高知深:材:通“才”。知:通“智”。才能出众,智慧高超。

8) 饰智矜愚:装作有智慧而在无知者面前夸耀。

9) 聪明睿达:聪明:聪敏有智慧。形容洞察力强,见识卓越。

10) 私智小慧:私:个人的;慧:智慧。个人的智慧和小聪明。指带有片面性而又自以为是的聪明。

表示智慧的成语

1) 折冲万里:折冲:指抵御敌人。指在远离沙场的庙堂上以谋略和智慧克敌制胜。常用以形容高明的外交才干或在外交争端中取得胜利。

2) 百龙之智:龙:公孙龙,战国时人,著有《公孙龙子》。一百个公孙龙的智慧。形容非常聪明。

3) 竭智尽力:用尽智慧和力量。

4) 积思广益:指集中众人的智慧,可使效果更大更好。

5) 聪慧绝伦:绝伦:同类中无可比拟者。指十分聪明智慧。

6) 足智多谋:足:充实,足够;智:聪明、智慧;谋:计谋。富有智慧,善于谋划。形容人善于料事和用计。

7) 教一识百:形容具有特殊的才能、智慧。

8) 没魂少智:智:智慧。形容失魂落魄的样子。

9) 知出乎争:智:同“智”;争:斗争。聪明才智是在反复斗争中锻炼出来的。比喻智慧来源于实践。

10) 才疏智浅:才:才能;疏:稀少;智:智慧。才识不高,智力短浅。用作自谦之词。

11) 虚室生白:虚:使空虚;室:指心;白:指道。心无任何杂念,就会悟出“道”来,生出智慧。也常用以形容清澈明朗的境界。

12) 智珠在握:智珠:佛教指本性的智慧。比喻具有高深的智慧并能应付任何事情。

13) 集思广益:集:集中;思:思考,意见;广:扩大。指集中群众的智慧,广泛吸收有益的意见。

14) 明镜不疲:明亮的镜子不为频繁地照人而疲劳。比喻人的智慧不会因使用而受损害。

15) 聪明睿知:聪明:聪敏有智慧。形容洞察力强,见识卓越。

16) 殚智竭力:殚:竭尽。用尽智慧和力量。

17) 智尽力穷:智慧和能力都已用尽。

18) 不测之智:测:估计;智:才智,智慧。不可估计的才智。形容智高才广。

19) 矜愚饰智:装作有智慧,在愚人面前夸耀自己。

20) 私智小惠:个人的智慧和小聪明。指带有片面性而又自以为是的聪明。

形容智慧的成语及解释

1) 一士之智:智:智慧。一个人的智慧。形容有限的才智。

2) 人多智广:人多智慧也多。用来强调人多出智慧。

3) 殚智竭虑:用尽智慧,竭力谋虑。

4) 智尽能索:索:竭尽。智慧和能力都已用尽。

5) 施谋用智:智:智慧,计谋。运用策略计谋。

6) 智贵免祸:智:智慧。人的聪明智慧,正当使用,可以使他避免灾祸。

7) 绝圣弃知:绝:断绝;圣:智慧;弃:舍去,抛开;知:通“智”,智慧。指摒弃聪明智巧,回归天真纯朴。

8) 敏而好学:敏:聪明;好:喜好。天资聪明而又好学。

9) 绝圣弃智:圣、智:智慧,聪明。弃绝聪明才智,返归天真纯朴。这是古代老、庄的无为而治的思想。

10) 虚室上白:虚:使空虚;室:指心;白:指道。心无任何杂念,就会悟出“道”来,生出智慧。也常用以形容清澈明朗的境界。

11) 明昭昏蒙:昭:明白;蒙:愚昧无知。聪明而通晓事理,愚昧而不明事理。

12) 高世之智:高世:超过世人;智:智慧,才智。具有超出世人的才智。形容才智非凡。

13) 双修福慧:修:善。福德和智慧都修行到了。指既有福,又聪明。

14) 才智过人:才能智慧都胜过一般人。

15) 万物之灵:万物:泛指天地间的所有生物;灵:聪明、灵巧。世上一切物种中最有灵性的。指人而言。

16) 负薪之资:负薪:背柴草,旧指地位低微的人;资:资质,指智慧,能力。指卑贱者的资质。

17) 醍醐灌顶:醍醐:酥酪上凝聚的油。用纯酥油浇到头上。佛教指灌输智慧,使人彻底觉悟。比喻听了高明的意见使人受到很大启发。也形容清凉舒适。

18) 知以藏往:知:同“智”,才智;以:已经;藏:包含。人的智慧包含在过去的事物中。比喻聪明才智来源于过去的经验教训。

19) 至智弃智:智慧达到极点,就可舍弃智慧不用。

20) 知尽能索:比喻智慧能力都竭尽了。

时髦的互联网公司都在用什么技术?

摘录自: http://www.cnblogs.com/onlytiancai/archive/2012/11/22/2783104.html

想知道国内互联网公司都在用什么时髦或靠谱的技术,服务,开源项目吗?为此我发起了个调查,已经有一些结果了,随我来看。

调查地址:http://www.diaochapai.com/survey/1a9164b1-fbbf-4476-b542-c6aad67f6587

本次调查收到133份样本,独立IP 130个,覆盖微博上好多互联网公司,有一定的代表性。

通过本次调查,总结出几个关键字:git,Markdown,RESTfull,nagios,Redis,mongodb,nginx,DNSPod,Python,QQ群,gitlab,jira

你们公司用什么管理文档?

通过调查发现大多数公司使用版本管理工具来进行文档管理,好处是文档的历史可以保留,而且git等版本管理工具开发人员用起来也很方便顺手。

另外就是用Wiki进行内部文档管理的公司也占一定的分量,它的优点就是可以在web查看,方便分享,但一般wiki都是全公开的,没有权限管理,对一些级别高的项目的文档管理有些不便。

在其它选项里也有公司选择用Google Doc进行文档管理的,也不错,但是缺点也是很明显的,这个你懂的。

其实在我们公司,文档也是用git管理的,但git的仓库是由gitlab管理的,文档既可以进行版本管理,也可以方便分享和权限管理。

你们公司的文档主要使用什么格式?

怪不得微软还这么强大,还有这么多人使用Office写文档,其次就是PDF,优点就是跨平台。

比较欣慰的是Markdown这种轻格式也逐渐被很多公司所认可,它编写方便,阅读美观,存储方便,平台通用,应该是程序员最喜欢的格式,我看好它。

你们公司的服务间通信选用什么协议和框架?

HTTP/RESTfull API以它的通用性,夸平台性赢得了很多公司的使用,完了就是RMI,.NET Remoting等语言框架内置的通信方式所占比例也很大,再次就是好多公司都是自主开发通信协议,看来一些开源的方案还是不能满足企业的内部需求。

再就是ZeroMQCelery等通信领域的新秀也崭露头角,有不少公司内部在使用了。

你们公司的运维监控用什么?

首先是好多公司在运维监控方面都是自主开发,这个现象比较奇怪,可能是现在好多公司的服务器越来越多,在运维监控上的需求越来越多,越来越个性化,一些开源的方案已经不太能胜任了,所以好多公司选择自主开发,在这个问题上,我还是希望各公司能分享自己的经验,让更多人受益。

nagioscatcti这两个老牌工具还是宝刀未老。 graphite也有很多人使用了,这是个比较轻量级的方案,数据上报协议很简单,而且有各种语言的客户端,比如pystatsd

其它选项里,有很多人提到了监控宝,看起来监控宝也功能不错,还有就是zenoss,zabbix,ganglia,collectd, munin,这些我都不了解,有兴趣的朋友可以搜搜。

你们公司的自动部署用什么?

震惊的同时也感觉有些道理,这么多公司的自动化部署竟然是用Shell脚本,Shell脚本真是运维的尚方宝剑呀。

puppetfibric的成绩也不错,puppet功能很强大,大公司应该用的比较多,fibric比较轻量级,也很灵活,应该一些新型公司在用。

其它选项里有人选择ccnet,cap,chef, capistrano,hudson,deployhq, jenkins, Bcfg2,ant的,大多不认识,但好多人用每日构建工具或持续集成工具做自动部署,确实感觉很新颖,要不就是我太土了,:)。

你们公司用什么做队列?

Redis这次当仁不让了,我想不用解释了,RabitMQ也很给力,占了近20%的份额,这个东西性能也相当强劲,淘宝褚霸经常推荐,应该错不了,主要是公司得有像霸爷这样能驾驭的了erlang的人才更靠谱。

JMQ,MSMQ不说了,其它选项里有MangoDB,ApachMQ, hornetq,activemq, kestrel, zeromq, beanstalk的,真是百花齐放呀,俺蛤蟆跳井--不懂。

你们公司的nosql系统用什么?

redis,memcached,mongodb这哥三齐头并进,不分伯仲。当然memcached资格老,用的人肯定多,redis不仅是k-value db,还支持key-结构化数据,队列,Sub-pub等模式,是架构设计的得力助手,mongodb虽然好多人说有这问题那问题,但瑕不掩瑜,在使用方便性上来说几乎无出其右者。

其它选项有CrabDB,hbase, couchbase, postgresql, dynamodb的,为啥没人用BDB呢?奇怪。tk也没人用了吗?

你们公司的WebServer,反向代理,7层负载用什么?

这。。。nginx又不低调了,快满格了。apache竟然还活着,佩服。haproxy做7层负载应该很强,但使用量貌似有些对不起它的知名度,我 一直以为大家都是用lvs做四层负载,haproxy做7层负载呢。gUnicorn就5个人使用,识货的人不多呀,或者玩python的公司不多,它的性能应该仅次于nginx,当然功能没nginx那么丰富,做python的web server肯定是首选,+1。

其它选项里有Litespeed,netscaler,F5,IIS,lvs,Tomcat的,用F5的都是高富帅,屌丝们可以退散了。

你公司的DNS解析用什么?

域名解析对一个互联网公司的重要性大家都是有目共睹的,DNSPod以其稳定安全的解析赢得了众公司的亲睐,成绩不俗,赞一个。

好多公司还是选择域名注册商如万网等自带的解析,还有一些IT能力或研发能力强的公司自己用Bind架DNS或完全自主开发,其它选项里有tinydns,softlayer,linode, aws, csiso,name.com, 花生壳啥的。

您公司有没有用时髦的编程语言?

好吧,我是python的坚定支持者,我觉得语言学好c,python,javascript基本就是无敌了,图表说明一切,不解释了。

other选项里有scala,Groovy,f#, obj-c啥的,都不错的语言,当然除了obj-c。

你们公司内部交流分享都用什么?

qq群立功了,呵呵,看来互联网公司都比较开放,不像一些传统公司,上班连qq都不让开,坑爹呀。内部论坛和rtx也有不少人用,另外飞信我就不说了。。。

其他选项有:skype irc,8hours.do, Lync(支持下),google sites, trac, wangwang(这是啥?), bootcamp, hipchat, IMO, OC, GTalk, salesforce, 邮件,wiki, node_chat, openfire, LCS, 飞秋(还记得那些年我们传的片儿吗?),webex, Hi(是百度hi吗亲?)。我去,好长,一口气念不完呀。

你们公司的BUG/需求管理用什么?

这个问题回答的好不统一,直接上其它选项吧:trello(好),jira(牛),mantis, QC, ClearQuest,github,redmine(有些老了),prd,禅道,bugfree,Agilezen,Asana(潮),openerp,MantisBT,codebase,bugzilla,urtracker

好了,调查分析到此告一段落,其实有好多问题还没问题,比如你公司用谁家的cdn? 你公司用什么源码管理工具?等,下回再来分解吧。