IT瘾网站推荐

网站速度终极优化

Fri, 18 Nov 2022 16:05:30 CST

好久没有折腾网站速度了。最近尝试再次优化提升网站的访问速度。

利用了CDN厂商Cloudflare的Page rules，创建了三条页面规则，将后台登录页面免除缓存外，其它页面全部都缓存在Cloudflare的全球CDN数据中心。

这样全球访客访问本网站的时候，除了第一次要从源主机上索取生成页面，其它都不再需要，直接从最近的CDN数据中心获取，这样既减轻了网站主机的资源消耗压力，又直接提升了访客的访问速度。

鉴于Google Anlytics统计数据越来越不好用（Cloudflare本身自带Web Analytics），再加上我也没有动机去使用它，索性把统计代码取消了，这样一来既减少了网页页面请求数量，也没有了cookies记录，因此访问过的网页会直接缓存在访客的浏览器中一段时间（设置为1天）。

去除了Google Anlytics统计功能后，访客在本网站上来回浏览的时候，短时间内去CDN上下载网页都不必了——CDN那边会返回304告诉浏览器页面没有改动，所以直接调用原缓存页面，进一步提升网站访问速度。

这样的网站速度终极优化方案，把本网站的加载速度基本控制在500毫秒以内，比秒开还要快。

这么多年后，再一次化繁为简、返朴归真，回归到博客网站写作的初心，其它的东西都不必要。

对标 VS Code，JetBrains 的下一代 IDE ：Fleet

Mon, 29 Nov 2021 23:00:08 CST

昨天（11月29日）， JetBrains 网站上出现了一个全新的 IDE — Fleet

它是谁呢？这软件的风格，怎么看都不像 JB 的亲儿子。。

不过，我很负责任地告诉，这就是 JetBrains 的下一代 IDE ，妥妥的亲儿子。

目前 Fleet 还处于开发阶段，还没有开放下载使用，如果你想尝鲜，可以通过这个链接（https://www.jetbrains.com/fleet/preview/）填写一下表格申请。

看到这个消息，我就赶紧去申请了，但何时会通过，官方表示也不清楚。

虽然还无法使用，不过可以从官网上已经能 get 到一些关于 Fleet 的信息。

Fleet 声称是从头开始构建的，拥有全新的架构和用户界面。但我不得不说，你的界面真的很像 VS Code（这口锅你是背定了），虽然比 VS Code 会好看一点。

虽然 Fleet 定位轻量级编辑器，但该有的东西，它一样也没落下：

智能补全
重构
导航
调试

以及 IDE 中一直存在的所有功能它都有，更重要的是，一键即可使用所有这些功能。

过去使用 JetBrains 的产品，通常是会多少种语言，就安装多少个 JetBrains IDE，如今你再也不用为你的内存和硬盘担心了，Fleet 和 VS Code 一样，适用于多种流行的编程语言。

除了一些常规的功能和需求之外，Fleet 也给我们带来了一些惊喜。

第一个惊喜

Fleet 是分布式的，它支持如下场景

协作开发：多个客户在同一个开发环境中工作并相互交互。
远程/云 IDE：托管在其他地方的开发环境，例如远程机器、集群或云。
多目标文件系统：开发和运行一个涉及多台机器或容器的项目，例如，一个基于微服务的应用程序。

第二个惊喜

Space 提供了编排支持，可从源仓库轻松启动远程服务器实例，支持使用 Dockerfile 进行自定义。

第三个惊喜

Fleet 全方位支持团队协作，同团队的人可以同时开发同一个项目，编辑同一个文件或者不同文件，运行测试、访问终端以及执行协作 IDE 所期望的其他功能。

JetBrains 是一家伟大的公司，做为一位开发者，可以没用过它的产品，但不可能没听过它的大名。

它们家的产品（比如 PyCharm，Goland ），经常拿来和 VS Code 做比较。

他们两者的关系有点像 Django 和 Flask，JetBrains 开箱即用，不用太多的配置就可以直接上手，这就导致了 PyCharm 非常重，一些配置不太给力的电脑，可能会内存不够用，而相反， VS Code 则非常轻量，需要你自行安装一些插件才能用得顺手。

JetBrains 做为 IDE 专业户，对开发工具的理解非常到位，做出来的产品做了比较重之外，很少有其他槽点，因此我可以完全相信 JetBrains 的产品能力和开发能力。

希望，我可以同时卸载 PyCharm Goland Clion 的这一天，能早一点到来…

市场规模测算方法及影响因素

Tue, 16 Apr 2019 10:20:23 CST

市场规模简单来说就是通过货币指标来衡量一个行业的总体需求量。我们经常在一些初创公司的新闻稿，CEO讲话，行业研报中看到某一个行业是千亿级的市场，这里的千亿就是通过货币指标计算出的市场规模。

市场规模有两个特点，第一特点是量级都会很大，比如中国汽车共享出行市场规模3800亿/年，亲子游市场规模将达到492亿/年等等。这很容易理解，中国总人口数量庞大，任何消费级的市场都会非常庞大。第二个特点是同一个行业的市场规模会有很多种说法，因为这是一个估算值，没人说得清准确的规模是多大。大家都是按自己的逻辑推算出来的。那么市场规模究竟是如何计算的？不同的行业规模数字哪一个更靠谱呢？下面我们试着说明下市场规模的测算方法及影响因素有哪些。

1，常见的市场规模测算方法

市场规模的测算有两种方法，自上而下(Top Down)的方法和自下而上(Bottom Up)的方法进行测算。

第一种是自上而下的宏观推演，层层细分。先预估整体大行业的规模，然后逐层分解到自己所在行业的细分市场。比如，整个出行市场规模3800亿/年，专车市场占比30%，高端专车占其中的10%，那么高端专车市场的规模就是3800*30%*10%=114亿/年。

第二种是自下而上，先定位目标用户群和需求的频率，也就是需求量。然后再乘以单价计算出市场规模。写成公式就是(市场规模=需求量*价格)。比如亲子游的市场规模测算，国家统计局中2018年普通小学在校生8900万人，假设排除学校的活动外每年还会以家庭为单位去旅行的孩子占比10%，也就是890万人，每次旅行最少要有一个大人陪同，所以总人数再乘以2，为1780万人。假设每次旅行人均消费按3000元计算，那么亲子游市场规模为534亿/年。相比之下第二种自下而上的测算方法更强调用户，对用户的实际情况和场景的把握更准确一些，所以更多被使用。

第二种市场规模的测算方法虽然相对更准确，但细想一下还是会发现很多问题。首先推算逻辑过于简单粗暴，没有考虑各种影响因素和变量的影响。第二，其中包含很多假设条件及数据，其中任何一个假设条件出行问题都会影响最终的结果。第三，任何市场的形成都是供需匹配的结果，二者缺一不可。下面我们逐个说明。

2，不同市场类型决定了规模强弱

市场规模测算，顾名思义我们考虑的是整个需求市场的容量。但市场的形态分为很多种，每一种市场都有自己的特征和固有的天花板。市场规模的计算必须要锚定在特定的市场形态上。

已经存在的市场为存量市场，例如出行行业中的出租车市场等。之前从未出现过的叫新市场，例如专车市场，外卖市场等等。在存量市场中又可以分为强监管市场和自由竞争市场。例如金融，诊疗行业都是强监管市场，需要政府许可，相关拍照，并且受政策影响明显。餐饮，家电行业则属于自由竞争市场。

存量市场和新市场在测算市场规模时有显著的区别，新市场是从0到1对原有模式的颠覆，没有历史经验和数据可以借鉴。只能从商业模式中解决的痛点，用户的刚性进行预估。存量市场是从1到100对现有行业的改造和效率提升，价值要小于增量市场。存量市场里的强监管市场，则完全取决于政策的变化。而对于自由竞争的市场规模，我们则需要考虑市场的终极模式会是什么样子的。

除了市场的终极模式外，我们还需要动态的来看待市场和公司的变化，聪明的公司总是会想办法突破现有的天花板。例如滴滴最开始是基于出租车的存量市场，但随着与Uber的竞争进入到了专车的新增市场。

3，终极模式决定了实际市场占有率大小

每一个市场都会有竞争，市场的终极模式是指在动态的竞争过程中，最终每一家在市场中所占的份额情况。按前面的市场规模测算，如果市场终极模式是赢者通吃，一家独大的局面，那么理论上是没有问题的。但任何一个行业都很难被彻底垄断。一个充分竞争的市场，在有限的时间内能拿到5%的市场份额就已经很了不起了。

因此，市场的终局模式是一个必须考虑的因素。那么市场终局是由谁来决定呢?答案是所在的行业和商业模式。理论上需要有规模效应或网络效应的行业或模式最终都会演变为一家独大或双寡头制衡的情况。例如传统行业的电话，传真机和复印机等，使用的人越多规模效应越明显，效率提升越显著，这转换到互联网上就是QQ和微信。

而门槛较低且规模效应不明显的行业则会发展的较为分散，例如新闻，游戏，快消等行业。按照常识和人们的生活习惯，以及地域距离和成本等因素，很难有一家能够完全垄断。

4，市场驱动因素决定了市场增长瓶颈

最后再回来看文章开始列举的两个行业示例，出行市场和亲子旅游市场。在这两个市场的测算中我们的关注点都围绕在需求端。但任何一个市场的形成都是由供需共同作用的结果。从供需的角度来看，市场增长的驱动里可以来自需求端的拉动，也可以来自供给端的驱动。

通常情况下，从供给到需求驱动也是一个动态变化的过程。大部分行业刚开始的成长阶段都是由供给驱动，产能限制了能提供产品和服务的数量。到了成熟期后开始转由需求驱动。

通用的底层规律是：在开始阶段产能较弱，提供的产品较少，这时能保证产能和供给的公司会胜出，接下来产能会迅速增长，产品变得丰富，消费者面临选择恐惧，市场由供给驱动开始转向需求驱动。这时候能减少产品的方差，保证使用体验并做出品牌的公司会胜出。品牌多了以后就会更加依赖渠道触达用户，这时候渠道会有丰厚的利润，用户终端和媒体会胜出。市场最终转变为由需求驱动。

在出行市场中，出租车，专车和司机都是供给端。乘客需求增长到一定规模后供给就会成为市场规模的增长瓶颈，换句话说这时市场的整体规模就不是由乘客数量和使用频率决定了，而是有出租车，专车数量和司机数量决定了，更宏观来看可能还会受到城市路网结构和公共交通政策影响。对于亲子旅游市场也有同样的逻辑，亲子游的需求集中在寒暑假期间，在需求集中爆发时，火车和航空公司的运力，飞机数量。旅游目的地城市的酒店数量就是供给端的瓶颈。而这时市场规模的大小和增速也将由供给端决定。

5，市场规模影响因素总结

我们曾经看到有公司的创始人发文，在理想市场规模下踩过的5个深坑。理想的市场规模总是很丰满，但实际可触达的市场规模则显得有些骨感。所以，我们总结本篇文章的内容，建议你在任何场合看到或需要计算市场规模时，都请考虑以下几点：

1，当前的市场规模是如何测算的，计算逻辑是什么？
2，我们面对的是一个什么样的市场，增长潜力有多大？受哪些因素影响？
3，这个市场的终极模式会是什么样的？大概需要多长时间可以达到？
4，市场目前发展到什么阶段？驱动力是什么？增长的瓶颈可能在哪里？

—【所有文章及图片版权归蓝鲸（王彦平）所有。欢迎转载，但请注明转自“ 蓝鲸网站分析博客”。】—

关联规则推荐算法的原理及实现

Sun, 13 Nov 2016 21:27:35 CST

关联规则用来发现数据间潜在的关联，最典型的应用是电商网站的购物车分析。本文将通过一个简单的例子来说明关联规则中各个术语的含义以及具体的计算方法。

这是一些用户的购物数据，uid是用户的ID，后面是每个用户具体购买的商品名称，我们使用字母进行标识。下面我们将使用关联规则对这些数据进行分析，挖掘不同商品间的联系。

首先将前面的一维的购物车流水数据转换为二维的列表。然后在这个基础上计算不同商品及商品组成出现的频率。

在关联规则中，有三个重要的术语，分别为支持度(Support)，可信度(Confidence)和作用度(Lift)。第一个属于是支持度，支持度是一件商品在所有购物车中出现的频率。如果我们希望分析的是两件商品的关联，那么支持度就是这两件商品同时出现的频率。支持度的作用是用来衡量关联规则重要性的指标，简单来说就是我们所要挖掘的关系有多大的普遍性，普遍性越大这条关联规则越重要。第二个术语是可信度，可信度是指两件商品中当第一件出现时，第二件商品同时出现的频率。可信度用来衡量关联规则的准确性。第三个术语是作用度，作用度用来衡量关联规则对于商品出现频率的影响。只有作用度大于1的关联规则才有实际的应用意义。下面我们分别介绍这三个术语的计算方法。

支持度(Support)

支持度是两件商品在所有购物车中同时出现的概率，可以记录为P（A U B）。支持度的计算公式为A,B两件物品同时出现的次数与购物车总数的比率。对于前面例子中，如果我们要计算商品A和B在5条购物车记录中的支持度，具体的计算公式为1/5。商品A和B在5条购物车记录中只在uid1中同时出现过。

单件商品的支持度的计算方法与两件商品一样，如果我们要计算商品A的支持度，具体的计算公式为3/5。商品A在5条购物车记录中共出现了3次。单件商品的支持度描述了在没有其他商品影响的情况下，商品在购物车中出现的次数。

可信度(Confidence)

可信度是一个条件概率，两件商品其中一件出现在购物车中时，另一件也会出现的概率。可以记录为P（B|A）。对于前面的例子中，如果要计算A和B两件物品的可信度，具体的计算公式为1/3。商品A出现的3次，商品B同时出现的次数为1次。

作用度(Lift)

作用度通过衡量使用规则后的提升效果来判断规则是否可用，简单来说就是使用规则后商品在购物车中出现的次数是否高于商品单独出现在购物车中的频率。如果大于1说明规则有效，小于1则无效。对于前面的例子中，如果要计算规则A-B是否有效，计算公式为(1/5)/(3/5*3/5)=(0.2)/(0.6*0.6)=0.2/0.36=0.55。作用度小于1说明A-B规则对于商品B的提升没有效果。

按照前面的计算公式我们分别对下面的四个规则进行了计算，在获得支持度，可信度后计算出了四个规则的作用度。其中A-D规则作用度大于1，说明对购物车中已经包含商品A的用户推荐商品D，购买概率是单独推荐D的1.11倍。

—【所有文章及图片版权归蓝鲸（王彦平）所有。欢迎转载，但请注明转自“ 蓝鲸网站分析博客”。】—

微信小程序的机会在于重新理解群组与二维码

Fri, 30 Dec 2016 19:00:17 CST

历时一年，唯一一个尚未发布就获得Pony Ma与Allen Zhang站台的产品：微信小程序，将于2017年1月9日正式上线了。我很期待。唯一要警惕的是：防止长考出臭棋。

来源：腾讯科技

在上线前夕，我对于如何借助小程序的东风获得蓬勃发展，忧心忡忡。要不要押注小程序，以及如何押注小程序，如何抄袭小程序，相信这是摆在中国众多中小创业者和大公司面前的问题，区别在于前者关注如何拥抱，后者关注如何抄袭。支付宝小程序、今日头条小程序、百度小程序面世的时间为时不远了。

就我个人理解而言。allen两句话特别值得关注。

1，“我相信这种协作式的任务，对于小程序的分享会起到很大的一个帮助，我们可以在里面构思出非常多需要群组一起完成的任务”—allen。

微信群组目前面临的最大问题是缺少有价值的互动内容问题，要么冷冷清清无人关注，要么沦为广告阵地。微信红包是支撑微信群活跃的第一大功臣。我想小程序的一个很大的使命是，如何为微信群组注入鲜活的、独特的、互动的内容。

2，“把小程序想象成PC时代的一个网站的话，我相信会帮助大家更好地理解什么是小程序”—allen。

二维码与服务号，是微信推动产生的一个玩法的两面，我想小程序是对二位码和服务号的一次升级，甚至可能是颠覆。二维码将在虚拟现实达到消费级应用之前，扮演连接微信和真实世界的桥梁。之前，所有的二维码基本上都指向了关注一个服务号，在服务号里再构建菜单来引导用户使用服务，在这个过程中，首先服务号的体验是不够的，其次产生大量信息的冗余与负担，有了小程序以后，那么所有拥有部署二维码能力的线下实体，无论是一个广告牌，还是一个门店，或者一张票，或者一包烟，或者一个菜单，或者一瓶水，都将成为小程序的入口。

小程序将基于这个入口提供接近app级的服务体验，无须安装、下载。也不会带来消息负担和安装过多的服务。

3，所以，有线下能力，应该着重思考二维码、服务号和小程序的关系。有线上能力的，应该着重思考群组+小程序。

4，小程序是一个比QQ群应用高明100倍的玩法，首先是调动了无穷无尽的民间生产力来基于足够细分的场景来创造新内容与新互动，其次小程序的方向不再是单向的，而是协作式与互动的。

5，红包是微信官方做的最大的，最佳的，群组内的小程序最佳实践。

6，未来微信群组将获得巨大的升级，群组与群组之间将因由小程序而产生巨大的差异化，一群人将可能因为某一个小程序聚集在一起完成某个特定任务，当然也同时可以享受微信群的基本服务。

7，未来每一个实体上都可能部署上二维码，每个二维码都将对应为一个小程序，甚至是一个小程序的特定的界面。

8，新的一年，做一个小程序吧。

2016中国社交媒体影响报告

Thu, 28 Jan 2016 17:49:24 CST

北京 2016 年 1 月 28 日 : 最新研究显示超过一半（51%）的中国城市居民已经成为了社交媒体用户，较去年大幅上升了17个百分点。然而，认为社交媒体给他们的生活带来积极影响的人仍然在减少：从去年的65%下降到今年的61%。有15%的受访者认为社交媒体让他们的生活变差了，比去年增加了2个百分点，还有24%的受访者认为社交媒体没有让生活变得更好或更差。今年的中国社交媒体影响满意度得分为67.0，较去年的68.0有所下降，而2014年时曾经高达73.4。

这是全球调研巨头凯度集团连续第三年发布《中国社交媒体影响报告》。今年的报告还指出认为社交媒体没有任何负面影响的人从去年的18%下降到了14%。有67%的中国城市居民认为“我的生活变得越来越忙碌”，而在社交媒体用户中，这一比例高达71%。

凯度集团是全球最大广告传播集团WPP的市场调查分支机构。本次调查利用了网上实名制调查，大数据挖掘，手机行为数据分析，微博文本分析和微信订阅号文本分析五个渠道。今年的报告还首次纳入了中国之外的数据，比较了来自于5个国家的15万名用户的回答，以及近2.5万名中美手机用户的社交媒体使用习惯。

本次报告的中英文全文和中文信息图已经通过凯度中国观察网站（ cn.kantar.com）发布。该网站提供来自凯度集团的与中国市场相关的内容，通过网站不断增长的数据库，记者可以免费便捷地获取商业、科技和消费相关领域的深度数据和专家评论。

央视市场研究公司（CTR）媒介与消费行为总经理李晏表示：“社交媒体的不断渗透还在加速，这一现象发生在各级城市和各年龄段里。尽管各社交媒体公布的注册用户数量增长已经放缓，但因为我们的问题是‘昨天你是否用过社交媒体’，所以我们可以得出的结论是中国人用社交媒体的频率增加了。”央视市场研究与Kantar Media CIC公司执行了今年的调查。

李晏同时指出，随着社交媒体越来越深入到人们生活的各个环节，人们对不同媒体的信任度也发生了变化。“社交媒体用户对传统媒体的信任度下降了，这一现象在90后社交媒体用户中尤其明显。而以微信和互联网为代表的新媒体平台越来越得到年轻的社交媒体用户的信任。”

如果将中国社交媒体用户与美国、英国、法国和巴西的社交媒体用户相比的话，中国人的积极度排名第三。有62%的美国受访者在受访时的前四周里用过Facebook或是Twitter，而这一比例在巴西是58%，中国（微博和微信的使用）是56%。法国（50%）和英国（36%）较低。在所有上述国家中，女性都比男性在社交媒体上更活跃。在中国，女性（58%）比男性（54%）高出四个百分点。

本次报告里首次纳入了手机行为数据的分析。通过分析18500名中国用户在手机上使用微信的情况和6058名美国用户在手机上使用Facebook的情况，报告指出美国人平均一天要打开Facebook 17.9次，高于中国人的一天打开微信14.5次。但中国人用社交媒体的总时长高于美国人（48分钟/天 vs 43分钟/天）。这一研究手段也证明了女性在社交媒体上更活跃：美国女性用户每天用Facebook的时间比男性长20分钟，而在中国使用微信的时间差距为8分钟。

李晏表示：“很明显，不管在哪个国家，女性都更喜欢分享东西，而社交媒体正好提供了一个理想的平台。对于以女性消费者为主要目标受众的品牌来说，它们应该面向社交媒体渠道制作以热门话题为题材的广告。”

为了了解中国人在微信上到底在看些什么，本次报告分析了微信上最热门的50个公众号在2015年9月15日到12月15日间发布的所有文章的阅读情况。在这三个月里，这些公众号共发布了26202篇文章，总阅读量为69亿次。通过与去年的比较，我们发现情感类内容，尤其是“心灵鸡汤”文章，变得特别受欢迎：50个最热门公众号中有19个是情感类账号，而去年只有三个。情感类文章的阅读量份额也从去年的21%上升到了34%。娱乐类内容的阅读量份额为41%，依然是最大的。健康类内容的份额为14%，与去年相同。新闻类内容从去年的5%上升到了8%，而时尚类内容的阅读量份额从去年的12%大幅下跌到了3%。

Kantar Media CIC的研究与咨询部负责人徐凌蓓分析道：“微信在前台设置了10万+的阅读量显示上限，但我们监测到真实的文章阅读量要远远高于这一数字。在我们监测时间段内前100名阅读量最大的文章都高于150万次，最高的达到了856万次。这说明了微信上文章的质量差距很大。”

“微信上‘鸡汤’内容的受欢迎程度达到了爆发式的增长，因为有很多用户需要心灵慰藉。不过，我们认为原创的，利用了多媒体素材的，与当时热门话题有关的内容最有可能获得病毒式传播，”徐凌蓓表示。“从品牌的角度来说，它们在微信上需要打造出自己的内容风格，也可以与专业的微信原创大号合作以最大程度发挥微信传播的力量。”

随着中国社交媒体格局不断演变，微博已经成为了人们谈论明星最集中的平台。本次报告的微博研究部分发现在2014年12月16日至2015年12月15日的一年中，被提及次数*最多的50个明星共被提及了1.1亿次。男孩组合最受欢迎：TFBoys在前50大明星中占了四位，而EXO的现任及前成员则占据了六个席位。周杰伦，霍建华和郑爽虽然没有微博账户，但也依然名列前50名。这50大明星平均每个人有2358万微博粉丝，平均每条微博会触发43395次评论和转发。

徐凌蓓指出：“在过去一年里，年轻英俊的90后00后跨界男艺人成为了娱乐圈里最红的一批人，他们的成功很大程度上来自于微博上粉丝对他们的力挺。同时，根据热门网络小说改编的电影和电视剧去年也获得了巨大的成功。品牌应该借力流行的文化主题来提升自己的品牌形象。”

