Web 架构和我的技术有用论观[转载]

原文来自http://mrluanma.github.io//2010/02/05/web-architecture.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+mrluanma+(江湖程序员)

在一个封闭的小圈子里讨论 Web 架构的时候, 我”突发奇想”将一小段内容发到 twitter 上:

并且大部分的网站都不需要 Google 级别的负载, 所以对于大部分开发者, 创业者来说, “架构”都是最最不重要的事情, 做出好产品, 伺候好用户, 赚到钱才是真的.

然后 @xmpp 认为我这是”技术无用论”, 我也做了一些解释. 现稍作整理, 权充博文一篇.

可能我的表达的确存在一些让人误解的地方. 首先是有人问:

昨天上网不小心看到了一些关于网站架构的讨论: 有人说将WEB站点用独立的方式, 也就是静态页面放到一服务器, 动态页面放一服务器, 图片放另一服务器, 用它们组起来作为一个站点, 这样会加快浏览速度.

请问这样的原理是怎样的?

然后我半壶水响叮当:

一般静态页面和图片可以当做一种东西处理, 和动态页面比起来肯定少耗费 CPU, 动态页面的话肯定会比较费 CPU, memcache 专耗内存, DB 基本上整体负载都很高, 所以如果你有一堆机器要”架构”的话, 肯定需要在 CPU, 内存, IO 这三方面来均衡着排布. 比如 memcache 耗内存不耗 CPU, 那就可以把动态页面放 memcache 的机器上一起跑, DB 啥都耗就自己占整个机器跑, 静态文件这些就直接让反向代理的 web 服务器来跑.

以上讲的是物理机器上的分隔, 其实为了提高访问速度, 一般在 URL 上也要做文章. 因为浏览器 HTTP 协议同时只对一个域名的机器发起最多两个连接, 比如我打开一个动态页面, 这个动态页面里用到 20 个静态文件, 那如果这些文件都是用两个水管来放的话, 是不是没有我同时用 N*2 根水管来放快? 所以一般网站就算只有一台机器提供全部内容, 也会把静动态内容放到不同的二级域名下来提供, 比如说一般的内容用 website.com 来提供, 静态文件就就用 static.website.com 来提供, 这样浏览器就可以向 website.com 发起两个连接要东西, 同时也可以向 static.website.com 发起两个连接要静态文件.

没懂, 啥叫水管?

其实我说的时候我就感觉没说清楚, 我这里一个水管的意思就是一个 TCP 连接. 我 Google 到以下别人解释的更清楚的, 摘录一段:

在HTTP 1.1 Spec 中针对 Persistent Connections 提出了这样的 Practical considerations: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

以上内容表明, 为了提高 HTTP 响应时间以及避免产生网络堵塞, HTTP 连接中的客户端不应该与服务器端建立超过2个 的 HTTP 连接. 如果有更多的请求需要, 那么这些请求将被 pipeline 到这两个 HTTP 连接之中, 并以异步的方式传送给服务器端. 举个例子: 有上百辆汽车(requests)想从天津开往北京, 但是天津与北京之间最多只允许修建两条公路(HTTP connection), 因此这些汽车要想从天津驶往北京的话, 就只能走这两条公路.

还有这篇, 内容都挺好, 我就不摘录了, 建议都看看.

忘了说一句, 我是山寨的, 只是看了一堆各个网站的架构, 并没有大型 Web 运营经验, 并且我估计很长时间内也不会有这样的事情做. 并且大部分的网站都不需要 Google 级别的负载, 所以对于大部分开发者, 创业者来说, “架构”都是最最不重要的事情, 做出好产品, 伺候好用户, 赚到钱才是真的.

以下是 twitter 上的讨论:

@xmpp

RT: @mrluanma: 大部分的网站都不需要 Google 级别的负载, 所以对于大部分开发者, 创业者来说, “架构”都是最最不重要的事情, 做出好产品,伺候好用户, 赚到钱才是真的 // 技术无用论. 看你站的角度, 如站在孔子学院网站角度, “做出好产品”也是很不重要的.

@mrluanma(我自己)

RT: @xmpp RT: @mrluanma: 大部分的网站都不需要 Google 级别的负载…//技术无用论. 看你站的角度, 如站在孔子学院网站角度, “做出好产品”也是很不重要的 //我绝对不认为技术无用, 我说的是大部分网站不需要担心架构问题, 至少在早期不用.

@xiaoxiaolu

非技术无用论, 是产品导向, 等有负载再解决是务实做法, 换个角度也可以说为啥你丫不进大公司? 我已见过不止一家公司做完技术就准备倒闭 RT @xmpp: RT: @mrluanma: 对于大部分开发者, 创业者, 架构是最最不重要的事情, 做出好产品,伺候好用户// 技术无用论.

@nepalon