H5报告： http://datanews.caixin.com/mobile/kantar/

从100PV到1亿级PV网站架构演变

Sat, 23 Jan 2016 10:38:38 CST

一个网站就像一个人，存在一个从小到大的过程。养一个网站和养一个人一样，不同时期需要不同的方法，不同的方法下有共同的原则。本文结合我自已14年网站人的经历记录一些架构演变中的体会。

1：积累是必不可少的

架构师不是一天练成的。

1999年，我作了一个个人主页，在学校内的虚拟空间，参加了一次主页大赛，几个DREAMWEAVER的页面，几个TABLE作布局，一个DB连接，几行PHP的代码嵌入在HTML中，再用FTP传到服务器上就可以给别人展示一个网站。

2000年，个人主页已经不能满足好奇，在当时的网管中心管起几台机器，作起网线水晶头，用ALL PEOPLE SEEMS TO NEED DATA PROCESS的理论开始认识了7层网络模块（面试技术员工时，经常会问这些网络基础知识的理解）。有了基础理论的武装，我也开始配置各种服务来玩LINUX，AIX和FREEBSD这些系统。面对各种原理不懂的系统，目的只是想尽办法去解决网站需要的各种基础服务。当时搭建了REALSERVER流媒体服务，各种开源FTP下载服务，BATTLENET游戏网关，APACHE（keepalive等配置，http报头相关的知识也是面试的老客户），DNS，QMAIL等服务给学校的学生使用；

网站有近10万PV的时候，开始考虑如何作扩展拆分，MYSQL的MASTER SLAVE作读写分离，MYSQL的索引优化是当时唯一会使用的DB性能优化方法。这个阶段基本上能解决需求，同时也遇到瓶颈，不知道访问量再大一个数量级，怎么办?明显感到技术能力不够。当时受限于网站的量一直没有新的数量级的突破，导致了几年内技术工作以维护为主，体验着网站日常运维的各种纠结，体力活。而这时期网站的2层架构方法也一再被重复应用到后续的N个网站的搭建过程中，2001年开始的JSP与PHP之争好像对我没什么感觉，因为我还是只会用那种很土的2层架构作着网站：页面中嵌入JSP，连接后端的MYSQL进行数据的CRUD，没有事务，没有考虑数据库读写错误，没有考虑两层系统不可用，因为有问题只需要重启，有报错只需要改JSP后刷新页面。作网站确实是体力活。

2005年，在道富参与了FXCNG项目，用MULE ESB，接触到MULE的前几个月还没有意识到这个系统在架构中的位置。直到半年后，在与第三方系统集成的应用中，才发现，这样的一个系统就是传说中的中间件，他可以专业的解决一部份系统的职能，比如当时的消息和远程调用代理。这时候我逐步有了一些架构观点，一个大型的应用系统中，是需要隔离一部份技术职能，让系统责任单一，方便技术维护和团队扩展，专人办专事。

2006年，阿里软件，一个全新的开始。进入阿里软件的前三个月在马总的老家，淘宝的发源地：湖畔花园小区，2楼的4室两厅里进行了封闭式开发，很累，但很兴奋。这段时间，我参与了一个全新外贸ERP系统的搭建。虽然只作为一名普通的JAVA开发工程师，仅负责一个很小的模块开发，但还是正式体会到一个大型系统的初创过程。这段时间对MVC的架构理论有了深刻的理解。MVC三层架构比2层架构带来的更好的技术扩展与团队扩展能力让我映像深刻。M层负责DB逻辑的CRUD，架构师们开发出了大量的中间层JAR包，完成了DAO层，DO的封装，M层也完成了SERVICE层，完成了BO的封装，接口包的封装，系统使用了最常用的工厂、单例、FACACE等模式（直到现在，我面试人还是常常只会问这些基本的模式）。V层的模板隔离，前端开发可以在这一层和后端开发一起修改界面（之后，更大规模的团队连这一层都可以再分离）。C层完成输入输出的基本校验和检查然后调用后面的服务层功能或作转发。简洁朴素的结构生命力是比较持久的。直到现在，MVC还是具有很强的生命力，在更种大型网站中承担重要架构骨架。

07年，我对应用层，服务中心层，持久层三层架构并没有多少的实践应用和理解。因为MVC对于初创系统或中小型网站，20人左右的团队规模来讲，已经适用。换个角度看，当时在3个月内作出一个完整的ERP系统也只用使用MVC，再选进的架构也需要考虑网站发展的阶段。用户一边使用，工程师一边迭代改进架构，这个方式是作网站，不是传统应用软件开发。ERP本身源自传统应用软件领域，我们在用互联网的方式作管理软件，最大的挑战应该是这种边作边改进架构的理念。07年，这个理念之争逐步在团队内达成了一致，架构师们小心的平衡着业务和架构，这个网站高峰时，也支撑到了日访问量近千万的级别，没有闪架。

08年，阿里软件开放平台，又是一个新系统。全新的系统架构总是可以得到足够的时间来考虑末来1到3年的增涨。实际上，互联网系统，我们感觉只能考虑到一年的架构。这一年，我参与架构设计，开始理解了三层架构的价值与扩展能理，服务中心开始搭建，因为这个系统将接受的几百万在线的旺旺用户访问，所以部份系统开始考虑服务中心，想把业务逻辑聚合到服务层，由统一的团队进行扩展维护。另外，随着两年下来小的业务系统越来越多，小机上的oracle连接数也吃紧了，服务中心的需求越来越大。首先进行的是用户中心，想法是集成整个集团队账号体系，基于『旺号』体系。这个用户中心项目有个响亮的名字：UDB，项目过程可以写一本书。这里不再展开。

《SAAS架构设计》这本书，针对的是软件平台的早期ISV用户。现在的眼光来看，这书写的过于简单，正如十年后再来看今天我的写的这个笔记一样。

09年，加盟了刚刚成立的aliexpress部门。经历了两三个应用的小系统到亿级PV的在线交易系统。遇到了很多问题，体会到一个小系统与大网站不同阶段架构的演变过程有不同的难处。

下文从不同维度分享亿级PV网站架构下我的体会和观点。

2：知识结构

网站架构师有很多，有科班出身的，有美术专业的，有生物专业的，有学物理的，有派出所警察出身的，我觉得都是OK的。我也接触到了这些架构师，非常有特点，在很多技术领域有自已专深的。英雄不问出路，好汉不提当年勇。架构师知识背景可以不同，个人看法是不同领域的人作网站架构可以带入很多交叉的思路。就像种树的人再去种花，其实也是可以看到一些共性的总结抽象。

网站架构师需要有编程的经验，从基本的算法，常用的设计模式，多线程开发，远程调用，不同类型数据源使用，这些是面试的时候看得基本功。我认为一个资深的测试专家一定是开发高手，一个架构师必须也是有长期的开发经验，很多性能优化是要从一行行代码优化起的。试想在一个被调用1000万次次每天的页面，一行代码如果每次都走到，每次少运算1ns,也可以节省不少的电力。我为环保作贡献，我骄傲。

网站架构师需要对网络环境有很好的知识理解。架构问题是需要考虑网络部署。比如系统因不可用而发生切换的时候，从一个机房切到另一个机房，要考虑网站的服务对用户访问速度上会有多大影响。这时候的技术方案可能是切DNS，也可能是切前端的跳转机，或是底层部份服务调用到另一个机房。对于这类切换的方案，架构师需要计算网络时间的开销带来的QPS影响，和用户体验上的延迟，每个请求估算需要精确到ms级。如果是全球范围内DNS切换，需要知道DNS刷新的时间经验周期，比如：全球更新在1小时左右，而80%的地区用户会在20分钟内刷新，这样系统带来的业务影响会有多大。

网站架构师需要对网络协议有深入的理解。HTTP协议是最基础的，无论是SESSION还是COOKIE在HTTP协议基础上怎么应用，COOKIE的大小，数量，浏览器是怎么处理HTTP协议的。这些基础有关键时候会影响业务的进行。比如，SAFRI浏览器对第三方COOKIE是禁用的，某功能跨域写COOKIE的时候每次都会重新生成COOKIE，直接导致系统统计用户UV的时候，数量增大，影响各种转化率的计算。HTTP协议还需要考虑本身的连接管理池大小和连接是否KEEPALIVE，这些细节很多时候成为架构上扩展能力的瓶颈。一个静态页面服务的HTTP MAXCLIENT设置为2500，机器只有10台，很可能在一次中小型活动中连接数到顶，用户部份请求无法满足。

架构师需要考虑数据格式带来的性能影响。很多远程系统调用走的是HTTP协议为基础，数据格式为纯文本或JSON，或XML等，这类调用需要考虑数据的序列化和反序列化，这个工作是CPU开销型的，对性能优化上需要有针对性。QPS高的系统RT一定会短，但RT短的系统不一定比RT高的系统能表现更好的QPS。

架构师需要有很好的数学能力，计算一个QPS里系统从网络请求发出，到网络的IO时间，DB的磁盘读写时间，CPU运算时间，再到数据库连接数，数据分库分表容量规划，都需要有精确的计算。因为容量计算不正确带来问题也是非常多的。比如一台小机上ORACLE的连接数开了2000个，而应用系统由于不断的扩展，小业务系统不断加入，大型促销活动前，临时机器的不断上线，很快就把DB连接数用完，引起业务部份不可用。架构师需要去合理估算每种应用的服务能力，以及他对DB等资源的合理连接数。

加构师对JVM的内存分区及管理策略要有深入的了解，GC的频率可以发现很多系统容量的问题。一个OLD区不断加大的系统，伴随YGC高频发生，加上TCP机器连接数很可能高，可能是要是机器了。一个业务功能不断叠加的系统，很可能PERM区会需要加大设置，否则容易OUT OF MEMORY。

加构师需要精读《数据库系统概念》这类书，对不同DB的索引原理和库表存储结构有了解，我们可以不是ORACLE ACE，但一定要听得懂ACE的DB架构和性能优化方面的建议。并且在原则上，前端用户系统架构上不要出现直连DB的设计，这是亿级PV架构的基础设计保障，特别是一些营销类功能系统，短时并发大的页面不能有DB直连，一些小应用可例外对待。

架构师需要很好的学习能力，技术是不断变化的，昨天用DUBBO，明天可能要换HSF；今天MEMCACHE，明天可能REDIS；今天刚刚把应用拆分，明天可能就要合并。公司外的技术社区还不断有一些好的开源中间件和框架出来，需要不断学习，关注。大网站的架构模式不一定合适小网站，新中间件和框架实施需要考虑运维成本和学习推广成本，架构上要选合适当前阶段的。架构师需要和不同类型的专业人才沟通，所以要能快速理解并学习不同专业的知识去补充自身的知识结构不足。

架构师需要理解业务，在一些业务系统型的网站，业务架构师也显得异常关键，比如像交易型系统，支付型系统。业务架构师需要解决业务层次结构，业务边界划分，业务优先级与技术优先级的平衡。传统软件的系统分析师不知道是否也干这角色？但互联网的业务架构师要求更高，应该是建立在系统架构师的基础上再看高一层，通过业务和技术的综合影响力去帮助网站取得合理的架构，更好得拿到业务结果。

网站架构师的知识结构是宽又深的。

3：设计理念

每个架构师都会有一些自已原设计理念和原则。我的基本思路是：架构要作到至少1年的预见性（半年不叫预见性，因为方案实施要半年）。设计的目标是尽量让系统可以水平扩展，并利于。当然，有些业务处在生存的边缘，可能架构方案只有几个月的生命力。但一些成本不高收益稳定的架构理念，不管什么时候都是值得优先考虑的。以下是架构设计的一些常用手段。

1>：异步换同步：

系统中的很多调用是可以异步化的，包括WEB界面上的AJAX异步，还有服务端的消息型异步；AJAX调用的应用要注意把这种类型的应用集中到一个隔离的服务系统中，以方便在必要的时候进行服务降级。
AJAX调用一般都是界面上非同步非强依赖的功能点；服务端异步的系统可以让服务端的请求RT变短，提升服务器QPS，同时减少应用强依赖。
一个小型系统（峰值万级消息per second）的服务端异步消息可以借助RMDB的表实现，当网站规模变大时（峰值百万级消息每秒），消息系统需要有一个中间件，负责消息持久化及数据CRUD管理；再大点的时候，消息中间件的分布式与可用性会有更高要求，需要综合使用多种架构设计理念；

同步换异步对软件工程上的好处是，可以把一个子系统的不同模块分别由不同的人开发维护，调试期间，两个模块也不会有很强的依赖。提高开发并发性。

2>: 集中变分布：

一个网站小的时候，很多业务都会在一两个应用系统中实现。比如一个电子商务网站，从登录，到首页，到搜索，到产品DETAIL，到购物车，下单支付，风控，订单管理，用户中心到售后用户纠纷流程。网站小的时候，这种一体化的业务架构模式在网站规模小的时候，无论是研发团队规模还是硬件成本都是比较低的。这个时期的扩展性一般只需要作到LB后面挂一片集群。服务器资源利用率这时候也是比较高的。

随着业务规模扩大，需要把系统独立分拆出来，基本原则是：不同维护策略和服务等级的页面和服务不要放在一个应用容器中，最好不要放在一个虚拟机或物理机上。发生过很多次紧急事件。因为大流量页面上带着一个小的AJAX请求，把提供AJAX服务的WEB应用压死。而这种AJAX应用平时又是比较容易在容量评估的时候被忽略的。也比较难以管理AJAX，因为一个前端开发工程师很可能因为一次小的运营活动加上一个调用。服务器端不同服务类型的功能也需要分拆到不同服务中，服务的聚合一定要有一定的原则，并不断的调整治理聚合服务内容。如果把一个文件生成类的业务功能（比如用户批量导入导单）和一个下单的服务放在一起，很容易让下单这类核心主干逻辑功能受批量导出功能影响，当架构师需要作服务降级时，不得不侵入代码层作服务功能的隔离。

架构上的基础设施也需要有隔离策略。比如一个功能先后需要完成读数据，再生成文件，再发消息，再写数据库，写CACHE，再把数据同步到另一个机房。这一串逻辑中，除了异步化策略之外，还需要考虑一些基础职能的隔离，比如把生成文件的功能封装成一个服务，文件存储也需要从集中式变成分布式。T级可以考虑NAS类的集中式存储方案，P级和Z级的文件容量一般是需要考虑分布式文件系统方案，开源的也比较多。数据库与从集中式变分布式是现在流行的方案，之前我们小网站的时候常用MASTER SLAVE，然后再大点搞双MASTER写，多SLAVE读；再大点流量或者应用系统过多时，数据库的连接数也会受到考验，这时候分布式的分库分表方案是必须的。当然对架构师来讲，如果能用上一种云方案，不需要业务架构师考虑分库分表方案，那会更有幸福感。同步系统也需要考虑集中变分布的策略，两个机房或同一机房两个系统进行数据镜像同步，需要考虑多通道，分表，分字段，分库进行同步，有时候还需加入一些商业逻辑作为同步数据的判断。非镜像同步的时候，同步系统还需要考虑业务逻辑之间的事务特性。

3>: 架构层次化：

早期网站一般是两层架构，应用层+数据库层；现在大型网站经常采用三层架构，应用+服务中心+持久层，这三层分别在不断的增强可用性和可扩展性；理论上增强后的三层可以称为saas+ paas +iaas。
我把saas层看作现在淘宝开放平台上的第三方ISV应用，独立发展，互不影响，SAAS层数据隔离，运维隔离。SAAS层还可以自建分布式CACHE，集中式CACHE或简单的本机CACHE。电子商务网站本身的系统也可以把这个当成架构设计的目标之一，把自已的应用层作成像第三方APP一样的存在，这样发展效率和扩展性都会高很好。

paas层是我理解中的服务中心，具有应用逻辑的一个业务层服务中心，比如UIC用户中心，IC商品中心，TC交易中心等等，一般这样的一个服务中心会被多个上层SAAS应用所调用依赖。对一只被一个SAAS应用依赖的服务中心是否值得建立，这个要看投入产出比，一般小网站可以直接让应用连着DB，而中型网站也可以考虑在一个应用内部分为两层，先从JAR包层面隔离，PHP的话可以用代码目录结构上来隔离。网站更大规模的时候，1：1的依赖也是值得建服务中心的，因为这样可以隔离下面的持久层和上面的应用层，并且可以在PAAS层隔离考虑缓存等职能，可以考虑在这一层实现流控，隔离对DB连接数量的依赖。PAAS层要尽量实现自已的水平扩展，服务无状态。

iaas层负责实现持久层，一般数据源都在这一层，常见网站的数据源不外呼这四种：RMDB（这个玩转了近20年了），KV（最近10年比较热，KV可以分为内存型或持久型，对于持久型的KV，可以把数据挂到各类存储中），inverted index or file(倒排索引类），FILE SYSTEM（各类传统文件存储或自已实施的小文件中间件，普通文件中间件）。

这三次之间是1：1：1的关系建立，还是N:1:1，或是N：N：N，都是需综合考虑的。曾经有一次，我在设计一个系统的时候，为应用层界面设计了一个用户列表的头像显示功能就引发了一个调用比例考虑不全的重大问题。当时，用户有个旺旺的第三方游戏插件，插件主界面上有个好友列表，每个好友都有个头像读取的请求。假设用户每天9点左右登录旺旺的人中会有10%的人马上去玩这个游戏，9点左右在线按100万人算，每个人的好友有平均50个，则每天9点左右用户头像URL的HTTP请求量会有50*10万，产生近500万个突发的HTTP请求。虽然有CDN，依然存在很大的头像请求容量的不足，并且服务端获取用户好友列表信息的接口调用并发量也会很大，如果没有提前对第三方应用进行接口调用限制和设计上的规范化，调用比例很可能带来极大的系统伤害。

应用层与服务层之间的调用与依赖会随着网站规模变得越来越复杂，当网站小的时候，这两层直接的固定协议调用是可以接受的，调用方知道服务端的IP LIST，也知道调用的SOCKET，还有调用的协议；规模更大的时候，调用变成N：N的方式，随然有层次，但已经成网状结构，这时候需要服务治理与服务依赖的监控，流控等基础设施。对于服务治理，引入服务中间件，比如阿里的DUBBO和HSF是比较成熟的可以处理每天亿级的服务调用量并作好配置维护，调用统计，分布式，名称服务，流控，路由等基础职责，业界开源的也有很多；服务层还需要处理异步消息调用与消息通知的机制，这时候需还要配全一些消息中间件。

4>: 功能分解化

网站的应用级功能在网站小的时候一般都在一个物理机上，但在网站发展过程中，有些模块经常因业务原因发生变化和升级，有些模块流量和调用量比较大，有些模块处理的及时性和异步性要求不同，有些模块与外部调用特别多；有些模块经常报异常，有些模块IO多，有些模块偏CPU计算型。不同的模块需要随网站规模发展进展不断的分解。

架构师之道在于庖丁解牛一般的理解业务系统的复杂度和结构关系，进行合适的分解和聚合，这是我理解业务架构的核心贡献之一。一个业务架构师首先是一个技术架构师，没有技术背景无法理解系统内的技术边界，没有业务能理无法预见架构变化的趋势，也无法预见业务系统的流量变化。

5>:服务中心化

服务化有很多方式，三层网站架构下，亿级PV的网站最好能把同一业务逻辑被多方使用，边界清楚的功能隔离出来作为服务。服务中心可以封装对持久层的访问，形成带有业务逻辑的一种原子性服务，加上一些事务性控制的多个原子服务。服务中心不要有界面，管理好服务的粒度，可用性，高并发下的性能，以及服务路由，监控为主要任务。

6>:结点监控化

亿级PV网站的监控是非常关键的，很多系统问题，服务问题，流量问题，性能问题，业务异动都需要通过监控来发现。监控可以分为几类，一类是快照型的，像搞活动的时候特别需要一个大盘监控。可以看全局的流量，交易量，访客分布，来源分布，系统LOAD，DB连接数，CPU和网卡口子的状态；一类是基线型，可以看到每小时，分天同一个指标的变化历史。看到一个页面响应速度，服务器RT时间的变化；一类是关键业务逻辑结点的按需统计，比如需要看一下某页面改动后某个页面点击量和原来的差别。

监控会带来系统的性能损失，特别是在线打点，不管你是在容器层面作的，还是在业务逻辑侵入方式实现的；另一种是通过日志分析，可能实时性差一些，比如有3分钟延迟；还有一类是基于RMDB直连的分析，一般会在备库上把数据导出来作分析，实时性好一些，但对备库或主库DB有压力。还有一类是基于消息的分析来实现监控。让一些关键结点有动作时，发现异步消息到消息队列上，然后监控系统的抓取模块和正常业务逻辑一样去订阅消费这些消息。这种方式需要监控团队与业务逻辑有协同，这对长期运维有挑战。

4：基础架构

亿级网站的基础架构是较多时间投入的一个工作，小网站一般没有中间件的概念，基础架构投入精力不多，但一样可以运行的很好。对于小网站，DB也像是一个中间件。一个亿级PV的网站，要看PV，也要看UV。这两个数字的规模对系统的技术架构挑战点是不同的。PV流过的系统和UV经过的系统路径不同，比例可能也有所不同。

架构师需要分析这个路径，好比庖丁解牛般的分析。在合适的节点引入中间件。比如一个亿级商品量的系统，需要从商品的POST服务性能，图片存储空间，图片缩图处理服务，多语言商品信息翻译，商品信息与图片在不同系统之间同步的服务，图片CDN服务，商品信息更新的通知和提醒服务，商品搜索服务，商品统计类信息服务等不同阶段和信息模块的CRUD中引入中间件，让系统可扩展，可承受高并发。

在合适的时间点引入中间件提升架构水平扩展能力，只是关心可扩展是不够的。基础架构不只是要关心系统的可扩展能力，还需要关心可用性。系统达到亿级PV后，每停机1分钟损失的流量都都是很大的。系统架构师预见并规划好系统容量。对于预料之外的超过容量的PV进行服务降级，限流，针对系统不可用时提供组织保障机制，用提前制定的紧急响应流程让不可用时间尽可能变短，这也是很重要的架构师职责。异地机房容灾或是同一机房的系统切换也应该有定期不定期的演习。对于不同国家之间的机房灾备，系统必须考虑机房之间的调用延迟，国内同步系统一般在10MS之内的延迟是可以接受的，对于非同步系统，延迟可适当放大，这种延迟的时间需要根据业务特性进行评估。对于中美之间的200ms级别的延迟，系统需要有合理的评估，尽可能不要有中美服务同步调用。这个200ms的延迟来自网络物理传输，来自路由器路由算法的延迟，也有来自机房本地的信息号交换过程，是刚性的，很多大型电商网站都面临这一问题的挑战。EBAY， AMAZON，alibaba和GOOGLE这类的网站架构设计时，一定会有很多系统不得不讨论这一延迟带来的系统方案区别。有时候网站会因业务原因考虑建完全独立分站，有时候会灰这种架构问题的影响考虑作单写还是双写。如果是全球机房，则这一问题会变得更复杂。数据同步和分发会是一个关键的中间件和可用性设施。

性能是大规模网站的重要基础架构问题。网站应用层，我们关心系统的关键页面的QPS值，比如在100并发下，系统某页面能接受每秒几次正常调用；综合页面的QPS也是需要关注的，特别是当一个前台应用内的界面比较多的时候。WEB应用的QPS可以通过服务端日志中的COOKIE来回放，进行线上线下的压测来取得一个有信心的数字。前台的WEB应用原则上不要有直接的DB层访问，小规模网站者需要平衡投入产出比，有时候作一些TRADE OFF也是值得的。对于服务层的应用，一般关心TPS，因为调用都来自WEB应用系统，所以通过COOKIE回放这种调用是不可能。持久层的TPS和上两层的QPS，TPS量之间存在一个比例。多个数据库的TPS可能对应一个服务层的一个TPS。这对于系统的容量和机器的扩容估主也非常关键，需要维护这么一个状态的快照。架构师才能让这个状态时刻保持胸有成竹。发现关键资源瓶颈对于分析QPS和TPS是非常关键的。

服务治理除了作抽应用层服务中心的工作和JAR包之间的依赖管理之外，服务强弱依赖也是需要有一个系统来监控和管理的。随时知道一个新上的系统在依赖哪个服务，或被哪个应用依赖，这是架构师工作的必要工具。架构师从输出经验，到提供工具平台，是一个必然的过程。小网站需要一个架构师的经验快速搭建，大规模网站则不可能靠一个人的经验来进行判断，需要更多的数据采集和分析生成规则。监控系统是一个网站健康状态的指示仪。

部署架构是网站进入10亿级规划，99.99%可用性要求下必然关注的问题。无论是EBAY还是AMAZON都在部署上有很多投入。单一的机房由于电力，机柜等问题，经常出现部署上的硬件约束；容灾与不同地区访问体验要求异地机房能提供在线同时的服务。部署上需要考虑是全机房的对称部署，或是应用不同分级的分区部署。比如持久层统一，服务层与应用层多机房对称部署；或是持久层与应用层服务层完全对称，但数据分区；这种分区需要考虑买家维度、卖家维度，或是IP区域分区，不同区生成的数据通过同步系统实现各区的最终一致。以订单为例，分区是可以让美国买家创新的订单写在美国分区数据持久层，然后异步消息生成同步任务，数据同步到卖家所在的分区。

基础架构的工作还有很多，架构师责无庞待。if not me, who?

5：软件工程

架构师除了作经验，工具和代码输出之外，还需要关注工作机制的建立和人员的传帮带。发布流程，可重复使用的灰度发布ABtest方案，代码管理规范，代码开发规范，人员梯队，业务优先级判断，中间件和平台化工作推进都是每一天的日常工作。有时候帮测式工程师去搭好并维护一套测试环境，也算是本职工作。

有些架构师被称为PM型架构师，也有被感觉像RA型的，偏咨询师型的架构，偏业务型的，偏算法型的，偏性能调优的，偏中间件和服务治理的，偏基础架构型的，这个是看网站发展阶段的需要，缺什么，作什么。关键是看架构在软件工程过程中对产品，对团队的输出是否能解决问题，拿到结果！eat what, what strong。

6：不同类型业务系统技术架构的差异化

每个网站架构都有不同，完全复制是不科学的。哪怕现在想再作一个淘宝网，光靠把淘宝全部几万台机器搬去是不行的，搭不出一个淘宝网。完全复制淘宝网的建设过程也不是靠谱的。可以复制或参考的是架构的原则和经验教训。不同类型的业务系统有不同的业务发展过程，业务架构发展演变过程不同；技术架构发展过程也不同，技术解决问题的重点不同，有些网站一开始需要解决的问题是如何从一个老网站中改版和分拆，有些则是全新的搭建。有些网站自建物流系统，有些则是与多家物流第三方对接系统。比如：有些网站交易模式简单，有些则需要去支持各种不同交易模式，像多次付款，预售，批发，团批，阶梯价格。。有些网站只需要解决支付宝对接，有些则自建网银与支付系统，风控系统。

架构师要小心经验的惯性。大网站的方法不一定合适小网站。小网站的格局也不可能适用大规模。时代在变，地点在变，因时制宜，因地制宜。

7:小趋势的生命力

开放平台是胸怀: 06年，我们都谈开放平以。其实这个理念最初考验的是网站拥有者的胸怀。你是否愿意让其它人进来操作你的数据，是否愿意看到别人作出比你理好的应用层系统？甚至是一些服务层的系统？

FB与微博是社会化：07年，我们都讲SNS。SNS无处不在，因为他本质上是一个社会化的思路下的技术系统表示。愿意接受UGC，能否以社会化的方式让系统内的数据产生和管理发生。原意为这些社会化的小数据作系统，才可以最终生成大数据的拥有者。

电商团购是心理：09年，GROUPON火了，大家都团购。团购本身是没有什么技术创新的。有人说O2O是他的模式创新，可是，难道在原来的C2C网上不能实现吗？就像超市里把促销的商品放在货架边上的花车上，和放在货架里有本质区别吗？区别在于心理，用户体验上的区别。有时候这也会是一种竟争力，是一种常态化的经营思路，但不会主流。

移动PC平板是体验：10年，平板热。这种比手机屏大，比笔记本屏小的东西，满足了某些场景的方便性需求，体验创新很有机会。

Pinterest电商导购是基尼：11年，导购网站火了。瀑布流热了，国内的蘑菇街，美丽说火了。从根本上来看，导购是解决了网站商品与用户流量之间的基尼关系，把基尼指数变得更小一些。否则80%的流量一直放在20%的热门商品和大卖家的店里，市场规模会有影响。作生态圈好一些，有活路的人多了，市场才稳定。

外贸电商是库存：12年，外贸电商预热了，GOOGLE TRENDS里显示，才作两年的ALIEXPRESS的指数超过了DHGATE这个作了五六年跨境电商B2B网站，也越来越接近ALIBABA。COM这个老牌SOURCING网站。外贸从批发变小单是什么背景？我想本质上他的销售链变了。MIC基本还没变，没有变成快速反应能力的供应商，但出品商变成了拥有小单外贸客服能力的80后；进口商变成了国外的RETAILER，国外的超市变成了最终消费者。

体感外设是物联：13年，各类体感设备越来越丰富。什么手势，什么随身拍，什么位置设备，拍照设备。好玩。按马斯少理论来讲，工作是生存需求，买房子是安全需求，买车和大房子是社交需求，体现在的单位和职位是尊重需求，买体感设备，那是自我实现。

BARABASI预见了末来，小趋势改变末来的本质是一种叫幂律的无形之手，像我们所熟知的长尾。据说人类行为90%是可以预测的，人类的90%的形为是可以采集的。架构师从不同观察者的角度理解他们的观点有时候会有更多的预见性。

8：LAST BUT NOT THE LEAST

作网站如作人。架构的是人的骨架，人还需要配一个好的心态：心胸+态度。心胸是装进不同声音采集到信息的基础，态度是推广服务他人的手段。一个新架构方案下去，一定会有反对的声音。如何去说服别人现在就启动架构升级或转型方案，是需要带着心态去的。毕竟一个大的架构方案是需要很多人一起努力才能拿到结果，不是一两个英雄人物能造就的。架构师的工作方式是主动的，而不是问题驱动的。能解决问题的架构师是牛B的，能预见问题或提前准备的架构师是称职的，这才是技术促进业务。

作者：叶军

协同过滤推荐算法的原理及实现

Fri, 11 Mar 2016 00:41:22 CST

协同过滤推荐算法是诞生最早，并且较为著名的推荐算法。主要的功能是预测和推荐。算法通过对用户历史行为数据的挖掘发现用户的偏好，基于不同的偏好对用户进行群组划分并推荐品味相似的商品。协同过滤推荐算法分为两类，分别是基于用户的协同过滤算法（user-based collaboratIve filtering），和基于物品的协同过滤算法（item-based collaborative filtering）。简单的说就是：人以类聚，物以群分。下面我们将分别说明这两类推荐算法的原理和实现方法。

基于用户的协同过滤算法（user-based collaboratIve filtering）

基于用户的协同过滤算法是通过用户的历史行为数据发现用户对商品或内容的喜欢（如商品购买，收藏，内容评论或分享），并对这些喜好进行度量和打分。根据不同用户对相同商品或内容的态度和偏好程度计算用户之间的关系。在有相同喜好的用户间进行商品推荐。简单的说就是如果A,B两个用户都购买了x,y,z三本图书，并且给出了5星的好评。那么A和B就属于同一类用户。可以将A看过的图书w也推荐给用户B。

1, 寻找偏好相似的用户

我们模拟了5个用户对两件商品的评分，来说明如何通过用户对不同商品的态度和偏好寻找相似的用户。在示例中，5个用户分别对两件商品进行了评分。这里的分值可能表示真实的购买，也可以是用户对商品不同行为的量化指标。例如，浏览商品的次数，向朋友推荐商品，收藏，分享，或评论等等。这些行为都可以表示用户对商品的态度和偏好程度。

从表格中很难直观发现5个用户间的联系，我们将5个用户对两件商品的评分用散点图表示出来后，用户间的关系就很容易发现了。在散点图中，Y轴是商品1的评分，X轴是商品2的评分，通过用户的分布情况可以发现，A,C,D三个用户距离较近。用户A(3.3 6.5)和用户C(3.6 6.3)，用户D(3.4 5.8)对两件商品的评分较为接近。而用户E和用户B则形成了另一个群体。

散点图虽然直观，但无法投入实际的应用，也不能准确的度量用户间的关系。因此我们需要通过数字对用户的关系进行准确的度量，并依据这些关系完成商品的推荐。

欧几里德距离评价

欧几里德距离评价是一个较为简单的用户关系评价方法。原理是通过计算两个用户在散点图中的距离来判断不同的用户是否有相同的偏好。以下是欧几里德距离评价的计算公式。

通过公式我们获得了5个用户相互间的欧几里德系数，也就是用户间的距离。系数越小表示两个用户间的距离越近，偏好也越是接近。不过这里有个问题，太小的数值可能无法准确的表现出不同用户间距离的差异，因此我们对求得的系数取倒数，使用户间的距离约接近，数值越大。在下面的表格中，可以发现，用户A&C用户A&D和用户C&D距离较近。同时用户B&E的距离也较为接近。与我们前面在散点图中看到的情况一致。

皮尔逊相关度评价

皮尔逊相关度评价是另一种计算用户间关系的方法。他比欧几里德距离评价的计算要复杂一些，但对于评分数据不规范时皮尔逊相关度评价能够给出更好的结果。以下是一个多用户对多个商品进行评分的示例。这个示例比之前的两个商品的情况要复杂一些，但也更接近真实的情况。我们通过皮尔逊相关度评价对用户进行分组，并推荐商品。

皮尔逊相关系数

皮尔逊相关系数的计算公式如下，结果是一个在-1与1之间的系数。该系数用来说明两个用户间联系的强弱程度。

2, 为相似的用户提供推荐物品

为用户C推荐商品

当我们需要对用户C推荐商品时，首先我们检查之前的相似度列表，发现用户C和用户D和E的相似度较高。换句话说这三个用户是一个群体，拥有相同的偏好。因此，我们可以对用户C推荐D和E的商品。但这里有一个问题。我们不能直接推荐前面商品1-商品5的商品。因为这这些商品用户C以及浏览或者购买过了。不能重复推荐。因此我们要推荐用户C还没有浏览或购买过的商品。

加权排序推荐

我们提取了用户D和用户E评价过的另外5件商品A—商品F的商品。并对不同商品的评分进行相似度加权。按加权后的结果对5件商品进行排序，然后推荐给用户C。这样，用户C就获得了与他偏好相似的用户D和E评价的商品。而在具体的推荐顺序和展示上我们依照用户D和用户E与用户C的相似度进行排序。

以上是基于用户的协同过滤算法。这个算法依靠用户的历史行为数据来计算相关度。也就是说必须要有一定的数据积累（冷启动问题）。对于新网站或数据量较少的网站，还有一种方法是基于物品的协同过滤算法。

基于物品的协同过滤算法（item-based collaborative filtering）

基于物品的协同过滤算法与基于用户的协同过滤算法很像，将商品和用户互换。通过计算不同用户对不同物品的评分获得物品间的关系。基于物品间的关系对用户进行相似物品的推荐。这里的评分代表用户对商品的态度和偏好。简单来说就是如果用户A同时购买了商品1和商品2，那么说明商品1和商品2的相关度较高。当用户B也购买了商品1时，可以推断他也有购买商品2的需求。

1, 寻找相似的物品

表格中是两个用户对5件商品的评分。在这个表格中我们用户和商品的位置进行了互换，通过两个用户的评分来获得5件商品之间的相似度情况。单从表格中我们依然很难发现其中的联系，因此我们选择通过散点图进行展示。

在散点图中，X轴和Y轴分别是两个用户的评分。5件商品按照所获的评分值分布在散点图中。我们可以发现，商品1,3,4在用户A和B中有着近似的评分，说明这三件商品的相关度较高。而商品5和2则在另一个群体中。

欧几里德距离评价

在基于物品的协同过滤算法中，我们依然可以使用欧几里德距离评价来计算不同商品间的距离和关系。以下是计算公式。

通过欧几里德系数可以发现，商品间的距离和关系与前面散点图中的表现一致，商品1,3,4距离较近关系密切。商品2和商品5距离较近。

皮尔逊相关度评价

我们选择使用皮尔逊相关度评价来计算多用户与多商品的关系计算。下面是5个用户对5件商品的评分表。我们通过这些评分计算出商品间的相关度。

皮尔逊相关度计算公式

通过计算可以发现，商品1&2，商品3&4，商品3&5和商品4&5相似度较高。下一步我们可以依据这些商品间的相关度对用户进行商品推荐。

2, 为用户提供基于相似物品的推荐

这里我们遇到了和基于用户进行商品推荐相同的问题，当需要对用户C基于商品3推荐商品时，需要一张新的商品与已有商品间的相似度列表。在前面的相似度计算中，商品3与商品4和商品5相似度较高，因此我们计算并获得了商品4,5与其他商品的相似度列表。

以下是通过计算获得的新商品与已有商品间的相似度数据。

加权排序推荐

这里是用户C已经购买过的商品4,5与新商品A,B,C直接的相似程度。我们将用户C对商品4,5的评分作为权重。对商品A,B,C进行加权排序。用户C评分较高并且与之相似度较高的商品被优先推荐。

—【所有文章及图片版权归蓝鲸（王彦平）所有。欢迎转载，但请注明转自“ 蓝鲸网站分析博客”。】—

提升网站性能开发的10个技巧

Thu, 22 Oct 2015 09:00:11 CST

随着网络的高速发展，网络性能的持续提高成为能否在芸芸 App 中脱颖而出的关键。高度联结的世界意味着用户对网络体验提出了更严苛的要求。假如你的网站不能做到快速响应，又或你的 App 存在延迟，用户很快就会移情你的竞争对手。以下为大家总结 10 条有关性能提升的经验，以供参考：

1. 采用反向代理服务器(Reverse Proxy Server)来对应用进行加速和保护

其作用主要在以下三方面：

负载平衡 – 运行在反向代理服务器上的负载平衡器会在不同的不服务器间进行传输平衡。透过它，你可以进行无差别的服务器增添。
存静态文件 – 对于直接的文件请求，例如图片文件或代码文件，可以直接存储在反向代理服务器然后直接发送给用户，从而可以进行快速访问并为应用服务器进行减负使得程序性能得到提升。
安全保护 – 反向代理服务器可以进行高安全度配置和对威胁进行识别和监测。

2. 增添一个负载平衡器

为网站增添一个负载平衡器是一个相对简单的变更，但是它可以带来不错的性能和安全性提升。负载平衡器的作用在于在不同服务器间进行传输分发。

负载平衡器的实施前提是有一个反向代理服务器，它在接收到 Internet 通信后把相关请求发送到其它服务器。平衡器的妙处在于它支持两个或以上的应用服务器，使用选择算法来分割服务器间的请求。

3. 缓存静态和动态内容

缓存技术的使用可使内容更快地展示给用户，其处理策略有：在需求发出时更快地处理内容，把内容存放在更快的设备上，或是使内容离用户更近。

4. 数据压缩

压缩技术是一个巨大的潜在性能加速器。其主要作用体现在对图片，视频或音频等文件，能够进行高效的压缩处理。

5. 优化 SSL/TLS 访问

尽管 SSL/TLS 变得越来越流行，但是它对于性能的影响也应得到重视。其对性能的影响主要体现在两个方面：

每当新的连接开启，初始化握手都是无法避免的，即浏览器每次都需要使用 HTTP/1.X 建立服务器连接。
存放于服务器上的加密数据会越来越大，加密后用户读取时也需要进行解码。

那么该如何进行处理呢？

会话缓存—使用 ssl_session_cache 来直接缓存建立新 SSL/TLS 连接的参数
会话 ID 化—把指定 SSL/TLS 的标识/ID 存放起来，但要建立新连接时，就可以直接取用，从而免去重新建立通信的繁琐。
OCSP stapling 优化—通过抓取 SSL/TLS 认证信息来减免建立通信的时间。

6. 部署 HTTP/2 或 SPDY

对于已经启用 SSL/TLS 的网站，一旦结合 HTTP/2 和 SPDY 将能实现性能上的强强联合；因为其结果是会让单一连接的建立仅需一次通信握手。SPDY 和 HTTP/2 的主要特性是它们使用的是单一连接而不是多方连接。

7. 定期更新软件版本

8. 优化 Linux 性能

例如对 Linux 进行以下配置或处理：

Backlog 队列

如果你有一些将要停用的连接，可以考虑增加 net.core.somaxconn。

文件描述符

NGINX 允许每个连接最多使用两个文件描述符。如果你的系统服务的是多个连接，你可能需要考虑增大 sys.fs.file_max 的值。

瞬时端口

当作为一个代理使用时，NGINX 会为每个 upstream 服务器创建临时的瞬时(ephemeral)端口。因此可以尝试加大 net.ipv4.ip_local_port_range 的值来增加可用端口数。

9. 优化 Web 服务器性能

访问日志优化

在 NGINX 中，在 access_log 中加入 buffer=size 参数来实现日志的缓存写入；加入 flush=time 则可实现在某个时间间隔后进行缓存内容写入。

缓存

启用缓存可使连接响应更快。

客户端活动连接

活动连接可减少重连的次数，特别是启用 SSL/TLS 的情况下。

Upstream 活动连接

Upstream 连接指的是连接到程序服务器，数据库服务器等的连接。

限制资源的访问

采取合适的策略来限制资源访问可以提高性能和安全性。

进行 worker 处理

Worker 处理模式就是请求驱动处理模式。NGINX 使用了一个基于事件的模型和 OS 依赖机制来有效地对请求进行分发。

进行 socket 分表

Socket 分表可以为每个 worker 处理创建一个 socket 监听器，当核心委派连接分到给监听器时，可以马上知道哪个处理是即将执行的，从而使处理流程变得简洁。

线程池处理

任何计算机线程都有可能由于单个缓慢的操作而挂起。对于 web 服务器软件来说，磁盘访问是一个性能瓶颈，例如进行数据复制等操作。当使用线程池来处理时，可以把一些响应慢的操作单独地放入某个任务组里面，从而不会对其它操作造成影响。

10. 进行实时监控以快速解决问题和瓶颈

实施实时监控，可以全面掌握系统的运行情况，发现问题解决问题，甚至是找出造成性能瓶颈或运行缓慢的原因。

例如可对如下的问题进行监控：

服务器宕机
连接访问丢失
服务器缓存丢失严重
服务器发送了错误的数据

一名网站数据分析师需要具备这9大本领

Wed, 06 Jan 2016 20:17:02 CST

如果你想成为网站分析师!想加入网站分析这个即有前途又有“钱途”的行业，那么你至少需要具备本文所提到的9大本领。

1、玩转Excel

Excel是一个最原始而且最容易入手的分析工具之一，如果你有少量的数据进行分析和汇总的话，Excel是你的不二之选，结合丰富的函数与公式，你能轻松的得到你想要的数据，如果你懂得计算机语言，会使用VBA进行编程那就更是如虎添翼了，并且还可以轻松的制作棒图，饼图，折线图等图表。但是Excel不可能是完美的分析工具，因为他的数据容量实在是太小了，超过1万行的数据请不要使用Excel。

1.1.常用函数：

1.2.常用功能：

2、网站分析基础知识

了解一些网站分析的基础知识是必须的，你要知道什么是会话，什么是PV，什么是UU/UV等指标值的含义。如下图(摘自《网站分析基础教程第二章》)所示：

3、网站开发的知识

网站分析师通过衡量各种指标值的优劣来评价网站的状况，以及提出改善优化的对策，如果分析师自己对网站的开发和构筑知识一点都不了解，也就不能准确的通过分析指标值的高低衡量网站的运营状况。

作为一名合格的网站分析师，你需要了解一些网站建设和运营的知识，还有网站设计的知识，以及用户体验相关的知识。这样的话你才能提出更有高度和深度的分析报告。

4、网络营销的知识

网站分析师的工作范围从宏观上可以分为“站内”和“站外”两大领域。站内重点在于改善用户体验，优化转化路径，SEO，分析用户行为等站内活动;站外的工作重点则在于如何更多更准确更优质的吸引用户进入网站。

所谓站外的工作主要就是指网络营销，网络营销按照具体的实现方式可以分为：展示广告(DisplayAdvertising)、PPC推广、SEO、邮件营销、视频推广、QQ群推广、博客营销、微博营销、SNS营销等。如果想成为网站分析师你需要学习如下知识：

4.1.广告类型

搜索引擎广告(PPC)

交换链接

横幅广告

邮件营销

传统媒体广告

4.2.广告相关指标

展现数(Impressions)

点击数

点击率(Click-throughRate)

CPC(CostPerClick)

CPA(CostPerAcquisition)

转化率(ConversionRate)

ROAS(ReturnOnAdvertisingSpend)

4.3.SEO知识

主流搜索引擎的排名算法

TITLE,META,Hn,h1等优化

5、测试方法

当网站分析指标的数值变得不是非常乐观的时候，或者你想做一次大规模的推广的时候，也可能是你需要对网站进行改版的时候，作为分析师需要预知改善后的效果是否能够达到预期，这一点是光凭经验很难做到的事情，那么就需要网站分析师聪明的利用师验方法进行验证，这是最直接而且准确有效的方法。

做网站分析师需要学会使用如：A/B测试，多变量测试，用户体验测试等测试方法对改善方案进行预评估，以减少新方案的实施风险。

6、交流能力

作为一名网站分析师，你需要和很多的人协同完成工作任务，其中包括项目经理，产品经理，运营经理，实施经理以及工具提供商等。高效率，准确的交流显得尤为重要。

对于交流来说，语言的表达能力作为最基本的能力要素不可或缺，但想要能顺畅的交流仅仅依靠语言是远远不够的，还需要有一定的资料的组织能力和总结能力，以及团队合作意识。

7、演讲的能力

当以网站分析师为主导进行一次网站的改版或升级的时候，通常的做法是用数字和图表来说服决策层和保守派，但事实上并不那么简单，说服更多人除了靠准确的分析数据以外，还需要网站分析师非常具有煽动性的演讲，以及面对质疑从容不迫的回应。网站分析师需要把自己的自信通过演讲的形式传播给参加会议的所有在场的人。

8、会做PPT

演讲和演示的时候，必备的利器!当然如果你能够做出很炫的动画效果将能感染更多的。

9、计划管理能力

如果你在一家小公司担任网站分析师职务的话，计划管理可能显得不那么重要，但如果你是一家大公司的网站运营经理，或者带领一个几十人的分析师团队的话，计划的管理能力将显得尤为重要。为了更好的和项目经理以及公司管理层的交流你需要具备这项技能，甚至有必要学习一些项目管理的相关知识，比如PMP认证等。

您可能也喜欢的文章：
什么数据库最适合数据分析师	如何成为网站数据分析师?	给网站数据分析师的五个忠告	网站数据分析：重点不在数据在于分析（一）	数据分析师必懂的10种分析思维
无觅

扒一扒HTTPS网站的内幕

Mon, 28 Sep 2015 16:20:14 CST

作者：王继波
野狗科技运维总监，曾在360、TP-Link从事网络运维相关工作，在网站性能优化、网络协议研究上经验丰富。
公众账号：yeyegou

今年6月，维基媒体基金会发布公告，旗下所有网站将默认开启HTTPS，这些网站中最为人所知的当然是全球最大的在线百科-维基百科。而更早时候的3月，百度已经发布公告，百度全站默认开启HTTPS。淘宝也默默做了全站HTTPS。

网站实现HTTPS，在国外已经非常普及，也是必然的趋势。Google、Facebook、Twitter等巨头公司早已经实现全站HTTPS，而且为鼓励全球网站的HTTPS实现，Google甚至调整了搜索引擎算法，让采用HTTPS的网站在搜索中排名更靠前。但是在国内，HTTPS网站进展并不好，大部分的电商网站也仅仅是对账户登录和交易做HTTPS，比如京东；很多网站甚至连登录页面也没有实现HTTPS...这里面有很多的原因，比如现有架构改动的代价过大、CDN实现困难、对用户隐私和安全的不重视等。

还有个重要原因是担心网站实现HTTPS后，网站的用户体验和性能下降明显。事实上，通过合理部署和优化，HTTPS网站的访问速度和性能基本不会受到影响。

一、什么是HTTPS网站？

在介绍HTTPS网站前，首先简单介绍什么是HTTPS。

HTTPS可以理解为HTTP+TLS，HTTP是互联网中使用最为广泛的协议，目前不部分的WEB应用和网站都是使用HTTP协议传输。主流版本是HTTP1.1，HTTP2.0还未正式普及，2.0由Google的SPDY协议演化而来，在性能上有明显的提升。

TLS是传输层加密协议，是HTTPS安全的核心，其前身是SSL，主流版本有SSL3.0、TLS1.0、TLS1.1、TLS1.2。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。

那网站为什么要实现HTTPS？

一言概之，为保护用户隐私和网络安全。通过数据加密、校验数据完整性和身份认证三种机制来保障安全。

由于本文的重点是HTTPS网站的性能加速，对于HTTPS通信过程和加解密算法就不展开介绍了。

感兴趣的同学可以Google之，基础都是一样的。

二、HTTPS网站的直观了解

推荐一个在线版全球知名的HTTPS网站检测工具-SSL Labs。Qualys SSL Labs同时也是很具有影响力的SSL安全和性能研究机构。在线检测地址为： https://www.ssllabs.com/ssltest/。

SSL Labs会对HTTPS网站的证书链、安全性、性能、协议细节进行全面检测，检测完毕后会进行打分，同时给出一份详细的检测报告和改进建议。

下面我们对一些常用网站进行检测。分别是12306购票页面、淘宝首页、百度首页、维基百科首页、WildDog首页的检测结果。

12306购票页面

淘宝首页

百度首页

维基百科首页

WildDog首页

可以看到，虽然都是HTTPS网站，但是差距就是那么大...... 这里要顺便提下，12306真的很挫，百度和淘宝为兼容一些低端版本的用户，也是各种使用弱加密和协议。

三、提高HTTPS网站性能和访问速度

如果你认为网站加上TLS证书，就是HTTPS网站了，那你就跟12306犯了同样的错误......

首先，网站在加上TLS证书时，为什么会变慢？这主要又两方面造成：

HTTPS比HTTP在通信时会产生更多的通信过程，随之RTT时间就会增加；
HTTPS通信过程的非对称和对称加解密计算会产生更多的服务器性能和时间上的消耗。

但是，每个HTTPS网站其实都有着巨大的优化空间。下面我们结合WildDog网站，来看看QPS值从30000到80000，加载时延从800ms到300ms，这中间的每个优化点是怎样的。

HSTS

HTTPS网站通常的做法是对HTTP的访问在服务器端做302跳转，跳转到HTTPS。但这个302跳转存在两个问题：

使用不安全的HTTP协议进行通信；
增加一个Round-Trip Time。

而HSTS是HTTP Strict Transport Security的缩写，服务器端配置支持HSTS后，会在给浏览器返回的HTTP Header中携带HSTS字段，浏览器在获取到该信息后，在接下来的一段时间内，对该网站的所有HTTP访问，浏览器都将请求在内部做307跳转到HTTPS，而无需任何网络过程。

Session Resume

Session Resume即会话复用，这提升HTTPS网站性能最基础也是最有效的方法。

在HTTPS握手阶段，对服务器性能消耗最为严重的是非对称密钥交换计算，而Session Resume通过对已经建立TLS会话的合理复用，节省非对称密钥交换计算次数，可大幅提高服务器的TLS性能。

TLS协议提供两种实现机制Session Resume，分别是Session cache和Session ticket。

Session Cache

Session Cache的原理是使用Session ID查询服务器上的session cache，如果命中，则直接使用缓存信息。但Session Cache有个明显的缺点，它不支持分布式缓存，只支持单机进程间的共享缓存。这对于多个接入节点的架构很难适用。

Session ticket

Session ticket的原理是服务器降session信息加密成ticket发送给浏览器，浏览器后续进行TLS握手时，会发送ticket，如果服务器能够解密和处理该ticket，则可以复用session。

Session ticket可以很好的解决分布式问题，但Session ticket的支持率还不是很高，而且需要考虑服务器上key的安全性方案。

OCSP Stapling

在HTTPS通信过程时，浏览器会去验证服务器端下发的证书链是否已经被撤销。验证的方法有两种：CRL和OCSP。

CRL是证书撤销列表，CA机构会维护并定期更新CRL列表，但这个机制存在不足：

1.CRL列表只会越来越大；

2.如果浏览器更新不及时，会造成误判。

OCSP是实时证书在线验证协议，是对CRL机制的弥补，通过OCSP浏览器可以实时的向CA机构验证证书。但OCSP同样存在不足：

对CA机构要求过高，要求实时全球高可用；
客户端的访问隐私会在CA机构被泄露；
增加浏览器的握手时延。

而OCSP Stapling是对OCSP缺陷的弥补，服务器可事先模拟浏览器对证书链进行验证，并将带有CA机构签名的OCSP响应保存到本地，然后在握手阶段，将OCSP响应和证书链一起下发给浏览器，省去浏览器的在线验证过程。

SPDY和HTTP2.0

SPDY 是 Google 推出的优化 HTTP 传输效率的协议，采用多路复用方式，能将多个 HTTP 请求在同一个连接上一起发出去，对HTTP通信效率提升明显。HTTP2.0是 IETF 2015 年 2 月份通过的 HTTP 下一代协议，它以 SPDY 为原型。SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。

Nginx stable版本当前只能支持到SPDY3.1，但最新发布的1.9.5版本通过打patch的方式，可以支持HTTP2.0，这绝对是不一样的奇妙体验。不过不建议直接在线上环境部署，等到2015年年底吧，Nginx会发布Stable版本支持HTTP2.0.

TCP优化

因为TCP是HTTPS的承载，TCP的性能提升，上层业务都可以受益。

慢启动是TCP规范中很重要的算法，其目的是为避免网络拥塞。通过客户端和服务器之间的数据交换，从一个很保守的初始拥塞窗口值，收敛到双方都认可的可用带宽。当客户端和服务器收敛到一定带宽时，如果一段时间内，双方没有收发数据包，服务器端的拥塞窗口会被重置为初始拥塞窗口值。这对于连接中的突发数据传输性能影响是很严重的。

在没有充足的理由时，服务器端需要禁用空闲后的慢启动机制。

另外，当前浏览器和服务器之间的可用带宽已经相对较大，所以我们还应该将初始的拥塞窗口值扩大，新的RFC中的建议是10，Google是16。

TLS Record Size

服务器在建立TLS连接时，会为每个连接分配Buffer，这个Buffer叫TLS Record Size。这个Size是可调。

Size值如果过小，头部负载比重就会过大，最高可达6%。

Size值如果过大，那单个Record在TCP层会被分成多个包发送。浏览器必须等待这些全部达到后，才能解密，一旦出现丢包、拥塞、重传、甚至重新建立的情况，时延就会被相应增加。

那TLS Record Size值如何选择呢？有两个参数可参考。

首先，TLS Record Size要大于证书链和OCSP Stapling响应大小，证书链不会分成多个record；

其次，要小于初始拥塞窗口值，保证服务器在通信之初可以发送足够数据而不需要等待浏览器确认

一般来说，从根CA机构申请的证书为2-3KB左右，级数越多，证书链越大，ocsp响应为2KB左右，所以TLS Record Size是需要根据你的实际情况设置，Google的值5KB。WildDog当前的值是6KB。

证书链完整且不冗余

浏览器在验证服务器下发的证书链时，不仅仅验证网站证书。如果是多级证书，网站证书和根证书之间所有的中间证书都需要被验证。一旦出现证书链出现不完整，浏览器就会暂停握手过程，自行到因特网进行验证，这个时间基本是不可估算的。

至于怎么查看，通过openssl命令查看，也可以通过SSL Labs帮你在线检测。

移动设备上的ChaCha20-Poly1305

去年的时候，谷歌已经在Android的Chrome浏览器上增加支持一个新的TLS加密套件，这个加密套件就是ChaCha20-Poly1305。它的设计者是伊利诺伊大学的教授和研究员Dan BernsteinChaCha20被用来加密，Poly1305被用来消息认证，两个操作都需要运行于TLS上。

当前流行的加密套件AES-GCM在TLS 1.2支持，它是不安全RC4和AES-CBC加密套件的替代品。但是，在不支持硬件AES的设备上会引起性能问题，如大部分的智能手机、平板电脑、可穿戴设备。

ChaCha20-Poly1305正式为解决这个问题而生。以下是Google的相关测试数据，在使用Snapdragon S4 Pro处理器的Nexus 4或其他手机中，AES-GSM的加密吞吐量是41.5MB/s，而ChaCha20-Poly1305是130.9MB/s。在使用OMAP 4460的老的Galaxy Nexus手机上，AES-GSM的吞吐量是24.1MB/s，而ChaCha20-Poly1305是75.3MB/s。

当前，OpenSSL 1.0.2的分支上已经开始支持ChaCha20-Poly1305，而对ChaCha20-Poly1305支持最好的当属BoringSSL。通过重新对Nginx的SSL库编译，可以支持到ChaCha20-Poly1305，不过对于线上环境，建议看明白源码再使用。

除此之外，还有不少优化的细节，如硬件加速、False Start、禁用TLS压缩等等，这里就不扒了。

如果觉得这篇文章有帮助，就请收藏或者分享一下，希望可以帮到更多人。

优化网站加载速度的14个技巧

Wed, 04 Feb 2015 21:12:44 CST

优化了加载速度的网站不仅可以提高其搜索引擎的排名，同时也可以降低网站的跳出率，提高其转换率，还能提供更好的终端用户体验，这是当今基于Web环境取得成功的关键。

下面我将介绍几个优化网站加载网页速度的简单方法，一起来看一下。

1.服务器响应时间

即使网站已经格外优化，但是除非服务器响应时间非常快，否则就不会有什么大的效果。当涉及到提高网站的速度，服务器响应时间起着重要的作用。下面是一些提高服务器响应时间的小贴士。

有独立的服务器，而不是选择共享/托管服务器。
提高Web服务器的质量。
移除不必要的插件，只有那些必要的插件，才需要一直保持启用状态。

2.浏览器缓存

浏览器缓存可以减少HTTP请求，从而反过来提高网站的加载速度。下面就是如何利用浏览器缓存的代码示例：

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>

注意：如果过期时间与文件挂钩，而此时文件中的内容需要更改的话，那必须先重命名文件，以便浏览器可以获取新添加的代码。

3.gzip压缩

gzip压缩是一个压缩实用程序，我们可以用它来快速加载网站。它的工作原理是在发送HTML和CSS文件到互联网浏览器之前，先压缩文件大小。允许mod_defalte模块启用Gzip压缩，下面是如何使用它的代码示例：

<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent
</IfModule>

4.异步脚本

还有一个可以提高网站页面速度的超棒选择就是异步加载脚本。如此一来网页负载就并不必依赖于这些异步脚本，网站访问者也不再需要不得不按捺下性子，等待所有的脚本加载完之后才能呈现页面。在异步模式中，脚本是在后台下载的。通常，我们会将第三方脚本作为异步脚本，因为下载这些脚本时常会让网站速度变得非常慢。

<script async src="http://www.yoursite.com/script.js"></script>

5.内容分发网络（CDN）

内容分发网络（CDN）是位于不同地理位置的服务器组成的网络。每个服务器都拥有所有网站的文件副本。要是有网站访问者请求文件和网页时，就可以直接从就近的网站服务器发送过来（也可以是从负载最小的服务器）。

6.优化JavaScript、HTML和CSS

优化JavaScript和CSS也可以提高一个网站的网页速度，而且这个方法非常简单。优化JavaScript、HTML和CSS就是删除所有不必要的空格和注释，从而减小文件大小。下面是一些最小化JavaScript和CSS的流行工具，非常有用。

7.置于顶部的样式表和底部的脚本

将样式表放在顶部有助网站的迅速加载，因为这样可以使得网页渐进式呈现。一般地，所有的互联网浏览器都支持在给定时间内并行下载两个组件（图像、样式和脚本）。但是通常而言，霸道的脚本会在并行下载时会阻止其他的下载，直到脚本下载完毕。

8.避免阻塞型的JavaScript和CSS

在浏览器呈现网页之前，它首先需要通过解析HTML标记语言来构建一个DOM树。在此过程中，如果遇到了脚本，此过程就会中止，转而先执行脚本，完了才会继续原先的活动。因此建议避免阻塞型的JavaScript，尤其是外部脚本。

阻塞型JavaScript还会导致网站的延迟。所以不妨推迟加载那些不重要的JavaScript，或者采用异步加载的方式。另一种选择是将这些HTML代码内嵌到网站上，同时需要确保CSS的优化。

9.JavaScript的延迟解析

为了加载网页，浏览器必须解析所有的<script>标记内容，从而增加了网站的加载时间。通过延迟解析脚本，那么就可以减少初始网站的加载时间了。

10.启用Keep Alive

当用户通过浏览器请求网页时，浏览器首先需要访问HTML文件。然后它才能读取这些文件，并请求与其他资料相关联（此处的资料可以是CSS，JavaScript，也可以是任何相关的图像）。

如果“Keep Alive”选项被禁止，那么下载网站的进程通常就会增加，从而拖累了网站速度。启用KeepAlive的另一个好处是，它可以减少CPU的使用。

语法: KeepAlive On

11.图像和文件格式

图像对于任何网站都非常有价值，因为它能传达一些强有力的信息给网站的访问者。最常见的图像格式是GIF、JPEG、PNG等。每种格式都有其长处和局限。建议使用JPEG格式，而不是GIF和PNG图像，除非图像包含Alpha因子或者是透明的。

12.优化代码：不使用内联CSS

内联了样式就不能清清楚楚地将内容从设计中剥离开来。同时可能还会需要大量的维护工作，给网站管理员带来各种不便，还会进一步增加网页的大小。

13.文件分离

网站的文件可以分为CSS、JavaScripts和图像。文件分离虽然并不能直接改善网站的加载时间。但是，这么做可以提高服务器的稳定性，特别是当网站流量突然出现了尖峰的时候。子域也可以用于托管文件，这样可以增加并行下载的数量。

14.尽量减少HTTP请求

还有一种简单的优化网页速度的方法是，减少HTTP请求。当一个网站一下子收到太多的HTTP请求，它的访客就会有响应时间延迟的体验，这不仅增加了CPU使用率也增加了页面的加载时间。那么，又该如何减少HTTP请求？请见以下步骤。

减少网站上的对象数量。
最小化网站上的重定向数量。
使用CSS Sprites技术（只要你需要的那部分图片内容）。
结合JavaScripts和CSS。

上述建议已被证明在优化网站的页面加载速度上非常有效。总之，炫彩夺目的图形，有趣的内容和更好的导航可以帮助你获得更多的网站访问者，但更快的网页加载速度则能帮助你留住他们。

网站页面优化策略

Thu, 23 Apr 2015 22:22:53 CST

　　网站的页面优化，也即网页优化是对网页的程序、内容、版块、布局等多方面的优化调整，使其适合搜索引擎检索，满足搜索引擎排名的指标，从而在搜索引擎检索中获得的排名提升，增强搜索引擎营销的效果使网站的产品相关的关键词能有好的排位。使网站更容易被搜索引擎收录，提高用户体验和转化率进而创造价值。下面主要从网站代码、标签、正文等几个方面来讲述网站的页面优化。

　　 网站重构

　　网站重构可以使网站的维护成本变得更低，运行得更好，遵循HTML结构化标准的设计，将网站页面的实际内容与它们呈现的格式相分离。简单来说，就是将所有的字体、样式等表现形式都写成DIV+CSS的方式，CSS放在单独文件里，Javascript也放在单独文件，HTML里面只有文字内容。凡是可以使用外部文件调用的，就使用外部文件调用，可以不出现的，尽量不出现，在正文中，全部以文字为主，不要出现CSS代码。

　　这样做的好处是，HTML文件的代码被精简，文件变小，搜索引擎在索引网站页面时，可以更好地索引和识别网站的内容信息，并能准确抓取页面正文的内容。

　　 Meta标签优化

　　对于Meta标签，主要有title、description、keywords三个地方，其余的meta标签不加也没事。就重要性而言，title在页面优化中绝对占据很重要的位置。

　　title标题标签告诉用户和搜索引擎一个特定网页的主题是什么。<title>标签通常放在HTML文档的<head>标签内。理想情况下，应该为网站的每一个网页创建唯一的title页面标题。

　　关于title的写作，title标签应该准确描述网页的内容，使用简短的，但具描述性的标题标签——短的标题同样可以包含丰富的信息。如果标题太长，搜索引擎只会在搜索结果里显示其部分内容。尽量不要堆积太多关键词，如果是长标题，可以包含关键词1-2次，而且关键词不用靠的太近。

　　description描述标签提供了关于这个网页的总括性描述，网页的标题可能是由一些单词和短语组成的，而网页的描述元标签则常常是由一两个语句或段落组成的。如果网页摘要里的某个词语恰好出现在用户的查询里，那么这个词语将被高亮显示，如果描述标签写的好，可以提升页面的点击率。

　　关于description的写作，description标签准确概括该网页的内容，每一个网页应该创建各不相同的描述标签，避免所有的网页或很多网页使用千篇一律的description标签。

　　keywords关键词标签，对于页面优化来说，重要性已经大不如前，甚至有种说法是，keywords标签已经没用了，不过，就算搜索引擎已经不将keywords考虑进，写一下keywords标签可能还会有些作用，不过keywords里面不要堆砌太多关键字，否则可能适得其反，写上4、5个核心关键字即可。

　　 Heading 标签优化

　　Heading标签（H标签）通常用来为用户呈现网页的结构。HTML语言里一共有六种大小的H标签，从最重要的<H1>到<H6>，权重依次降低。最常用的包括H1、H2标签，H1代表着大标题，H2是小标题。按照这个意思，最重要的关键词设置在H1标签中，和关键词相关的词组再放到H2标签中，依次往后推。

　　由于H标签通常会使某些文字比普通的文字大，对于用户来说，这样可以便于他们更直观地看出这些文字的重要性，多种渐变大小的H标签可以为网站的内容创建分层结构，从而使用户更容易地浏览网站。

　　对于网页内容页面的优化来讲，应该适度的使用H标签，从一般页面的写作来讲，文章的标题，就应该出现在H1标签中，小标题就出现在H2标签上。

　　 Alt优化

　　图片的优化对于网站页面来说也非常重要，所有的图片都拥有一个Alt属性，对于图片的优化主要是针对这个属性的优化，优化图片的alt属性可以使得图片搜索引擎能更好地理解图片。

　　由于搜索引擎读取图片的困难，所以在一般的写作中，需要对添加的图片，进行ALT标签注释。当然对于图片的理解，周围的文字也起到一定的作用，当图片因为一些原因不能够显示的时候，系统会显示alt属性指定的文字。

　　Alt属性的编写，应该使用简短但是描述性很强的alt文本，当图片作为链接使用时，一定要提供alt文本，这会大大有助于搜索引擎更好地理解它链向的那个页面。

　　 链接锚文本优化

　　锚文本是链接上可以被点击的文字，它通常被放在锚标记A标签中间，锚文本主要作用是描述链接页面的一些情况，锚文本写得越好，用户浏览网站就越容易，搜索引擎也能更容易地理解链接到的页面内容。

　　锚文本的正确写法是，使用简短的描述性文字，避免使用与目标页面主题无关的文字，避免用一个长句子或是一篇短文来实现的过长的锚文本，

　　 关键词优化

　　关键词的布局，最重要的几个位置是开头，特别是第一段开头的50-150个字，需要包含一次关键词，然后中间正文中，出现2-3次关键词或者近义词，文章的结尾，也包含一次关键词就可以了。

　　在关键词的布局中，还有一个概念是，关键词密度。关键词密度(Keyword Density)也叫关键词频率(Keyword Frequency)，它是用来量度关键词在网页上出现的总次数与其他文字的比例，一般用百分比表示。相对于页面总字数而言，关键词出现的频率越高，那么关键词密度也就越大。简单地举个例子，如果某个网页共有100个字符，而关键词本身是两个字符并在其中出现5次，则可以说关键词密度为10%。通常认为，页面的关键词密度应该保持在2%到8%之间。

　　许多搜索引擎都将关键字密度作为其排名算法考虑因素之一，每个搜索引擎都有一套关于关键字密度的不同的数学公式。合理的关键字密度可使你获得较高的排名位置，密度过大，起到相反的效果。

　　关键字密度有时候会影响到关键词的排名，不建议采取一些极端的方法来提高关键字密度。合理的目标关键字密度可以通过关注一些长尾关键字来进行优化。长尾关键词(Long Tail Keyword)是指网站上非目标关键词但也可以带来搜索流量的关键词。长尾关键词的特征是比较长，往往是2-3个词组成，甚至是短语。通过长尾关键词挖掘工具可以找到不少长尾关键词，将这些词组织到文章里，就可以做到既不提高关键词密度，又能提升关键词在页面的权重。

　　在正文里，要围绕关键词自然地写作，千万不要生硬地将需要优化的关键词直接插到文章中。文章中，尽量使用关键词的近义词、同义词。

　　 内容优化

　　对网站来说，提供高质量的、对用户有益的内容恐怕是所有讨论的各种要素里最重要的一部分。用户很容易分辨出网站提供的内容是否是高质量的，并且他们也乐意于通过各种社交网络来向自己的朋友推荐好的网站，这同时也会提高网站在用户和搜索引擎中的声望，而这一切都离不开高质量的内容。

　　但可惜的是，撰写高质量内容并不太容易，除了拥有过硬的专业技能知识外，作者还要拥有一流的语言组织能力，以及充足的时间，不过对于高质量内容的撰写也是有一定规律的，主要的规律包括：

　　1、撰写容易阅读，浅显易读的内容，有条理地组织内容，段落清晰，让读者能够清楚地了解内容的起始和逻辑，避免将大量不同主题的内容放在同一页上，却没有任何的分段、标识和层次划分。

　　2、提供原创的、独特新颖的内容，不要模仿甚至抄袭别人的内容。原创内容不仅仅能吸引更多的用户，还可以招揽更多的回头客。而搜索引擎对于原创内容的识别能力也越来越高。

评论《网站页面优化策略》的内容...

微博：新浪微博 - 微信公众号：williamlonginfo
月光博客投稿信箱：williamlong.info(at)gmail.com
Created by William Long www.williamlong.info

使用varnish + nginx + lua搭建网站的降级系统

Sun, 07 Jun 2015 18:20:48 CST

前言

通常一个网站数据库挂掉后，后果将是非常严重的。基本上整个网站基本不可用了。对于一些网站来说，当数据库挂掉后，如果能提供基本的浏览服务，也是不错的。本文将尝试使用varnish + nginx + lua 搭建网站降级系统来实现整个目标。

降级目标

降级方案的目标是，当网站出现致命故障时（如出现500错误，不能提供服务），可以把缓存的页面数据展现给用户。从而提供基本的浏览服务。
1、只提供基本的浏览服务
2、浏览的数据都是非登录状态下的数据
3、支持手动和自动降级。自动降级是当后端返回500错误次数在一段时间内达到一定阈值(不包含503)。手动降级是从控制界面操作。

降级方案

存储

使用varnish作为存储。有效的节约了物理内存，并保持了较好的性能。

更新

使用crond脚本从nginx的access日志中分析出请求url，然后向varnish发请求，从而更新varnish的缓存。缓存的异步更新，减少对nginx的压力。

降级

支持手动降级和自动降级。降级后，nginx自动从varnish中提取数据，并返回给用户。

流程图

流程描述

1、用户请求到nginx时，nginx会判断当前是否是降级状态。如果属于降级状态，直接从varnish中获取数据。非降级状态，把请求转到php-fpm。
2、当crond脚本请求varnish进行缓存数据更新时，如果当前varnish处于降级状态，则不进行缓存更新。如果没有处在降级状态，则把请求转到nginx，获取数据。然后把获取的数据缓存到varnish中。
3、varnish会自动监控后端nginx的状态。如果检测到nginx已经处于降级状态，则varnish也会自动进入降级状态。

安装部署

vanish安装到/home/varnish 目录下。安装步骤如下：
首先，安装libpcre。

sudo yum install pcre pcre-devel

其次，安装varnish。

./configure --prefix=/home/varnish
make 
sudo -u admin make install
sudo -u admin mkdir -p /home/varnish/vcache/
sudo chown admin:admin -R /home/varnish
sudo -u admin touch /home/varnish/vcache/varnish_cache.data
sudo chmod 777 /home/varnish/vcache/varnish_cache.data

再次，修改varnish配置文件和部署相关脚本。点击下载文件压缩包。配置文件名为default.vcl
最后，启动varnish。启动脚本也在压缩包中，名称为 varnishctl

sudo /home/admin/varnish/sbin/varnishctl start

注意：启动后可以通过varnishlog命令查看是否运行正常。如果出现以下字样，说明运行正常。http的返回状态为200

$/home/varnish/bin/varnishlog 
0 Backend_health - default Still healthy 4--X-RH 4 2 4 0.002698 0.001722 HTTP/1.1 200 OK

部署lua脚本

lua脚本在/home/admin/nginx/data/lua目录下。确保目录下有如下几个个脚本。
pc_get_downgrade_data.lua
init.lua
pc_status_stat.lua
pc_get_status.lua
pc_set_satus.lua
这几个脚本在下载的压缩包中有。

修改nginx配置文件

首先，在http域增加

init_by_lua_file 'lua/init.lua';
lua_shared_dict pc_status 1m;
lua_shared_dict pc_auto_status 1m;
#varnish config
upstream varnish{
    server 127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=5s;
}

最后，在server域宏增加如下配置。

location @php {
  include fastcgi_params;
}   
location @var {
 proxy_pass http://varnish$str_params;
}   
location ~* ^(.+\.php)(.*)$ {
  #check downgrade status, then get data from varnish
  set $str_params $uri;
  content_by_lua_file lua/pc_get_downgrade_data.lua;
}
location /pc_get_auto_status {
           if ($white_ip = 0) {
               return 403;
           }
           content_by_lua_file lua/pc_get_auto_status.lua;
 }
location /pc_get_status {
     if ($white_ip = 0) {
         return 403;
     }
     content_by_lua_file lua/pc_get_status.lua;
}
location /pc_set_status {
           if ($white_ip = 0) {
               return 403;
           }
           content_by_lua_file lua/pc_set_status.lua;
}

log_by_lua_file  lua/pc_status_stat.lua;

部署crond脚本

脚本varnish_crond.php。在crond中增加执行命令。每分钟执行一次。
来自crond的请求，user-agent数据为varnish_crond。把user-agent为varnish_crond请求特殊处理。保证能正常请求，并返回相关数据。

降级管理

varnish降级

只要让varnish配置中指定的监控脚本check.php返回500错误即可。varnish监控到指定脚本不可用，自动会进入降级状态。
当脚本返回200状态后，varnish自动又会恢复正常。

nginx降级

设置降级

curl -H"Host:demo.bo56.com"-i http://127.0.0.1/pc_set_status?status=1

恢复正常

 curl -H"Host:demo.bo56.com" -i http://127.0.0.1/pc_set_status?status=0

查看降级状态

curl -H"Host:demo.bo56.com" -i http://127.0.0.1/pc_get_status

如果返回的值为1表示降级

开发一个业务逻辑复杂的系统，应该怎么样设计才能使项目的扩展性更好？

Tue, 30 Dec 2014 08:39:13 CST

看到一篇好文章，收藏一下

我在知乎关于《开发一个业务逻辑复杂的系统，应该怎么样设计才能使项目的扩展性更好？》做的回答。

既然业务逻辑复杂，那意味着项目前期的业务建模、需求分析、分析设计极为重要，直接抛开这几个阶段进入技术实施开发阶段，不管套用什么设计模式、架构模式，系统的扩展性肯定难以保证。

项目的扩展性虽然最终体现为系统架构、技术实现的扩展性，但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差，大都将原因归结为技术实现烂，但总结那些成功的大型项目或产品的最佳实践，原因都会有：某某是业务专家，对xx业务很熟悉，能够衔接业务与技术。因此一个好的项目角色中，应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色，从业务架构、信息架构、技术架构保证系统的扩展性。

具体怎样进行业务建模，搭建良好的业务架构和业务模型，从而为技术架构、信息架构、技术实现奠定良好基础，有一些较为成熟的软件开发过程可供参考。例如 RUP（Rational Unified Process，统一软件开发过程)。一个标准的RUP工作流程包括：业务建模，需求分析，分析设计，实施开发，测试，部署，配置和变更管理，项目管理，环境。当然RUP只是一个方法论，且过于庞大，大部分项目很难完整执行其过程，需要根据实际情况进行裁剪，但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。