市场导向的话对处于生存期的公司比较合适, 只要迎合市场, 功能不算太烂, 一般都可以有市场. 但要进一步发展就要提高技术了, 有了更好的技术, 才能提高性能, 提高用户体验, 提高自己的行业中的地位. 我们的做法是通过销售来发掘市场, 从而根据市场来开发产品, 做技术储备.

@mrluanma

RT @nepalon: 因为我本身就是做开发的, 我觉得把市场看的比架构重是我的一个突破, 当然, 要长远发展, 如果有技术负债, 也肯定是要还的. 这两天用到的产品体验中, 360buy, 邮政的EMS查询, 移动的号薄管家这些的技术负债我觉得都比较严重.

OSX的VPN

最近有一台香港的服务器，同事用pptpd作了一个VPN服务，而且我也有账号，真好。
在公司使用WINDOWS 7可正常使用，不过回到家使用MAC OSX就上不了了。
当登录到这台服务器上，查看了/var/log/daemon.log时，发现以下错误：
GRE: read(fd=7,buffer=80524a0,len=8260) from network failed: status = -1 error = Message too long
原因就出现在Message too long这几个字眼上，查了下google，只要在/etc/ppp/pptpd.options里面加入两个即可：
mru 1400
mtu 1400
那到底这两行是什么意思呢？
MTU(Maximum Transmission Unit，MTU):http://zh.wikipedia.org/wiki/最大传输单元

最大传输单元（Maximum Transmission Unit，MTU）是指一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位）。最大传输单元这个参数通常与通信接口有关（网络接口卡、串口等）。

因特网协议允许IP分片，这样就可以将数据报包分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。这一分片过程发生在 IP 层（OSI模型的第三层，即网络层），它使用的是将分组发送到链路上的网络接口的最大传输单元的值。原始分组的分片都被加上了标记，这样目的主机的 IP 层就能将分组重组成原始的数据报了。

在因特网协议中，一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址所经过“路径”上的所有IP跳的最大传输单元的最小值。或者从另外一个角度来看，就是无需进一步分片就能穿过这条“路径”的最大传输单元的最大值。

RFC 1191 描述了“路径最大传输单元发现方法”，这是一种确定两个 IP 主机之间路径最大传输单元的技术，其目的是为了避免 IP 分片。在这项技术中，源地址将设置数据报的 DF（Don’t Fragment，不要分片）标记位，再逐渐增大发送的数据报的大小——路径上任何需要将分组进行分片的设备都会将这种数据报丢弃并返回一个“数据报过大”的 ICMP 响应到源地址——这样，源主机就“获取”到了不用进行分片就能通过这条路径的最大的最大传输单元了。

不幸的是，越来越多的网络封杀了 ICMP 的传输（譬如说为了防範 DoS 攻击）——这使得路径最大传输单元发现方法不能正常工作，其常见表现就是一个连接在低数据流量的情况下可以正常工作，但一旦有大量数据同时发送，就会立即挂起（例如在使用 IRC 的时候，客户会发现在发送了一个禁止 IP 欺骗的 ping 之后就得不到任何响应了，这是因为该连接被大量的欢迎消息堵塞了）。而且，在一个使用因特网协议的网络中，从源地址到目的地址的“路径”常常会为了响应各种各样的事件（负载均衡、拥塞、断电等等）而被动态地修改——这可能导致路径最大传输单元在传输过程中发生改变——有时甚至是反复的改变。其结果是，在主机寻找新的可以安全工作的最大传输单元的同时，更多的分组被丢失掉了。

对于时下大多数使用以太网的局域网来说，最大传输单元的值是 1,500 字节。但是像 PPPoE 这样的系统会减小这个数值，通常是1492（= 1500 – 2（PPP）- 6（PPPoE）），这就使得在使用最大传输单元发现方法时可能会产生这样的结果：一些处于配置不当的防火墙之后的站点变得不可达了。对于这种情况，还是可能找到变通的方法的，但这取决于你控制的是网络的哪一部分。这些方法包括改变用来在防火墙一端建立 TCP 连接的第一个分组的 MSS（Maximum Segment Size，最大分段大小）。

MRU:不才啊，找不到MRU的意思。不过个人的猜测是(Maximum Rrrive Unit，MRU).
pptpd默认这两个参数的都是1280，那为什么1280不行却1400就可以呢？难道windows下面发的数据包比osx的包要小，osx在包里还加上其它的东西。这东西还真可以深究！

用圆周率测试cpu速度

今天看了一blog,内容大致是一台dell服务器非常慢，负载低。以往的经验是出现在程序锁或io block上，一般是某些重要资源争用导致的。
他的思路是先用圆率来测试CPU速度的，代码如下
time echo "scale=5000; 4*a(1)" | bc -i -q
通过得到结果来测试速度是否有问题。正常情况如果是服务器是半分钟以下就可以搞定。我电脑是1分钟以下。然后再看看syslog里的报错。
看blog里说最后的结果是出现在dell服务器上的linux内核bug,大致是内核在cpu功耗和温度控制上有bug,没法拿到正确的值，由此导致cpu持续被降频！