因此对于题主描述的一个复杂系统，标准的过程应当在业务建模，需求分析，分析设计，实施开发，测试，部署完整过程的分析设计（与开发语言无关）或实施开发（分析设计的成果映射为具体语言，例如Java、.NET等）阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段，类似禅修中“看山是山、看水是水”的三个阶段，才能体会模式的运用之妙。

值得强调的是：如果是偏交易（例如支付、金融）的系统，在考虑扩展性时候，一定要将信息架构、信息模型的扩展性纳入到考虑范围，此类系统数据模型至关重要，也不可能频繁变动。

上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目，对于互联网偏创新性的项目就不一定完全适用了，此类项目的现实情况如下：业务模式不确定，会不停试错，验证模式；需求不停变化，要求能够快速响应；全新的行业，没有行业专家，没有行业标杆可借鉴（至多有跨界标杆可参考）；此时候，类似精益创业、Scrum之类的敏捷开发模式更适合，但对于复杂的业务而言，业务建模->需求分析->分析设计的理念仍然值得参考借鉴。

最后，最最重要的是：完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样，中国大部分公司后任会不停否定掉前任的架构、系统，推倒再来一遍，然后等新系统刚开发出来不久，尚未上线或上线运营一段时间后，再换一帮人继续折腾，然后。。。

总结这么多年的经历，深刻体会到：再烂的系统和架构，如果能够强化管理、持续积累、持续重构、持续完善，都能够有机会成为完美的系统，完美的系统不在于其架构的牛逼和完美，而在于：符合公司的业务模式，能够完美支撑公司业务的高速发展和市场需求的快速响应。

Php及Redis安装测试汇总

Tue, 09 Dec 2014 22:37:13 CST

后端开发用到php操作redis，在此将安装测试过程中遇到的问题汇总记录下来，以便以后参考！（系统为ubuntu）

本文目录：

1.redis安装

2.redis测试

3.php redis 扩展安装

4. php-redis测试

1.redis安装

下载地址： http://download.redis.io/releases/

解压安装：

tar -xvf redis-2.8.17.tar.gz

make

sudo make install

为方便使用，在/usr目录下创建redis目录，讲如下几个文件拷贝到/usr/redis/目录下：

/yourdir/redis-2.8.17/redis.conf

/yourdir/redis-2.8.17/src/redis-benchmark

/yourdir/redis-2.8.17/src/redis-server

/yourdir/redis-2.8.17/src/redis-cli

当然，你也可以通过软连接的方式达到方便使用的目的。此外，你也可以将redis-server加入开机启动，此处从略。

2.redis测试

1）先开启redis服务端程序

为方便测试，我们将redis.conf配置文件中的loglevel和logfile的值，修改后如下：

loglevel debug

logfile “/tmp/redis.log”

jay13@ubuntu:/usr/redis$ redis-server redis.conf

2）开启redi客户端，通过客户端向redis数据库中进行增删改查操作。整个操作过程中生成的日志可以到/tmp/redis.log中查看。

以最简单的key操作为例，实例如下：

jay13@ubuntu:/usr/redis$ redis-cli
127.0.0.1:6379> set jay13 cricode.com
OK
127.0.0.1:6379> set jay hello,world
OK
127.0.0.1:6379> get jay
"hello,world"
127.0.0.1:6379> get jay13
"cricode.com"
127.0.0.1:6379> del jay
(integer) 1
127.0.0.1:6379> get jay
(nil)
127.0.0.1:6379> set jay13 www.cricode.com
OK
127.0.0.1:6379> get jay13
"www.cricode.com"

3.安装phpredis扩展

在使用sudo apt-get install php5安装php时，默认是没有安装phpize的，我们安装phpredis时，需要用到phpize，因此，需要先安装phpize。

1）我们通过安装php开发者工具来获取phpize。执行如下命令即可：

sudo apt-get install php5-dev

2）获取phpredis源文件

最新的phpRedis地址： https://github.com/nicolasff/phpredis

按照GitHub上的说明进行如下安装时，

phpize
./configure --enable-redis-igbinary
make && make install

可能会出现如下出错说明：

checking for igbinary includes... configure: error: Cannot find igbinary.h

这个是因为我们没有igbinary扩展，这是phpredis依赖的一个东西。

好吧，怎么安装igbinary呢？

使用apt-get没有无法安装完成，我们通过下载安装文件进行安装。

wget    http://pecl.php.net/get/igbinary-1.1.1.tgz

tar -xzvf igbinary-1.1.1.tgz

cd igbinary-1.1.1

phpize

./configure # No need for extra config params

make

make install

安装好igbinary后，可以用如下命令安装phpredis。

phpize

./configure –enable-redis-igbinary

make && make install

至此，安装完成。

我们修改php.ini配置文件，将刚才安装的两个扩展加入到php.ini文件中，加入的语句如下：

extension=igbinary.so

extension=redis.so

重启apache，Done！！！

4.测试php-redis

在网页根目录/var/www/中新建文件test.php，内容如下：

<?php 
$redis = new Redis(); 
$redis->connect('127.0.0.1',6379); 
$redis->set('Jay13','www.cricode.com'); 
echo 'Jay13:'.$redis->get('Jay13'); 
echo '</br>'; 
echo 'Jay12:'.$redis->get('Jay12'); 
?>

结果如下图：

《大型网站技术架构》笔记－架构篇

Sun, 06 Jul 2014 20:56:12 CST

第四章瞬时响应：网站的高性能架构

4.1 网站性能测试

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

性能测试的指标有：响应时间、并发数、吞吐量、性能计数器。

网站性能优化的目的，除了改善用户体验的响应时间，还要尽量提升系统吞吐量，最大限度利用服务器资源。

4.2 Web 前端性能优化

主要手段有优化浏览器访问、使用反向代理、CDN加速等。

4.2.1 浏览器访问优化

减少http请求：合并、压缩CSS、JS，合并图片， 使用Ajax局部刷新页面。
使用浏览器缓存：
- Expires：告诉缓存器：相关副本在多长时间内是新鲜的。过了这个时间，缓存器就会向源服务器发送请求，检查文档是否被修改。
- Cache-Control：
  > * max-age=[秒] — 执行缓存被认为是最新的最长时间。这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
  > * s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存
  > * public — 标记认证内容也可以被缓存，一般来说：经过HTTP认证才能访问的内容，输出是自动不可以缓存的；
  > * no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；
  > * no-store — 强制缓存在任何情况下都不要保留任何副本
  > * must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
  > * proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用。
- Last-Modified/If-Modified-Since：第一次请求资源时，服务器在响应头里设置 Last-Modified 为资源的最后修改时间，浏览器第二次请求资源时，在请求头里带上上次响应的 Last-Modified 值，服务器检测到资源自此值后没有修改，则仅返回 304 响应头。
- ETag/If-None-Match：服务器发送你所请求的数据的同时，发送数据的某种 hash (在 ETag 头信息中给出)。hash 的确定完全取决于服务器。当第二次请求相同的数据时，你需要在 If-None-Match 头信息中包含 ETag hash，如果数据没有改变，服务器将仅返回 304 状态代码。
服务端启用GZip压缩
CSS 放在页面最上面，JS放在页面最下面：浏览器在下载完全部CSS之后才开始对整个页面进行渲染；在加载JS后立即执行，可能会阻塞页面，造成页面显示缓慢。
减少Cookie传输：Cookie包含在每次请求和响应中，太大的Cookie会影响数据传输；对于静态资源，发送Cookie没有意义，可以对静态资源使用独立域名。
对不同的静态资源使用独立域名：浏览器对同一个域同时访问的连接数是有限制的，增加不同的域可以加快资源加载。

4.3 应用服务器性能优化

主要手段有缓存、集群、异步等。

网站性能优化第一定律：优先考虑使用缓存优化性能。

缓存主要用来存放那些读写比很高、很少变化的数据。

任何可以晚点做的事情都应该晚点再做。

代码优化：

多线程： 启动线程数＝[任务执行时间/(任务执行时间－IO等待时间)]*CPU内核数。解决线程安全的主要手段：将对象设计为无状态对象、使用局部变量、并发访问资源时使用锁。
资源复用
恰当的数据结构
关注垃圾回收：

4.5 小结

网站性能优化的主要工作是改善高并发下情况下的网站响应速度。

网站性能对最终用户而言是一种主观感受，性能优化的最终目的就是改善用户的体验，使他们感觉网站很快。离开这个目的，追求技术上的所谓高性能，是舍本逐末，没有多大意义。而用户体验的快或慢，可以通过技术手段改善，也可以通过优化交互体验改善。

第五章万无一失：网站的高可用架构

5.2 高可用的网站架构

完整的高可用架构设计的主要目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。

实现上述高可用架构的主要手段是数据和服务的冗余备份以及失效转移。

位于应用层和服务层的服务器为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务。

位于数据层的服务器需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。

5.3 高可用的应用

通过负载均衡进行无状态服务的失效转移。

Session 管理

Session 复制：简单，占用服务器内存、带宽资源。
Session 绑定：将同一IP或Cookie信息转发到特定的服务器，不满足高可用。
利用Cookie 记录Session：简单可靠性高，支持应用服务器线性伸缩；受cookie大小限制，每次请求要传输cookie，影响性能，如果用户关闭cookie，访问会不正常。
Session 服务器：这种解决方案将应用服务器的状态分离，分为无状态的应用服务器和有状态的 session 服务器；应用服务器每次读写 sission，都访问 session 服务器。

5.4 高可用的服务

也是通过负载均衡和失效转移机制失效。

分级管理：对服务进行分级管理，确保优先级高的服务；在部署上进行隔离，避免故障的连锁反应。
超时设置：可避免请求长时间不能得到响应。
异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
服务降级：有两种手段：拒绝服务和关闭关闭服务。
- 拒绝服务：拒绝低优先级应用的调用，减少服务调用的并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让一部分请求成功，避免要死大家一起死的惨剧。
- 关闭服务：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。
幂等性设计：服务层保证重复调用和调用一次产生的结果相同，即服务具有幂等性。服务重复调用是无法避免的。

5.5 高可用的数据

保证数据高可用的手段主要是数据备份和失效转移机制。

CAP 原理

CAP 原理认为一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availability）、分区耐受性（Partition Tolerence，系统具有跨网络分区的伸缩性）。

在大型网站中，通常会选择强化分布式系统的可用性（A）和伸缩性（P），在某种程度上放弃一致性（C）。

数据一致性又分为：

数据强一致性：各个副本的数据在物理存储中总是一致的。
数据用户一致性：各个副本的数据可能是不一致的，终端用户访问时，通过纠错和校验机制，可以确定一个一致的且正确的数据返回给用户。
数据最终一致：物理存储的数据可能是不一致的，终端用户访问到的结果可能也是不一致的，但系统经过一段时间的自我修复和修正，数据最终会达到一致。

数据备份

数据备份分为冷备份和热备份，热备份又分为异步热备份和同步热备份。

在异步写入方式下，存储服务器分为主存储服务器（Master）和从存储服务器（Slave），应用程序通常只连接 Master，数据写入时，由 Master 的写代理操作模块将数据写入本机存储系统后立即返回写操作成功响应，然后通过异步线程将写操作数据同步到 Slave。

同步方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据的都已经写操作成功。

失效转移

失效转移操作由三个部分组成：失效确认、访问转移、数据恢复。

失效确认主要通过心跳检测和应用程序访问失败报告。

5.6 高可用网站的软件质量保证

网站发布
自动化测试
预发布验证
代码控制
自动化发布
灰度发布

5.7 网站运行监控

不允许没有监控的系统上线。

监控数据采集

用户行为日志：

服务器端日志
客户端浏览器日志

服务器性能监控。

运行数据报告。

监控管理

系统报警、失效转移、自动优雅降级。

第六章永无止境：网站的伸缩性架构

6.1 网站架构的伸缩性设计

网站的伸缩性架构可分成两类：一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。

当一头牛拉不动车的时候，不要去找一头更强壮的牛，而是用两头牛去拉车。

负载均衡的基础技术

HTTP 重定向负载均衡：采用 HTTP 重定向服务器，根据用户 HTTP 请求计算一台真实的 web 服务器地址，将该服务器地址写入 HTTP 重定向响应中返回给用户浏览器。需要两次访问才能完成一次请求，重定向服务器自身的处理能力有可能称为瓶颈。
DNS 域名解析负载均衡：在DNS 服务器中配置多个 A 记录，每次域名解析请求都会根据负载均衡算法计算一个不同的 IP 地址返回，这样 A 记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。DNS 的解析有延迟。
反向代理负载均衡：反向代理服务器需要配置双网卡和内部外部两套 IP 地址，工作在 HTTP 协议层，也叫应用层负载均衡。
IP 层负载均衡：在网络层通过修改请求目标的地址进行负责均衡。
数据链路层负载均衡：在数据链路层修改 mac 地址进行负载均衡。在分发过程中不修改 IP 地址，只修改目的 mac 地址，通过配置真实物理服务器集群所有机器虚拟 IP 和负载均衡服务器 IP 地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的。也称作直接路由（DR）。

负载均衡算法

轮询（Round Robin，RR）：所有请求被依次分发到每台应用服务器上。
加权轮询（Weighted Round Robin，WRR）：在轮询的基础上，按配置的权重将请求分发到每台服务器上。
随机（Random）：请求被随机分发到各个应用服务器上。
最少连接（Least Connection）：记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上。
源地址算列（Source Hashing）：根据请求来源的 IP 地址进行分发请求，同一个 IP 总是分发到同一台服务器上。

第七章随需应变：网站的可扩展性

扩展性（Extensibility）：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在基础设施稳定不需要经常变更，应用之间少依赖和耦合，对需求变更可以敏捷响应。
伸缩性（Scalability）：指系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。这种增减是成比例的，就被称作线性伸缩。

设计网站可扩展架构的核心思想是模块化，并在此基础之上，降低模块间的耦合性，提供模块的复用性。

分层和分割是模块化设计的重要手段，模块之间以消息传递和依赖调用的方式聚合成一个完整的系统。

模块分布式部署以后具体的聚合方式主要有分布式消息队列和分布式服务。

大型网站分布式服务的需求与特点：

服务的注册与发现
服务调用
负载均衡
失效转移
高效的远程通信
整合异构系统
对应用最少入侵
版本管理
实时监控

第八章固若金汤：网站的安全架构

一个更加牛逼的科技媒体将如何崛起

Wed, 15 Jan 2014 17:11:39 CST

　　笔者经常看到一些科技媒体和自媒体在自己的平台上探讨媒体该怎么做，几乎每天都能看到这样的讨论。讨论的具体话题包括传统媒体是如何走向衰落的？面临着什么样的问题？自媒体到底靠谱不靠谱？科技媒体扯淡不扯淡等等？

　　同样作为媒体从业者，笔者从这些讨论中获益良多，可是窃以为很多讨论或多或少偏离了一些最基本的问题，而是显得有些抽象化和概念化。或许，他们讨论的出发点都比较高，不屑于去关注一些基本的东西。

　　笔者是某手游媒体的主编，由于地处南京，跟本文所提到的这些远在帝都科技媒体和自媒体没有打过什么交道。本文只是笔者作为一个旁观者的个人意见，如有偏颇，欢迎探讨。这些想法比较杂乱，这里通过三个小标题把它们串起来：

　　 一、最重要却最被忽视的

　　笔者不太能想得通的是，为什么国内的科技媒体都是年轻人当家，而且乐此不疲。据我了解，国外的科技媒体，如连线杂志、TechCrunch以及最近倍受关注的Re/code基本都依赖于一个资深且专业的编辑团队，这些团队都是由一个年龄较长的头儿带领。

　　比如连线杂志的前主编凯文·凯利和克里斯·安德森，TechCrunch创始人兼前主编迈克尔-阿灵顿，Re/code的卡拉·斯韦舍和大名鼎鼎的莫博士，其中莫博士已经到了退休的年龄——66岁。据报道，Re/code刚创建没几天，其估值就达2500万至3500万美元。秘诀就是一个资深而专业的编辑团队。

　　对于一个互联网创业公司来说，年轻的团队意味着有活力、有创意、有干劲、有体力，可是对于媒体来说，资深记者或者饱经风霜的业内人士却是多多益善的。这一点我想无需多言。

　　问题在于，我们的媒体在主观上似乎并不在乎这一点？例如，虎嗅网招聘编辑的条件是“最好生于1985后”。其他科技媒体的编辑团队也主要是由年轻人组成。笔者认为，编辑团队的年轻化和缺少业内经验是制约国内科技媒体发展的主要因素。

　　 二、“自媒体”对罗振宇真的那么重要？

　　2013年讨论最多的是自媒体，倍受关注的也是自媒体。一些人认为自媒体不靠谱，另一些人认为自媒体代表未来。罗振宇的罗辑思维横空出世，让很多原本看低自媒体的人闭上了嘴。可是，罗振宇的成功真的因为他是自媒体？罗振宇真的想做自媒体吗？或者说，他真的只想做一个自媒体吗？我表示怀疑。

　　对于“罗振宇是否想做自媒体”这个问题，答案似乎是肯定的。笔者看过罗振宇在推出罗辑思维前的策划会议录像，罗振宇力主做个人脱口秀，不要谈话类节目，不要搞群演，坚决一个人上。而且罗振宇本人也是自媒体的大力支持者。

　　可是单人脱口秀不等于自媒体，周立波也是单人脱口秀，你怎么不说他是自媒体？单人脱口秀在电视行业早已不是什么稀罕玩意，很多国内外电视台都有这种节目。

　　罗辑思维的特色在于其传播渠道和形式：一是微信公众号的语音功能，二是优酷网的视频。罗振宇自己也认为，罗辑思维的一大成功秘诀在于，通过语音和视频充分地发挥了其人格魅力。

　　可是语音和视频有什么了不起？语音就像收音机，视频就像电视机，在中国都已经普及几十年了。

　　来自传统电视行业的罗振宇的秘诀在于把收音机、电视机和互联网结合了起来。这也算是一种“互联网思维”吧。是不是很简单？

　　可这看似简单，却是浸身互联网的国内众多科技媒体和传统的博客作者所忽视的。

　　我们看看国外的科技媒体，就会发现，他们早就开始做视频节目，我本人就会看商业周刊和TechCrunch的视频节目。可是回头看看国内的网络媒体，自制视频却少得可怜。除了凤凰网会借用凤凰电视台的视频，力推“全媒体”战略，其他四大门户很少有自己的视频作品。

　　视频作品本身的内容没有什么了不起，最重要的是这个形式。就像罗振宇说的，相比文字，语音和视频更具有人格特征。

　　如何来理解这一点？这里举一个简单的案例。

　　经常看科技媒体的都知道有一个叫魏武辉的人，因为他经常到处发表文章，也有自己的独立博客。他的头像就是他本人的照片。说句实话，魏老师不要生气，那张照片有一种欠揍的感觉（这也许和魏老师经常发表批判性文章有一定关系，给人感觉居高临下）。可是当笔者看了魏老师在Ted的演讲视频，那感觉和他的头像完全不一样，还是很平易近人和正常的。看了他的视频演讲，笔者对他的内容更有一种亲近感。这就是视频所表现出来的人格特征起到了作用。

　　还有独立博客的作者，你看了他几年的文章，但是可能根本不知道这个人长什么样。你可以引用钱钟书的话来反驳我：“如果你吃了一个鸡蛋感觉不错，何必要认识那只下蛋的母鸡呢？”可是你又不得不承认，在现实生活中，你往往就是先看看那只母鸡是什么样，然后才去判断它的蛋的。

　　再举一个典型的例子：某个互联网大佬放了个屁，但是我们总还习惯于从中找到正确的成分；相反，某个不知名的作者写了篇好文章，我们总还习惯于鸡蛋里挑骨头。人就是这样。

　　所以罗振宇成功的主要因素并不在于他是个自媒体，自媒体只是一个噱头，一种奠定个人魅力和品牌的手段。当罗老师有了足够的积累和资源，他召集一帮自媒体做一个网络电视台又何妨？罗振宇的微信号只有100万粉丝，做一个电视台，就可以轻松破千万粉丝，影响力成倍增长，何乐而不为呢？

　　作为媒体从业者，相比计较于“自媒体”这种概念，我们更应该关注的是具体的传播方式和途径。

　　 三、国内这些科技媒体的成功能否复制？

　　下面说一些更加具体的，如果你现在要在中国做一个新的科技媒体，你应该怎么做？先让我们看看目前已有的一些科技媒体。这里说三个最典型的：36氪、虎嗅网和Pingwest。

　　先说36氪，这是个很奇葩的网站。之所以我们都早已不觉得他奇葩，是因为习惯了。习惯了他整天翻译别人的文章，习惯了其他媒体也纷纷效仿。可是想想，一个媒体单纯靠翻译就能崛起，是不是真的很奇葩？你能想象一个美国媒体靠翻译虎嗅网就能成功吗？

　　现在的36氪又做产品库，又提供创业场地，大概也是意识到光靠翻译是做不长的。如今国外出来一篇文章，国内媒体就争相翻译。所以你想复制36氪，那是行不通的。

　　再说虎嗅网，最先知道这个媒体，还是通过它在月光博客的投稿，据说它和百度也有合作。总之，它一开始就通过不同渠道弄来很多流量，所以大家都愿意去投稿，因为曝光率高。再者，在传统杂志浸淫多年的创始人李岷深知传统媒体的弊病，于是选稿更灵活更大胆，这也吸引了不少业内人士投稿。

　　但虎嗅的成功最终还在于“业内人士”这四个字，李岷知道光靠一帮小屁孩是写不出能让业内人士正眼去看的文章的。于是“以夷制夷”，让业内人写给业内人看，也就是打造一个投稿平台。

　　可是很快，这一招也被其他媒体学去了，那些喜欢码字的业内人成为各大媒体争抢的香饽饽。例如钛媒体打出“自媒体平台”的旗号，召集一帮“自媒体”去码字，而且“尺度”比虎嗅更大。最近笔者就经常看到钛媒体发一些有关“网站如何做SEO”的文章，不禁唏嘘。网站如何做SEO，这个话题早已经被SEO博客们写滥了，现在连这些博客都懒得再写，没想到一个科技媒体会接下这个光荣而艰巨的任务，您可千万别学《士兵突击》里的李梦说：“光荣在于平淡，艰巨在于漫长。”这个话题写不长的。

　　最后说说Pingwest，这是个很特别的网站。如果你在它刚刚创建时就访问过它，你也会有同样的感觉。那时Pingwest用的是一个普通的不能再普通的Wordpress模板。很长一段时间内，我都以为那是个人博客。也许创始人是想暗示他们要发扬个人独立博客朴素的原创精神。

　　Pingwest确实很有原创精神，基本所有的文章都是他们编辑团队自己写的。创始人骆轶航原本是《第一财经周刊》驻硅谷的记者，号称7年科技报道经历，这在国内算资深的，但相比国外动辄十几年、二三十年的报道经验还是少了点。目测其团队成员也都只有二三十岁。那为什么这帮“小屁孩”就可以写原创，而不用像虎嗅那样依赖外部投稿呢？笔者观察得出的结论是：除了这个编辑团队本身较有水准外，他们的优势在于常驻硅谷。从他们的报道中也能看出这一点，他们经常亲临硅谷现场，对产品进行报道，对业界名人进行采访。

　　这是一种很讨巧而且正确的做法。如果是写评论，别说是不经世事的年轻记者，就连业内人士，稍有不慎也会被骂的狗血喷头。写出新意得出结论总不是那么容易的事。而做报道就能很好地弥补这一点。

　　以上就是这三个科技媒体的三条崛起之路：翻译、投稿和原创。你想复制哪条路？前两条路基本已经不能再复制成功，最后一条原创则需要独特的报道资源，当然也要加上本文第一部分中所说的强大的编辑团队，以及第二部分所说的更好的展现方式。

　　下一个牛逼的国内科技媒体，也许就是这样崛起的。

　　来源：投稿，作者：牌巴子博客

评论《一个更加牛逼的科技媒体将如何崛起》的内容...

微博：新浪微博 - 微信公众号：williamlonginfo
月光博客投稿信箱：williamlong.info(at)gmail.com
Created by William Long www.williamlong.info

360案例讲解：如何使用Python?

Thu, 30 Jan 2014 11:01:48 CST

360一共80余个Python项目，6万行Python代码。每个项目提供一个或一组完整的功能集合，每个项目都有自己的 setup.py 文件用来将项目代码打包成 Python 发布包（Distribution），部分项目还使用是 Sphinx 和 reST格式的文本自动生成文档。打包好的Python包被发布到自己搭建的内网（与 pypi.python.org 兼容的私有 pypi 服务器)，而文档保存在内网的类似于 readthedocs 的服务器上。

后台团队的代码主要运行我们自己的Linux服务器集群上，开发和部署的成本比较低，因此使用比较敏捷的开发流程。流程大体上可以分为下面几个步骤：

开发：这个步骤当中，开发人员在开发机上面写代码实现功能，不同的开发人员的开发环境使用扩展过的 virtualenv 脚本进行隔离；
单元测试：开发人员负责对代码当中的关键部分进行单元测试，通常使用 unittest，使用 nose 将测试用例聚合和进行回归测试，不定期使用 coverage 确定代码测试覆盖率（集成在nose当中）。这一步还会使用 PyLint 对代码进行扫描；
构建：使用 python distribute 将 Python代码构建成包，同时将这个包发布到测试版 pypi 服务器（pypi-testing），测试版pypi服务器是我们搭建的若干个私有pypi其中之一，发布工作使用的是我们扩展的 distribute 命令；
测试：在测试机器或测试流程当中，从测试版pypi当中获取最新的库并测试，这个部署过程我们使用 distribute 提供的 easy_install 工具进行；
发布：将经过测试的包从测试版pypi服务器移到发布版pypi服务器，这个同样通过扩展的 distribute 命令；
部署：运维人员从发布版pypi服务器上获取最新的库，并更新到真实的服务器上，并应用新的变更。这个过程当中任何一台单机部署使用的都是 easy_install，在分布式环境下，我们使用 Fabric 进行多机部署；
监控：新版本上线之后，会持续通过日志和报警系统进行系统监控。专门扩展了 logging 模块以便适应监控需求。

原文地址： http://blogs.360.cn/blog/how-360-uses-python-0/

2014年值得关注的数字分析新趋势

Wed, 12 Feb 2014 16:09:10 CST

　　这篇文章是我直接写成英文准备发布在英文媒体上。现在先请邢袖迪同学帮我把我这不合格的英语翻译出来。我先发表在我的博客上，请同学们斧正。

　　2014年值得关注的数字分析新趋势，原文：宋星；翻译：邢袖迪。

　　为了制定恰当的数字营销策略，我建议广告主要始终关注目标受众。但是，目标受众并非一成不变，他们像溪流一样从一个地方流向别处。不久以前他们还通常活跃在数百万的网站上，但现在他们在移动设备上花费更多的时间。他们比以前更加难以监测和识别，花费的时间更加碎片化，兴趣点也变得易于分散。

　　我们需要校正我们的工具来监测他们，去发现他们在哪里、有什么行为、有什么兴趣，并立刻调整我们的营销战略和战术。否则若是他们突然从网站上溜走，就可能再也不会回来了。因此，我们必须更新那些传统的数字分析观念。

网站依然重要，但需要从新视角去衡量

　　移动的时代到来，人们开始谈论App应用程序；但这并不意味着我们可以抛弃网站。为了满足受众的好奇，强化他们的喜好，并且实现转化，网站依然在数字营销中扮演着决定性的“终结者”角色。在移动领域常用的数字营销方法是从第三方的App应用中获取流量，引导到广告主的官方活动着陆页。这样的话，我们依然需要留意一些网站的关键指标，比如吸引、劝导和转化的能力。我们还需要关注一些关键业绩指标(KPI)，比如说跳出率、转化率、访问深度和访问停留时间等。

　　但有一点不同：就在两三年前，访问数还是网站分析的关键指标。我们分析受众在一个访问范围内的行为。一些重要的指标都是用访问数（visit）作为分母计算出来的，例如跳出率或访问深度。但是，这样做的明显缺陷是一次访问只是访客在该网站整个生命周期中的一个片段；如果我们基于访问进行分析，就不得不也基于访问去进行优化。访客从知道你的网站到完成购买，不只发生在一次访问之内，而是需要多次访问。另一个问题是访客往往不会总是通过同一个渠道访问网站，他会通过多种渠道。搜索引擎、社交网络和其它来源共同促成了同一个转化的情况非常普遍。为了了解更加复杂的现实世界，你必须考虑衡量和分析访客的行为，而不再是访问的行为。这就是说基于访问的分析不足以再帮助我们了；我们需要跨访问（pan-visit）的分析，它是基于访客而不是访问的。对此，一些建议如下：

1) 必须进行跨渠道/多渠道分析。需要分析的不只是单一渠道的表现，而是多渠道的综合表现。因为多渠道涉及到了同一个访客的决策制定过程，通过跨渠道分析你可以发现1+1大于2的效果，或者相反的效果。这对我们制定有效的渠道策略至关重要。

2) 细分访客，而不是访问。很多网站分析工具提供了细分不同访客的功能，但有的却只能细分访问。选择前者，自定义属于自己的访客细分方法，将了解到关于他们的全景信息。比如说，看一下那些通过我们网站下单的访客通常都有什么行为？没有下单的呢？你都可以轻松的获得答案。

3) 分析一个访客的生命周期。从访客在网站的所有交互行为来看，访问只是一些独立的片段。我们应该开展跨访问分析，去关注下单回访率，而不仅仅是回访次数；去关注购买衰减率或增长率，而不仅仅是转化率。

只有跨渠道分析还不够

　　上文中提到了跨渠道分析，但这还不足以了解访客的行为，原因在于一个更新的挑战的出现：移动互联网。人们开始在移动设备上花费更多的时间。Facebook宣布现在每天有48%的用户只使用移动设备登录它的网站。还在考虑跨渠道分析？现在应该做到跨终端分析了！

　　越来越多的网站访问来自于多终端设备。SAP所做的一项调查显示，67%的访客从一个设备上开始购物，然后在另外一个设备上继续操作。这就是现实：如果你想监测真正的访客，你必须有跨屏的监测方法。我们传统的监测方法是基于cookie的，但是访客使用一个新的设备时，会产生一个新的cookie，也随之被标记为一个新访客。这当然是不对的。即使访客拥有两种或者更多的设备，我们也希望把他只标记为一个访客。此外，我们还想知道他在不同设备之间的行为。

　　这是一个需要克服的新挑战。幸运的是，我们有了新的方法来应对。Google这个业界巨头利用用户的ID（UID）去监测跨设备的访问行为。一些公司也在通过大数据技术计算访客的行为方式，去判断某些访客是否是同一个人。更多的公司在使用数字指纹或者相关的技术去替代传统的cookies技术。Google似乎很有优势，但其他方法也不乏机会。可以非常确定的是，我们离完美的解决这个问题的时间已经非常近了。对此，一些建议如下：

1) 留意跨终端/多屏幕的监测方案。Google推出的Universal Analytics已经整合了这一特性，并且即将发布。

2) 跨终端分析没有那么困难。通常来讲，你需要做三件事：通过设备的重叠数据，找出访客同时使用的设备是哪些；通过设备访问路径，找出不同设备所发挥的不同作用（这里很像跨渠道分析）；通过细分访客，找出在行为方式上使用多种终端的异同。

大数据，大舞台

　　现在我们比以往更加依赖于大数据。在当前的数字营销中，一个重大的变革是程序化的广告购买。为了实现实时竞价，需要使用大数据技术。这一趋势也将影响到数字分析模式。以前，我们人工的进行分析（特别是在渠道/广告分析中），但是在实时广告中这明显是行不通的。分析、建议和优化也都应该实时的进行。为了做到这一点，唯一的办法就是大数据技术和相关的程序化分析。一种可以被整合到不同DSP（Demand Side Platform广告主服务平台）的第三方的程序化分析解决方案将很受欢迎。

　　预测分析也将成为2014年的一大重要趋势。没有大数据技术，在这个领域将很难有所作为。借助大数据，我们能得到更完美的答案。同时，预测分析的模式也受到大数据技术的影响。我们不再需要挖掘事物的因果性，而只要让大数据的“汽轮机”去挖掘出相关性就可以了。投入的数据量越大，做出的预测分析就越精确。基于这种精确预测的市场策略是革命性的，也是极其诱人的。

　　当然这里也有不少挑战：首先是从哪里可以获得这些大数据。DSP可以借助DMP（Data Management Platform数据管理平台），搜索营销机构可以借助SEM（Search Engine Marketing搜索引擎营销）的程序优化供应商，例如EF或Marin；但是其他的营销方式呢？因为目标受众总是在变化的，因此对与时俱进的、精确的关于受众构成的大数据总是有着刚性需求。其次，可以在毫秒级处理大数据的超级算法也非常紧缺。在2014年，这些问题的研究有望取得显著进展。对此，一些建议如下：

1) 大数据对数字营销的影响远远超出你的想象。我们需要关注程序化广告购买，并找到一个可靠的程序分析供应商，这可以是DSP、DMP或者一家第三方咨询公司。

2) 目前看来，大数据并不能解决所有问题。尽管它很具有吸引力，但传统的分析是不会被取代的。大数据可以帮助你程序化的购买广告，但却不能解释为何你的网站转化率下降了。可以通过咨询公司获得一些专业的建议，去决定哪些地方需要大数据，哪些地方仍然需要人工分析。

Zemanta

从打动乔布斯那句话看移动互联网

Tue, 11 Feb 2014 07:59:34 CST

2004年1月，刚刚成为摩托罗拉CEO的爱德华·詹德从芝加哥飞往硅谷，约见苹果公司的史蒂夫·乔布斯，想谈合作。

詹德深知乔布斯的雄辩，所以在双方会面之前，詹德已经做好了准备。

要知道，在当时，乔布斯于2001年底推出的那款纯白色、晶莹剔透的iPod销量正佳，是不折不扣的明星产品。

而摩托罗拉，基本上好像是摩托被骡子拉，已经出现江河日下的颓势。

爱德华·詹德又刚刚接手公司，摩托罗拉没有一款重量级产品可以当做谈判筹码。如何让苹果与自己合作呢？

何况乔布斯对手机似乎并没有那么强烈的兴趣。

因为早在2001年，苹果设计师迈克尔·赵曾劝乔布斯进军手机市场，乔布斯不以为然， “我们为什么要进入这个领域呢?我们不了解这个领域，我们能够在其中做些什么呢?”

后来，苹果公司也尝试秘密研发智能手机，但隔行如隔山，到2004年，苹果手机尚未成型。此外，iPod的成功可能让乔布斯对智能手机的研发不太着急。

而另一头，新官上任三把火的詹德很着急，2004年初的摩托罗拉正处于艰难的转型期。那时候，正是摩托罗拉股价暴跌的时候，也是其对手诺基亚的股价蒸蒸日上的时候。

有人说过，“ 不幸福不是你没有什么，是你的邻居有而你没有。”

作为空降兵，詹德能够通过摩托罗拉董事会的面试关键在于他说了一句话。

当摩托罗拉董事会成员问：“摩托罗拉代表什么?”詹德一边嚼着嘴里的鱼，一边看着自己放在桌上的手机——一款镶有蝙蝠似的“M”标志的摩托罗拉手机。“答案就在这儿。”詹德说，“ M代表Mobile(移动) ，必须牢牢抓住移动做文章。”

一句话，打动了董事会成员，他入主摩托罗拉，现在，他需要用一句话来打动乔布斯。

所以，詹德一直苦思他认为足以打动对方的“那一句话”。

这句话为：

“ 如果你只能随身带三件东西，你会带什么？”几乎不用等待对方回答，詹德继续说：“ 我们做过的调查是，人们最需要的是钥匙、钱包和手机……抱歉，没有iPod 。”

詹德“iPod不在这张清单内”这句话，让乔布斯认识到智能手机将是他引以为豪的iPod“掘墓人”。

詹德这句话，让乔布斯立马同意合作。

乔布斯迅速应允把苹果的音乐播放及销售平台iTunes向摩托罗拉开放，双方合作一款突出音乐功能的手机，这就是2005年底推出的ROKR。

但这种合作有着先天的利益冲突：摩托罗拉希望打造一款取代iPod的产品，可这并不是苹果乐于见到的。

詹德的洞察打动了乔布斯，但乔布斯下定决心， 如果iPod真的会被具有音乐功能的手机取代，那它也应该被苹果的手机取代。所以，从2004年中起，苹果即开始在高度保密下开发iPhone。

于是，2007年1月10日，人们在乔布斯的演示下，见证了第一台布iPhone，尽管iPhone并没有“重新发明”手机上的种种功能，而完全是手机、iPod和掌上电脑的功能混搭，但是他足以创造让人尖叫的兴奋和惊喜。

通过上述故事，我想说的是，iPhone不仅仅是一次好奇带来的革新产品，它的诞生本身就意味着乔布斯回归苹果十年来重新塑造一家公司的核心竞争力， 这个核心竞争力就是移动互联网。

还记得故事中，詹德的入选吗，他说，“ M代表Mobile(移动) ，必须牢牢抓住移动做文章。”

还记得詹德那句话吗？“ 如果你只能随身带三件东西，你会带什么？我们做过的调查是，人们最需要的是钥匙、钱包和手机……抱歉，没有iPod。”

联想你现在，你每天看多少遍手机呢？你都用手机干什么呢？你手机一天陪你多长时间呢？马化腾的抢红包让多少人绑定了银行卡呢？……

移动互联网已经全方位融入我们的生活。

多年前，詹德和乔布斯都洞察到了。

你呢？

面对即将到来的移动互联网，会有什么样的变化呢？

移动正在改变世界

新兴市场时移动终端的天下，我们要做的只有两个字：改变。

因为，智能手机正在改变人们的行为、互动方式、消费方式和生活方式。

你知道吗？在日本消费者多使用手机付款而非信用卡；在韩国，免费的手机电视已经播放了七八年，在本书撰写的2011年，就已经有3000万用户定期使用手机观看电视节目。

面对，不受限制的移动消费群，移动革命已经开始。这种革命并非只是技术方面的变革，更重要是，消费者行为方面的根本性变化，这些变化永久性地改变了营销规则。

用荣老师的话讲， 企业要学会在移动化的世界对消费者进行营销，否则，收拾收拾准备倒闭吧。

这绝对不是危言耸听，就和当年乔布斯推出手机后，说领先业内手机5年以上，诺基亚对之嗤之以鼻。最后，诺基亚被革命了。

移动平台个性化

因为移动的存在，消费者就是移动平台。而且是一个个性化的移动平台。

世界上没有两个人是完全一样的，智能手机也是如此。

每一部手机都是高度个性化的，与主人形影不离，每部手机的通讯录、应用程序以程序的排放顺序也不相同。

每个人都生活在自己的移动世界里，且独一无二。

品牌脱媒现象

在这种个性化的平台，手机带一种行为的变革，就是朋友圈的信息交换。

以后会有越来越多的恶人在购物时会与朋友打电话，询问他们对某个商品的评价。

或者直接看到，某款商品自己的相关关系人的评价。

这就会出现“品牌脱媒现象”，品牌和营销者都被排除在外，你做再多广告、再找大牌明星也没有用，消费者可能会听从朋友的建议而决定买或不买。

面对上述变化，在移动化的世界你做好准备了吗？

有一个高管说，你所有的消费者都在移动终端上，而你却只在上面分配2%的广告预算。

这个还不算糟糕的，我经常和企业打交道，很多企业在移动互联网领域是零准备、零预算。

可想而知，未来的移动化世界里，你的品牌已经丧失了露脸的机会。那在移动互联网的浪潮面前，我们企业营销该如何做呢？

我认为，至少我们要了解移动营销的三板斧。

移动营销三板斧

也就是说，基于前面提到的趋势，移动营销也不用想得太复杂，三件事做好了，移动营销就能做好。

1、引客上门：现在有很多方式，APP是一种、微信是一种、做内容营销也是一种，电子优惠、其他激励措施都可以尝试，总之，你需要通过这些沉淀客户资源，打造客户资源池。

2、留住顾客：吸引客户关注你，加入你的圈子，你要给他们有价值的东西，比如某方面的实用资讯，以便长久地留住顾客；

3、促成交易：在长期提供价值过程中，适当把你的产品或服务融入顾客价值的一部分，水到渠成地提供给他们，基于客户终身价值管理的方式，为他们提供产品，先交流、再交易，然后最后就是铁杆交情。

这营销三板斧，目的是把用户通过手机引入到你的销售体系当中来，能够吸引更多客户，做到持续交易。

总之，当今天我们谈到移动互联网的时候，似乎大家都认可这一趋势。从先知者詹德也好，乔布斯也罢，在移动互联网的时代，我们需要铭记这句让乔布斯有所触动并作出决策的话： iPod不在这张清单内。

这句话已经点出了一个关键，未来最具效力的营销方式只有一种，就是你是否进入消费者的手机，不夸张的说，手机已经决定了你的未来。

敬请关注微信公共平台“荣振环微书评”：这是中国最为睿智的移动互联、营销与品牌、新技术、新思维的微书评。微信号：rongzhenhuan.

荣振环图书推荐，每日推荐一本好书。让你“好读书、读好书、读书好”。好书活用，智慧伴侣。中间穿插微品牌策略、微营销策略、微文化智慧。让你学到即能用到。每日一书，人生不输。

欢迎朋友们把好书分享给你的朋友，传递书香，共享智慧。

猜您喜欢：
从乔布斯传看移动互联网急需的六种能力	谁是移动互联网第一品牌？	荣振环：我为何断言苹果会走下坡路	移动互联网时代，聊天仍然是门好生意	移动金融创新案例，Simple用互联网的方式改造传统银行业务 \| 商业不靠谱
无觅

本文版权属于- 商业不靠谱 Bukop.com -转载请务必保留版权信息。
商业不靠谱（bukop.com）致力于汇聚全球新兴的商业模式与创新趋势，在全球范围内整合优秀商业创意和案例，并将这些好点子提供给具有企业家头脑的创业者，以及对创新和挖掘新商机有兴趣的朋友。

优化WordPress速度为服务器和访客减压

Mon, 10 Feb 2014 10:45:41 CST

如果你用wordpress来做CMS站点那么你如果用主机托管那么一定杯具了，用VPS内存小了宽带小了也麻烦。其他人都是教了一招，这次我汇集百家所长，十招齐发，十管齐下，勇者无敌！大家多说时间就是生命，可能几秒钟的等待就会让网站失去一个访客，对于网站的速度你不能等！ 1.Cookie的静态化制作 约有80％至90％的时间，访客要花费大量的时间等你的WordPress加载静态内容。这意味着，有大部分的时间，用户浏览您的网站，他们正在等待加载，如：图像，CSS，JS脚本，flash等等。所以你可以优化内容，更快捷地让WordPress加载一个cookie域。消除了负载时的一些珍贵的时间，当然了这可能看起来并不多，但添加其他拖延问题时，才能真正减少时间损失。我不知道其他源码的网站应该怎么做，但是wordpress很简单只要修改一下wp-config.php就好了！在合适的位置加入：

define(“WP_CONTENT_URL”, “http://static.***.com”); define(“COOKIE_DOMAIN”, “www.***.com”);

然后用“bloginfo(template_directory’)”这段代码加入你要实现的静态内容中即可！ 2.设置静态内容的缓存 静态的内容缓存，我就不多介绍了，你用相关的缓存插件也需要这个步骤，那就是修改.htaccess文件代码如下：

<IfModule mod_expires.c> ExpiresActive on # Perhaps better to whitelist expires rules? Perhaps. ExpiresDefault “access plus 1 month” # cache.appcache needs re-requests # in FF 3.6 (thx Remy ~Introducing HTML5) ExpiresByType text/cache-manifest “access plus 0 seconds” # Your document html ExpiresByType text/html “access plus 0 seconds” # Data ExpiresByType text/xml “access plus 0 seconds” ExpiresByType application/xml “access plus 0 seconds” ExpiresByType application/json “access plus 0 seconds” # RSS feed ExpiresByType application/rss+xml “access plus 1 hour” # Favicon (cannot be renamed) ExpiresByType image/x-icon “access plus 1 week” # Media: images, video, audio ExpiresByType image/gif “access plus 1 month” ExpiresByType image/png “access plus 1 month” ExpiresByType image/jpg “access plus 1 month” ExpiresByType image/jpeg “access plus 1 month” ExpiresByType video/ogg “access plus 1 month” ExpiresByType audio/ogg “access plus 1 month” ExpiresByType video/mp4 “access plus 1 month” ExpiresByType video/webm “access plus 1 month” # HTC files (css3pie) ExpiresByType text/x-component “access plus 1 month” # Webfonts ExpiresByType font/truetype “access plus 1 month” ExpiresByType font/opentype “access plus 1 month” ExpiresByType application/x-font-woff “access plus 1 month” ExpiresByType image/svg+xml “access plus 1 month” ExpiresByType application/vnd.ms-fontobject “access plus 1 month” # CSS and JavaScript ExpiresByType text/css “access plus 1 year” ExpiresByType application/javascript “access plus 1 year” ExpiresByType text/javascript “access plus 1 year” <IfModule mod_headers.c> Header append Cache-Control “public” </IfModule> </IfModule>

3.优化数据库 有一个方法来为的服务器减压，怎样才能优化wordpress的数据库呢？自然是用代码，用代码，嘿嘿，你可能编辑了几个小时都没有效果！WordPress的免费插件使得这个问题变得简单，个人推荐Yoast Optimize DB和WP DB Manager。牢记大多数缓存插件还帮助了很多本，所以你会发现大多数正在采取照顾您已经现存的缓存软件的工作量。 4.尽量缓存媒体 创建缓存可以很简单地通过插件完成。从本质上讲，这些新增转成静态页面，所有这些方式，既方便加载，又节省您的浏览器前端的滞后。那么，什么插件，听我的建议吧。我最喜欢的缓存工具：WP Super Cache， Hyper Cache，和W3 Total Cache。用这些生成HTML文件，可以节省更多的时间。 5.使用CDN CDN加速目前很火，那么自然火是有一定的道理的，因为CDN可以加速呀。呵呵，cdn一般是收费，不过免费的CDN也有。下面为大家推荐一些实用的免费CDN：免费CDN：Webluker，cloudflare 6.压缩JS和CSS文件 你可能只听过说JS和CSS文件的库转移，总没有听说过压缩吧。呵呵，这个方法是很异想天开，但是就是有人做到了，并且开发了压缩的实用工具，当然机器的压缩并不尽人意，你也可以手工压缩。 JS压缩工具推荐：Closure Compiler ，Minify JavaScript. CSS压缩工具推荐：Minify CSS ，CSS Compressor 7.压缩图像 图像的加载也是比较耗时的，想你如果试用BMP或者PSD作为图像那么速度一定和蜗牛爬一样，比较高质量保存的PNG文件我也不怎么推荐。建议试用JPG压缩，但是也不要过度！不然图片会失真。通过WP Smush.it插件你可以比较简单的来压缩图片！ 8.GZIP压缩 GZIP的压缩在一定限度内是很不错的！而且通过gzip压缩不仅能够加速而且还可以屏蔽广告（免费空间的福音啊）GZIP的压缩代码交给你！修改.htaccess文件

<IfModule mod_deflate.c> # force deflate for mangled headers # developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/ <IfModule mod_setenvif.c> <IfModule mod_headers.c> SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)s*,?s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding RequestHeader append Accept-Encoding “gzip,deflate” env=HAVE_Accept-Encoding </IfModule> </IfModule> # HTML, TXT, CSS, JavaScript, JSON, XML, HTC: <IfModule filter_module> FilterDeclare COMPRESS FilterProvider COMPRESS DEFLATE resp=Content-Type $text/html FilterProvider COMPRESS DEFLATE resp=Content-Type $text/css FilterProvider COMPRESS DEFLATE resp=Content-Type $text/plain FilterProvider COMPRESS DEFLATE resp=Content-Type $text/xml FilterProvider COMPRESS DEFLATE resp=Content-Type $text/x-component FilterProvider COMPRESS DEFLATE resp=Content-Type $application/javascript FilterProvider COMPRESS DEFLATE resp=Content-Type $application/json FilterProvider COMPRESS DEFLATE resp=Content-Type $application/xml FilterProvider COMPRESS DEFLATE resp=Content-Type $application/xhtml+xml FilterProvider COMPRESS DEFLATE resp=Content-Type $application/rss+xml FilterProvider COMPRESS DEFLATE resp=Content-Type $application/atom+xml FilterProvider COMPRESS DEFLATE resp=Content-Type $application/vnd.ms-fontobject FilterProvider COMPRESS DEFLATE resp=Content-Type $image/svg+xml FilterProvider COMPRESS DEFLATE resp=Content-Type $application/x-font-ttf FilterProvider COMPRESS DEFLATE resp=Content-Type $font/opentype FilterChain COMPRESS FilterProtocol COMPRESS DEFLATE change=yes;byteranges=no </IfModule> <IfModule !mod_filter.c> # Legacy versions of Apache AddOutputFilterByType DEFLATE text/html text/plain text/css application/json AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE text/xml application/xml text/x-component AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml AddOutputFilterByType DEFLATE image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype </IfModule> </IfModule>

9.禁用ETAGS ETAGS可能我也搞不懂，但是你仅用了它就可以加速了，所以你管他神马ETAGS你说是不？在.htaccess 文件中+这一行！

File ETag none

10.服务器环境 使用LAMP环境或者LNMP环境，可以更好的支持wordpress并且风险系数低，也很安全，估计你的服务器或者VPS几年都不会重启一次，所以网上总是我自己的linux密码忘记了重启怎么办！这就是免费惹的祸，真是躺着也中枪啊！ 总结： 这些方法中大多数只适合在LAMP或者LNMP的环境下，所以使用wordpress就必须要在linux环境下，win环境下的wordpress你会遇到一些列的问题！

The post 优化WordPress速度为服务器和访客减压 appeared first on 神刀网.

40+新鲜的WEB开发人员开发框架和工具

Wed, 26 Mar 2014 10:24:39 CST

对于现在很多WEB开发人员来说，项目的效率就是一切，因为时间就是金钱。很多人都不在自己的模式里捣鼓研究了，而是用各种流行的框架和第三方平台去让项目更快的推进。今天我们要分享给大家的就是一些新鲜的WEB框架和开发工具。这些工具也是一些GEEK长时间的总结研究出的一套体系。用框架的好处就在于，只要你是正确的架构就能不用担心太多自身的漏洞和BUG。可以避免走很多弯路。好好研究使用起来吧。会让你事半功倍的！

Phalcon

Phalcon is a web framework delivered as a C extension providing high performance and lower resource consumption.

YARD

YARD is the only Ruby documentation tool that supports storing metadata alongside your documentation. This metadata can be used to create consistent documentation in any format you wish. YARD also comes with a powerful templating system to quickly modify existing templates. And for the simple case, you can even add custom metadata to your docs with nothing but the command-line.

Koala

Koala is a GUI application for Less, Sass, Compass and CoffeeScript compilation, to help web developers to use them more efficiently. Koala can run in windows, linux and mac.

Duo

Duo is a web browser that allows you to keep an eye on mobile without losing sight of the desktop. If you’re into Responsive Web Development, we made Duo for you.

Lighttable

Light Table is a new interactive IDE that lets you modify running programs and embed anything from websites to games.

Laravel

Laravel is a web application framework with expressive, elegant syntax. We believe development must be an enjoyable, creative experience to be truly fulfilling.

DevDocs

DevDocs combines multiple API documentations in a fast, organized, and searchable interface.

Myth

A CSS preprocessor that acts like a polyfill for future versions of the spec.

Docker

Docker is an open-source project to easily create lightweight, portable, self-sufficient containers from any application. The same container that a developer builds and tests on a laptop can run at scale, in production, on VMs, bare metal, OpenStack clusters, public clouds and more

Varycode

VaryCode team is a group of professionals focused on programming code conversions between different programming languages.

Jiko

Jiko is a modern and easy to use template engine for Javascript. Its objective is to provide to Javascript programmers a way to write templates with an engine as powerful as server-side state of the art template engines like Jinja and Mako.

Cabot

Cabot is a free, open-source, self-hosted infrastructure monitoring platform that provides some of the best features of PagerDuty, Server Density, Pingdom and Nagios without their cost and complexity.

CountUp.js

countUp.js is a dependency-free, lightweight JavaScript “class” that can be used to quickly create animations that display numerical data in a more interesting way.

Convnetjs

ConvNetJS implements Deep Learning models and learning algorithms as well as nice browser-based demos, all in Javascript.

Highlight.js

Highlight.js highlights syntax in code examples on blogs, forums and, in fact, on any web page. It’s very easy to use because it works automatically: finds blocks of code, detects a language, highlights it.

ScrollReveal.js

A simple way to create and maintain how elements fade in, triggered when they enter the viewport.

Epub.js

Epub.js is a JavaScript library for rendering ePub documents in the browser, across many devices.

Circles

A lightweight JavaScript library that generates circular graphs in SVG.

Switchery

Switchery is a simple component that helps you turn your default HTML checkbox inputs into beautiful iOS 7 style switches in just few simple steps. You can easily customize switches, so that they match your design perfectly.

Uinames

Uinames.com is a simple tool to generate names for use in designs and mockups.

Bijou

A beautiful CSS framework under 2kb (minified and gzip).

Slip

A tiny library for interactive swiping and reordering of elements in lists on touch screens.

Zeptobuilder

Zepto Builder will let you generate a custom version of Zepto that just includes the modules you need.

Gridism

A simple responsive CSS grid.

Hubot

Hubot is your company’s robot. Install him in your company to dramatically improve and reduce employee efficiency.

You Complete Me

YouCompleteMe is a fast, as-you-type, fuzzy-search code completion engine for Vim. It has several completion engines: an identifier-based engine that works with every programming language, a semantic, Clang-based engine that provides native semantic code completion for C/C++/Objective-C/Objective-C++ (from now on referred to as “the C-family languages”), a Jedi-based completion engine for Python, an OmniSharp-based completion engine for C# and an omnifunc-based completer that uses data from Vim’s omnicomplete system to provide semantic completions for many other languages (Ruby, PHP etc.).

Nightcode

Nightcode is a simple IDE for Clojure and Java. It integrates a copy of Leiningen as well as the lein-cljsbuild, lein-droid, and lein-fruit plugins. The goal is to provide a simple, all-in-one solution to get started with Clojure/Java programming for the command line, the desktop, the web, Android, and iOS.

HTML5 Drag & Swap Zepto Plugin

A micro plugin for having swappable/dragable/sortable lists and grids.

Twittstrap

Twittstrap Sleek,intuitive,and powerful front-end framework for faster and easier web development.

Revel

A high productivity web framework for the Go language, in the spirit of Rails and Play!

Daux.io

Daux.io is an documentation generator that uses a simple folder structure and Markdown files to create custom documentation on the fly. It helps you create great looking documentation in a developer friendly way.

Cardinal

Cardinal is a small “mobile first” CSS framework, with useful default styles, fluid typography, and a responsive grid system.

Pocketgrid

PocketGrid is a lightweight pure CSS grid system for Responsive Web Design. Moreover, it is semantic, mobile-first, and allows to have an unlimited number of columns and breakpoints.

Fitgrd

Fitgrd is not a framework. It’s a solid foundation to build up your own responsive website. It is designed for rapid prototyping, but also runs well in production environments. This grid system is perfect for advanced web designers who don’t want to have their pages look like “bootstraped”.

Kraken

A lightweight, mobile-first boilerplate for front-end web developers.

Preboot

Preboot is a collection of LESS mixins and variables for quickly writing CSS. As the precursor to Bootstrap, it serves as a lightweight and interface agnostic approach to jumpstarting your next web project. Use it how you see fit.

Girder

A minimalistic grid for building awesome Websites for the modern browser. It uses Sass silent classes (placeholders) to structure content in HTML and keeps your Markup free of excess presentational classes like “unit_1of4″, “small-2″, “grid4″.

Typeplate

Frameworks make decisions for you about how to organize, structure and design a site. Pattern libraries don’t separate styling and markup, making them tough to use in a truly modular fashion.

Topcoat

CSS for clean and fast web apps.

Responsablecss

Framework for getting started with the Responsable grid.

Clank

Clank is an open source HTML/CSS prototyping framework for tablet and smartphone apps. Think of it as Twitter Bootstrap but for prototyping native apps.

Responsive Web Css

Spending hours manually designing your pages for the responsive web? Layout your pages in minutes for beautifully responsive pages on desktops, tablets and smartphones.

Via

猜您也喜欢：
2014年3月-设计师和开发人员新鲜资源	50个WEB开发人员需要的jQuery插件	WEB设计师和开发人员需要的新鲜资源	7个开发人员和设计师适用的WEB应用资源
无觅

50个WEB开发人员需要的jQuery插件

Thu, 26 Dec 2013 11:26:50 CST

jQuery插件是很多前端开发人员和网页设计师都会设计的东西。我不得不说这是一个伟大的东西。这些插件大大的缩短了工作时间，调高了设计开发人员的效率。也更便捷的让人做出选择。精力的缩减对于开发人员来说是绝对需要的。那如何去获取这些好的插件呢。那么除了需要你有好的用户体验的经验还要学会去搜集优秀的插件以备未来使用。今天我们要分享出来的就是一些非常优秀的jQuery插件。你可以试着使用这些插件。去了解这些插件带来的体验和便捷。让你得到更多的灵感和创意。

Vortex

( Demo | Download )

CLNDR.js

( Demo | Download )

Selectric

( Demo | Download )

FullPaged

( Demo | Download )

jQuery Mapael – Build dynamic vector maps

( Demo | Download )

Swatches

( Demo | Download )

Block Slide

( Demo | Download )

Toolbar.js

( Demo | Download )

jqTimeline

( Demo | Download )

jQuery Spellchecker

( Demo | Download )

ScrollUp

( Demo | Download )

Nod Frontend Validation

( Demo | Download )

Any List Scroller

( Demo | Download )

Tumbo 1.0 – Show Tumblr feeds on your website – Jquery plugin

( Demo | Download )

Responsive Text

( Demo | Download )

ImageFill-js

( Demo | Download )

Tipue Drop

( Demo | Download )

Resizable Columns

( Demo | Download )

BIGVIDEO.JS

( Demo | Download )

stickUp

( Demo | Download )

Tabslet

( Demo | Download )

Offreg

( Demo | Download )

jQuery Fullscreen Editor

( Demo | Download )

jVanilla Menu

( Demo | Download )

Snap.svg

( Demo | Download )

Moa Modal

( Demo | Download )

Succinct

( Demo | Download )

FailSafe

( Demo | Download )

onScreen

( Demo | Download )

Touche.js

( Demo | Download )

Offline.js

( Demo | Download )

Peeler.js

( Demo | Download )

Mobify.js

( Demo | Download )

At.js

( Demo | Download )

Scrolld.js

( Demo | Download )

Resumable.js

( Demo | Download )

WhatsNearby

( Demo | Download )

Isotope

( Demo | Download )

Minimalect

( Demo | Download )

EasyDropDown

( Demo | Download )

Selectize.js

( Demo | Download )

Nivo Lightbox

( Demo | Download )

jQuery CollagePlus

( Demo | Download )

FilmRoll

( Demo | Download )

Glide.js

( Demo | Download )

Excolo Slider

( Demo | Download )

CarouFredSel

( Demo | Download )

OWL Carousel

( Demo | Download )

Sticky-Kit

( Demo | Download )

FlowType.JS

( Demo | Download )

Via

猜您也喜欢：
42个新鲜的开发人员资源素材	10有趣的轻量级jQuery插件的Web开发	WEB设计师和开发人员需要的新鲜资源	WEB设计师和开发人员需要的新鲜资源
无觅

IE11可以自动使40%以上的网站变得更安全

Fri, 15 Nov 2013 13:27:47 CST

Internet Explorer 11 是首款使 Internet 连接变得更安全可靠的浏览器，其采用的具体方法是通过减少易受攻击的密码集（例如，RC4）的使用，以及在默认情况下使用最新的安全标准 TLS 1.2。通过 IE11 中的这些更改，您可以放心地访问社交媒体、银行、商业和其他网站上的重要个人信息。这些改进基于我们为使 IE 在社交工程攻击等关键方面成为最安全的浏览器而做出的不懈努力。

IE11 减少了对易受攻击的 RC4 密码集的使用

通过减少对易受攻击的 RC4 密码集的使用，IE11 在提升安全性方面向前迈进了一大步。RC4 是一种受到 TLS 服务器的广泛支持（通常为首选）的流密码。但是，最新研究（例如由 AlFardan 进行的研究）揭示了利用可用于恢复一些加密数据的 RC4 密钥流进行攻击的行为。 Paul、 Mantin 和 Fluhrer 还发现 RC4 存在其他的缺陷。基于这些研究所达成的业内共识是：RC4 存在着各种各样的加密缺陷，利用 RC4 的攻击目前切实可行。我们已建议对 TLS 标准进行更改，以便其他浏览器和业内人士可以和我们一起使 Web 变得更安全。

IE11 中的这些更改提高了安全性，同时仍然能够确保与 Web 的兼容性，尽管 RC4 密码集目前已被广泛使用。在初始 TLS/SSL 握手期间，IE11 不提供基于 RC4 的密码集。这样，大多数连接都可以成功地使用非 RC4 密码集。通过对 500 万个 Internet 站点进行研究，我们发现超过 96% 的站点可以协商除 RC4 之外的其他密码。值得注意的是，在这些网站中，有近 39% 的网站支持非 RC4 密码（尽管他们首选 RC4 密码）– 对于这些网站，IE11 显著提升了 Web 的安全性。

网站类型	数量	百分比	IE11 的行为
示例网站总数	5,000,000	100%
当前使用 RC4 密码的网站	2,127,500	42.55%
支持非 RC4 密码的网站	1,932,500	38.65%	通过协商非 RC4 密码，IE11 使网站变得更安全
仅使用 RC4 密码的网站	195,000	3.90%	IE11 确保您可以通过继续使用 RC4 密码来访问这些网站
当前未使用 RC4 密码的网站	2,872,500	57.45%	IE11 继续与这些网站协商非 RC4 密码

一项针对 500 万个 Internet 站点进行的研究显示，在不影响兼容性的情况下，IE11 可以自动提升 39% 的网站的安全性
在浏览器无法与服务器协商非 RC4 密码的极个别情况下，IE11 将继续协商使用 RC4 的 TLS 1.0 或 SSL 3.0，以确保您仍然可以访问您需要的网站。Microsoft 正积极与许多这样的网站进行协作，以实现对非 RC4 密码集的支持。

在默认情况下打开 TLS 1.2

通过在默认情况下启用 TLS（1.2 版），并基于 IE 的领导地位（首个将 TLS 1.2 实施为 IE8 中的一个选项的浏览器）而进行构建，IE11 进一步提高了 Web 安全性。您可以使用行业领先的安全标准访问 Outlook.com、Facebook 等网站，从而确保您的个人信息的安全。通过支持更高级的密码集，TLS 1.2 提高了安全性。大多数以 TLS 1.0 和 TLS 1.1 密码为目标的实际利用行为不适用于 TLS 1.2 密码。例如，TLS 1.2 不会受到 BEAST 攻击。

在 IE11 中，您可以利用 TLS 1.2 中增强的安全性，同时获得像使用 RC4 密码一样的性能。TLS 1.2 提供了全新的密码集，可实现强大的安全性和高性能。例如，仅 TLS 1.2 提供了对 AES-GCM 密码集的支持，并且性能像使用 RC4 密码一样出色。通过启用使用 AES-GCM 的 TLS 1.2，网站可以提供强大的安全性，而无需引入额外的服务器负载。

通过优化 IE11 中开箱即用的 TLS 1.2，可以自动提高近 16% 的 Web 服务器的安全级别，并且随着更多的服务器和浏览器开始支持 TLS 1.2 并将其设置为首选，这一数字还将继续增加。自 Windows Server 2008 R2 以来，Windows Server 就已开始支持 TLS 1.2，我们鼓励在服务器的 IIS 配置中启用 TLS 1.2，而这只需一个简单的配置更改即可。诸如 Apache 等服务器也支持 TLS 1.2，并且随着行业的不断发展，未来将有更多的其他 Web 服务器支持 TLS 1.2。这一更改不会影响与现有服务器的兼容性，因为这些服务器会向下协商共同支持的最高 TLS 版本。默认情况下，IE11 支持 TLS 1.2、TLS 1.1、TLS 1.0 和 SSL 3.0。

总结

通过禁止使用易受到攻击的基于 RC4 的密码集，IE11 使 39% 的网站变得更安全，而且通过协商 TLS 1.2（最安全的 TLS 版本），IE11 还提高了 16% 的网站的安全性。

立即试用 IE11 以体验使用最新行业标准的更安全的浏览。我们期待通过 Connect 收到您的反馈，以帮助我们推动行业的发展，并继续改进浏览器。

Hasnat Naveed 和 Ritika Kapadia

Windows 和 Internet Explorer 项目经理

This article addresses: http://www.iefans.net/ie11-zidong-40-wangzhan-anquan/

Here is no comments yet by the time your rss reader get this, Do you want to be the first commentor? Hurry up

网站批量挖掘长尾关键词的方法

Tue, 15 Oct 2013 17:50:45 CST

　　网站大部分的搜索流量来自于单个搜索次数并不多的长尾关键词几乎是每个SEO都知道的事，越是大中型和门户型网站，长尾词的流量占比越重。这也是为什么很多SEO一直在呼喊要重视长尾词，要不停的的去拓展、去优化长尾词关键词的缘故。长尾关键词的挖掘也是一个比较繁琐的活，也是需要长期去做的事情。

　　一般来讲，长尾关键词的拓展方式有以下几种：

　　1、百度下拉框及相关搜索

　　通过对百度下拉框的提示也能获取一些长尾关键词，这些词很大程度上会让用户直接搜索，因此也具有一定的访问量和转化效果，相关搜索也同样如此。但由于下拉框是单体搜索，扩展量比较小，不适宜于大批量的长尾词拓展。

　　2、流量统计工具

　　这也是仅次于搜索引擎后台的关键词又一大量获取真实并有价值的长尾词的方法。借助网站流量统计工具，不仅能分析出网站访问流量的来源，同时也能分析出用户的具体搜索行为，即用户是通过什么搜索词进入网站的。

　　3、客服软件

　　网站常见的客服软件，比如商务通、53kf、乐语等都提供关键词下载工具，这个绝对是用户真实搜索的关键词，并且具有相当的商业和转化价值。当然这其中很大一部分与后台流量统计工具的关键词有重叠，可作为筛选关键词之用。

　　如果可以的话，这些客服公司都有关键词库，不妨想办法要过来一些，扩充一下自身网站的关键词库，岂不美哉!

　　4、问答平台及专业社区

　　像百度知道、搜搜问问、天涯问答这些综合型的问答平台，各行各业的问答都会有，虽然充斥着大量的推广和广告问答，但也有大量的真实用户的问答，所以很大一部分长尾词可能是我们头脑风暴所意想不到的，是继搜索引擎后台关键词工具和流量统计后台关键词挖掘之后的又一大长尾词拓展方法。

　　例如在百度知道搜索某目标关键词时，会出现许多与这个关键词相关的问题，而通过这许多相关问题再搜索时，又会出现更多关于这个关键词的问题，如此循环，可利用的长尾关键词资源可谓源源不绝。

　　一些专业社区或者论坛，如39健康是医疗行业寻找关键词的最佳去处。

　　PS：以上4个方法也可以通过做个简单脚本程序来完成，这样可省去不少人力和时间，给批量挖掘长尾关键词带来方便。

　　5、搜索引擎提供的站长工具/关键词工具

　　谷歌的网站管理员工具和百度的凤巢竞价后台的关键词查询都有拓展关键词的功能，在国内来说，站长和SEO们还是以百度为主，所以百度竞价后台的关键词相对来说比较重要，搜索次数和拓展词量也相对真实可靠。

　　6、站长工具及关键词软件

　　目前站长工具像站长之家、爱站网、站长帮手都有类似的关键词拓展查询，并给出关键词的百度指数、搜索量以及优化难度，在一定程度上也能拓展出一定量的关键词。

　　一些关键词拓展软件，如金花、飞达鲁等，也会根据关键词进行拓展，并产生一些联想词，可以满足站长在量上的要求，但有可能会产生大批无用或无价值无意义的关键词。

　　7、拆分组合

　　把网站目标关键词按一定形式进行拆分，然后在排列组合在一起，产生大批量的长尾关键词是很多网站的通用做法，这虽然并不像搜索引擎后台、流量统计以及问答平台这三种得到的关键词那样在真实性和价值性上性价比高，但同样可以获得大批量的关键词，全方位的把关键词覆盖住，是一种全面撒网式拓展方法。

　　例如做中小学辅导的网站，可以按地区、年级、学科、单元章节、费用、主关键词等来分类，做旅游的，按城市、景点、几日游、费用等进行拆分，然后把这些关键词排列组合。

　　8、头脑风暴

　　头脑风暴是一种最简单直接的关键词拓展方法，但很可惜人工有限，能想到的关键词非常少，所以不适宜批量拓展长尾词。

　　9、其他方法

　　比如去竞争对手网站查看，可自制一些抓取工具把对手网站的长尾词抓取过来，进行去重、筛选等，存入关键词库。或者是利用百度指数、搜索风云榜这些工具，来搜集和拓展一些长尾词。

　　来源：投稿，作者：北漂书生，原文链接。

评论《网站批量挖掘长尾关键词的方法》的内容...

微博：新浪微博 - 腾讯微博
QQ群：10271552
月光博客投稿信箱：williamlong.info(at)gmail.com
Created by William Long www.williamlong.info

中国为什么没有Linkdin？职业社交网络该如何落地？

Fri, 11 Oct 2013 17:45:55 CST

黑马哥今天收到一封前天际网员工的匿名邮件投稿，大致问题是天际网以“造假舞弊”为由辞退了他，却不出具任何证明。前段时间，就有业内消息爆出：“从2012年底开始,分别是原ceo林廷翰离职(创始人)、产品技术VP李杨、mobile部门vp熊兆文离职，之后陆陆续续在市场部，产品部门及数据部门进行了大换血，目前又裁掉了销售vp。前后离职员工超过20人，其中包括很多的核心员工”。黑马哥不禁一身冷汗，一个踏踏实实做职业社交网站的公司，到底怎么了?还是行业出了什么问题?以抄袭著称的中国互联网界，陆陆续续走出了多个上市公司，反而是职业社交网站Linkdin一直被抄袭的一塌糊涂。职业社交网络该如何在中国市场落地?

黑马哥特邀了两位资深社交网络从业大拿来进行分析解答。

中国为什么没有Linkdin?

1、习惯

中国人和外国人的社交习惯不同，外国人有朋友引荐的传统，也习惯于直接联系某人去建立强关系，中国人相对更习惯于混圈子，习惯于在没有和对方有直接合作的时候，保持着一种“认识”但不直接的圈子内的所谓熟人关系，待到真的对对方有需求，才会直接建立强需求。

2、社交不是核心

职业社交四个字，社交并非最终目的和核心需求，社交只是一种手段，用户如果社交，肯定是为了达成自己所希望的一项直接的目的，比如找工作。但是国内很多职业社交网站还是更偏向于社交，而非围绕职业生涯中的直接的某项需求。

3、工具性缺乏

职业社交网站，我们可以定义为“用户是带有很强的目的性的,用社交当作工具的一个平台”核心并非强关系(好友)或若关系(关注)，也并非真实关系(线下认识)或兴趣关系(纯网友)核心应为，用户用网站这个平台，能够解决自己在整个工作的过程当中遇到的什么样的强需求，以及如何设计一系列的工具，去让用户在网站上完成这种需求。

没有以上的这些工具，用户不可能愿意用网站，更别谈社交(活跃)了。

4、大致说说我认为比 较现实的一种职业社交的：roadmap

工具>个人价值>社交价值>平台化价值

但似乎国内的很多公司一上来做的就是第四步

5、太过拘泥于产品具体形态

如果要做解决“职业成长路上的强需求”的产品,我认为唯一必须要有的是一系列强有力的工具至于用户体系，可以是自己的,也可以是第三方的，比如基于微博用户关系,可以是自己的，也可以是第三方的B2C的招聘，可以有也可以没有,毕竟这不是唯一的可用工具web，app，都可以用户活跃，可以追求可以不强求，但是我们看到，国内的职业社交网站的功能和内容基本完全雷同，无太多的创新。

web端的基本都是sns+招聘+feed，问答等内容

app端的基本都是交换名片，分享名片，线下活动，识别名片。

其实可以完全不如此。

职业社交网络该如何在中国市场落地?

1. 一个产品模式要想成功最大的前提是要看准及能够解决用户的实际需求。从这个角度考虑职业社交理论上应该是解决职场人士的交流沟通问题，但是职场人士相对于其他用户来说是一类更看重实际效果的人群，即能够很快给自己带来实利，否则他们不会愿意在这上面花费时间。社交目前已经是一个很泛的需求，而不是一个解决单一实际问题的有效方法。

2.社交体系要想建立及维系下去，社交的参与者之间得有一个连接点，比如一起讨论一个职业问题，有一些内容交换。但是目前的职业社交网站在内容建设上非常乏力。试想一个sns平台如果平台方即不主动产生内容，也不引导用户产生内容，没有UGC机制，那么这个社交平台是很难建立起来的，更何况是陌生人之间的社交。用户活跃度很低这个是职业社交的通病，linkedin也有这个问题，但是它已经在内容上开始发力了，通过购买内容平台等方式。

3. 职业社交相对于其他社交平台来说，专业性应该是需要强化的点，比较遗憾的是目前貌似各方没做或者做得很弱。

4.如果社交机制无法建立，那么剩下能吸引职场人士的就只有所谓高薪职位了，实际上就是招聘求职的套路。这个套路最重要的是什么呢，效率，效率，还是效率。由于平台的局限性导致无法提供充分的职位，所以对用户的吸引力就很低，进而影响招聘效率，进而导致职位更少，最终导致求职效率更低。这是个恶性循环。

5.一个既无社交性，也无娱乐性，更无工具平台的效率性的产品，用户上来无法和其他用户交流(因为活跃度低，你的请求可能很长时间得不到响应)，没有有用的内容可看，没有提高职业技能的手段可参考学习，甚至连最后的找工作都不靠谱时。这个平台就很难维系了。

最后关于天际， 天际的核心问题是内部管理，即一个对中国用户，对中国市场不太了解的法国团队直接按照国外的经验和模式，指挥公司的具体产品策略，不可能不出问题;同时由于法国管理方对中国员工的信任度问题，导致中国员工对公司策略的不同于管理方的意见时不被重视或直接无视。

另外还有个大问题， 据说他们为了向法国投资方交差，直接造虚假用户。当这个比例太大时，即使后续有准确的策略也很难凑效了。很像中国从清末到民国的所有改革措施几乎都失效一样，清廷之前的错误行为延误了最佳治疗时间。最后就只能重装系统了。

如何成为网站数据分析师?

Sat, 26 Oct 2013 11:44:33 CST

如果你想成为网站分析师!想加入网站分析这个即有前途又有“钱途”的行业，那么你至少需要具备本文所提到的9大本领。

1.玩转Excel

1.1.常用函数：

1.2.常用功能：

2.网站分析基础知识

了解一些网站分析的基础知识是必须的，你要知道什么是会话，什么是PV，什么是UU/UV等指标值的含义。如下图(摘自《网站分析基础教程第二章》)所示：

3.网站开发的知识

4.网络营销的知识

4.1.广告类型

搜索引擎广告(PPC)

交换链接

横幅广告

邮件营销

传统媒体广告

4.2.广告相关指标

展现数(Impressions)

点击数

点击率(Click-throughRate)

CPC(CostPerClick)

CPA(CostPerAcquisition)

转化率(ConversionRate)

ROAS(ReturnOnAdvertisingSpend)

4.3.SEO知识

主流搜索引擎的排名算法

TITLE,META,Hn,h1等优化

5.测试方法

做网站分析师需要学会使用如：A/B测试，多变量测试，用户体验测试等测试方法对改善方案进行预评估，以减少新方案的实施风险。

6.交流能力

7.演讲的能力

8.会做PPT

演讲和演示的时候，必备的利器!当然如果你能够做出很炫的动画效果将能感染更多的。

9.计划管理能力

本文链接《如何成为网站数据分析师?》
官方微信：woshipm，干货天天推荐，欢迎订阅

如何写好你的网站分析报告

Fri, 20 Dec 2013 23:45:27 CST

从哪里入手撰写网站分析报告？报告中应该选择和使用哪些指标？如何让分析结果更有价值？这些都是在我们在撰写网站分析报告时经常遇到的问题。本篇文章分享一个创建网站分析报告的流程，通过四个步骤让分析报告变的更有价值。

一, 明确分析目的，挖掘有价值的分析需求

网站的商业目的产生分析需求，而需求的价值则直接影响分析结果的价值。因此在开始撰写一份网站分析报告前，我们先要仔细思考并充分挖掘分析需求的价值。那么，什么样的分析需求是有价值的分析需求呢？我们先来看三类最常见的客户分析需求。

第一类客户有明确的分析需求，第二类客户有一个非常模糊的需求，第三类客户无法清晰的表达自己的分析需求。对于第二类和第三类客户在进行分析前，必须要明确他们的分析目的和需求。以及这些分析需求与最终商业目标间的关系。没有明确的目的就没有分析需求的产生，也没有分析的意义。在这种情况下，你也不会知道该如何下手去进行分析，更不要谈分析结果的价值。然而，并不是所有客户提的需求都会有价值。有时候客户向我们表达的信息其实并不是他内心中真正想要的。这时需要我们对客户需求背后的含义进行分析，获得真正有价值的需求。分析需求的价值直接决定了分析结果的价值。而有价值的需求多半都会和如何为客户带来收益相关。

二，确定分析方法和报告逻辑

在明确了有价值的客户需求后，我们进入第二步，选择需要使用的分析方法和报告中的逻辑。首先是选择分析方法。选择哪种分析方法多半是由客户的需求和问题决定的。对于初级客户，多半会以递进的方式提出三个问题：表现怎么样？为什么会这样？以及如何修改并提高？这三个问题几乎可以套用到任何场景下，比如广告投放分析，网站结构分析，页面质量分析，转化分析等等等等。对于这三个问题，通常情况下我们可以分别使用对比分析，细分分析和质量分析三种方法进行解答。

对于报告的逻辑，我们给出一个通用的分析逻辑，用户—影响—行动—转化—收益。这个逻辑可以和大部分广告投放方式和网站业务模式结合。我们将分析逻辑中不同的阶段映射到用户，广告，网站等不同的部分中。并为每一部分中的目的和问题选择准确的衡量指标。

三，使用准确的指标进行度量

前面两部我们明确了分析目的，分析方法和报告的逻辑。下面开始为分析中不同的问题选择准确的指标进行衡量。指标的选择将直接影响到分析的结果。如果指标选择不当，那么分析结果也可能是错误的。选择指标的规则只有一个，就是能准确衡量所要分析的问题。这个说起来容易，但很多时候我们却经常用错，甚至有些时候为了报告的丰满，避免犯错，将很多无效的指标进行罗列。造成数据堆积。

下面是一个例子：我们使用哪个指标可以准确的衡量一个页面的质量？跳出率，退出率，浏览量，转化率这些指标都可以，但我们需要针对页面不同的功能和使用场景选择最准确的那个指标，而不是将所有相关的指标都放在上面。即使是针对同一个页面也是如此。

如何衡量页面质量？

跳出率：页面作为Landingpage时。

退出率：页面出现在任务过程中时。

浏览量：页面作为内容承载页时。

转化率：互动页面，且无其他下级页面时。

四，使用图表和业务语言展现分析结果

最后一步，也是最重要的一步，就是对前面所有的工作进行呈现，让不懂网站分析和数据的客户也能快速理解报告中的信息。这里有两部分，第一是选择合适的图表对分析结果进行展示。一图胜千言。第二是将网站分析的专业指标转换为客户可以理解的业务语言。并按业务场景为客户进行解读。我们必须承认，没有客户对指标感兴趣，大部分客户根本就不想知道Visitor和Visit的区别，他们通用也不会对你的数字感兴趣，他们需要的是通过数据和分析对业务问题的解读。因此我们不能只是简单的在分析报告中罗列数字和指标。还需要告诉客户指标在这类场景下说明的具体业务问题。

作者：王彦平 (蓝鲸)

文章及图片版权归作者所有，文章转自蓝鲸网站分析博客。

本文链接《如何写好你的网站分析报告》
官方微信：woshipm，干货天天推荐，欢迎订阅

高品质免费响应式HTML5模板下载

Fri, 24 Jan 2014 00:23:52 CST

对于网页设计人员和前端开发人员来说这两年HTML5的技术更新可以说是革命性的。不管之前你对于HTML5的意见是如何，现在你一定不会忽略这个技术带来的改变。几乎没多长的时间，这个技术就被几乎所有网站所普及更新和深入使用。这也让网站前端有了更多的可能和更好的功能。随着这个技术的普及，连普通的建站者都开始尝试使用这个新技术。而今天我们要带给大家的就是这样流行的HTML5模板，免费的并兼任各个PC平台和移动端平台。赶快去下载下来体验一下吧。让这样的神奇继续下去。

Strongly Typed

Agency

Liquid gem

Mori-Dark

Free Responsive One Page Template

Free Responsive Bootstrap Template

Colorized Free HTML5 Responsive Template

Royale Free html5 Template

Particular Free HTML5 Template

Cafe Free HTML5 Template

Digy Template

Free HTML5 Website Template Highlight Your Portfolio with

Fizz Free HTML5 responsive WordPress theme

Burn Studio Free HTML5 Responsive Template

Via

IT瘾网站推荐

网站速度终极优化

对标 VS Code，JetBrains 的下一代 IDE ：Fleet

市场规模测算方法及影响因素

1，常见的市场规模测算方法

2，不同市场类型决定了规模强弱

3，终极模式决定了实际市场占有率大小

4，市场驱动因素决定了市场增长瓶颈

5，市场规模影响因素总结

关联规则推荐算法的原理及实现

支持度(Support)

可信度(Confidence)

作用度(Lift)

微信小程序的机会在于重新理解群组与二维码

2016中国社交媒体影响报告

从100PV到1亿级PV网站架构演变

1：积累是必不可少的

2：知识结构

3：设计理念

4：基础架构

5：软件工程

6：不同类型业务系统技术架构的差异化

7:小趋势的生命力

8：LAST BUT NOT THE LEAST

协同过滤推荐算法的原理及实现

基于用户的协同过滤算法（user-based collaboratIve filtering）

1, 寻找偏好相似的用户

欧几里德距离评价

皮尔逊相关度评价

皮尔逊相关系数

2, 为相似的用户提供推荐物品

为用户C推荐商品

加权排序推荐

基于物品的协同过滤算法（item-based collaborative filtering）

1, 寻找相似的物品

欧几里德距离评价

皮尔逊相关度评价

皮尔逊相关度计算公式

2, 为用户提供基于相似物品的推荐

加权排序推荐

提升网站性能开发的10个技巧

一名网站数据分析师需要具备这9大本领

扒一扒HTTPS网站的内幕

一、什么是HTTPS网站？

二、HTTPS网站的直观了解

三、提高HTTPS网站性能和访问速度

优化网站加载速度的14个技巧

1.服务器响应时间

2.浏览器缓存

3.gzip压缩

4.异步脚本

5.内容分发网络（CDN）

6.优化JavaScript、HTML和CSS

7.置于顶部的样式表和底部的脚本

8.避免阻塞型的JavaScript和CSS

9.JavaScript的延迟解析

10.启用Keep Alive

11.图像和文件格式

12.优化代码：不使用内联CSS

13.文件分离

14.尽量减少HTTP请求

网站页面优化策略

相关文章:

使用varnish + nginx + lua搭建网站的降级系统

前言

降级目标

降级方案

存储

更新

降级

流程图

流程描述

安装部署

部署lua脚本

修改nginx配置文件

部署crond脚本

降级管理

varnish降级

nginx降级

开发一个业务逻辑复杂的系统，应该怎么样设计才能使项目的扩展性更好？

《大型网站技术架构》笔记－架构篇

第四章瞬时响应：网站的高性能架构

第五章万无一失：网站的高可用架构

第六章永无止境：网站的伸缩性架构

第七章随需应变：网站的可扩展性

第八章固若金汤：网站的安全架构

优化WordPress速度为服务器和访客减压

三，使用准确的指标进行度量

四，使用图表和业务语言展现分析结果