回顾2008，我们做了很多事情。
3月 Yo2 审核过滤系统开发完成
6月 Yo2 CDN 系统成功上线运营
今年的重点项目是 CDN 系统的建设，能更好的缓解因拔线而造成无法访问的影响，并且博客访问速度得到很大的提高。
目前 Yo2 正在使用的 WordPress 版本还是 2.3.3，虽然有点老，但我们认为这个版本是非常稳定的，经过我们1年时间的不断优化与修正，博客数据的处理效率非常高，博客系统的BUG也很少。
而新版的 WordPress 在数据库上与 2.3.3 相差很少，但功能并没有增加多少，主要是后台的操作界面加强与美化，所以我们还未有升级到新版的想法。为了保证稳定的服务，希望广大用户可以体谅。当然我们也在密切关注新版 WordPress 的发展，会认真考虑在一个适当的时间升级到新版程序。
希望大家能一如既往的支持 Yo2，一起走过更长的道路 谢谢！
刚在 Yo2Mass 看到《从豆瓣宕机看IDC单点问题》 一文，自己是深有感触的。刚好今天我们电信的服务器也出了故障，断网4个多小时。从Yo2开张到现在，我们都不知道换多少个IDC。就是没能找到一个很稳定的（当然太贵的我们是租不起）。
豆瓣所在的机房是北京实力比较厚的IDC之一，我们也有台服务器在他们的天津机房。一直用着，感觉还可以。虽然偶尔会出现某些地区访问速度慢的问题，但因它在教育网的访问速度挺好的，所以一直在用。万没想到，我一直说算稳定的IDC也会出现如此长时间的断网故障《2008.10.31 豆瓣访问故障》。刚查了下豆瓣的服务器信息，发现他们已经把服务器出口切换到其他机房。他们的数据估计都在原来的机房，新的出口应该是直接 Proxy 代理，访问速度并不理想。
做网站的技术都知道什么是单点故障和它所造成的影响。传统的解决方案是使用LVS把访问请求分发到多个服务器，如果某台服务器故障，它可自动分发到另外的服务器，能很好的解决单点故障问题。但你再看远一点，在前端的LVS不是一个非常大的单点吗？万一它出现故障，那么它后面的N台服务器都无用武之地！大家都在努力解决单点故障的问题，却未意识到自己在制造一个更大的单点故障风险。
Yo2也有单点故障的情况发生，但它的影响不至于扩散到全局，因为我们使用了CDN技术。我们目前在几个网络、分几个机房，架设了访问加速节点。CDN利用域名智能解析技术把用户的访问指向到不同的服务器，部分用户间是相对独立的，如网通用户与电信用户，甚至可以精确到某个省份和地区。比如今天电信服务器出现故障，就不会影响到网通和教育网用户的访问，并且我们及时在CDN上把电信的访问切换到其他的机房，能快速恢复服务（当然域名解析耗时比较长，大概1个小时左右）
但CDN也不是灵丹妙药，不是什么网站应用都能使用CDN。比如一些动态页面就无法使用CDN系统的缓存功能，只能直接Proxy。如果网站应用是以动态内容为主，那么建立CDN系统也就等于把成本扩大1倍。因为它只能直接Proxy到后台服务器，CDN跑多高的带宽，后台的服务器都会跑这么高；后台服务器需要处理的数据量跟没使用CDN是一样的，并不会减少。除非把内容缓存在CDN的加速节点上，这样不仅能节约服务器的成本，并且访问速度会快很多。但目前商业运营的服务商，还未能提供这个完美的解决方案。
Yo2是在成长过程中就意识到单点故障问题的严重性，我们必须把影响降低到最低。因没找到能提供解决方案的服务商和需要考虑运营成本，所以我们选择了自主根据Yo2作针对性的开发。目前我们是拥有一个算完美的解决方案。当然目前的加速节点还很少，单点故障的影响还是比较大。只是从以前的影响100%降低到40%左右，随着Yo2的成长，我们会继续增加更多的访问节点，单点故障的影响将会降到更低 
为防止有人恶意的用于 SEO 操作，所以我们对 feed 地址的数量作出了限制：免费用户3个，绑定域名用户10个。我们也会监测用户的使用情况，发现恶意使用者，将会被关闭博客服务处理。我们提供用户需要的工具，如菜刀，但我们必须阻止使用菜刀杀人的情况发生。
我们充分考虑到文章的版权问题，所以插件不会提供文章全文转载，只能显示几百字以内的摘要。对于文章上的图片，则以小的缩略图显示。或者有人会说文章罢了，不值几个钱。但我却认为低价值不能代表可以随意转载。人家本来就只值那么一点点，你还要落井下石啊？
mass 插件本身意义不是丰富自己博客的内容，而是给大家提供一个互相展示的场所，给访客多一些内容导航。这就相当于更高层次的友情链接。好比我自个的博客，内容以博客界、互联网技术为主，所以我的聚合 feed 都与这些有关，访客如果有更多的内容需求，可以通过 mass 插件导航到其他博客上
结语：我认为 mass 插件是有益于博客发展的，希望大家能更好的使用它。
完成 ！ 希望这些技巧能让你更好的使用 Yo2 博客服务
CDN是一个经策略性部署的整体系统，能够帮助用户解决分布式存储、负载均衡、网络请求的重定向和内容管理等问题。 其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容， 解决 Internet 网络拥塞状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均而产生的用户访问网站 响应速度慢的根本原因。
目前国内主要的 CDN服务商有北京蓝汛、网宿科技、北京快网、浙江联存、CDN联盟等数家，服务商之间的技术实力还有一定差距，产品线比较长的有北京蓝汛和网宿等几家，全国分布节点数量多，可提供多种加速服务，但相对价格也比较昂贵。一般小型 CDN 服务商较有价格优势，但产品线比较短，不能提供一些比较高端的应用，基本是做静态文件加速服务。
普通的静态文件加速服务技术门槛低，只需要配备智能DNS解析服务，使用 squid (内容缓存系统) 在各地区部署一定数量的服务器节点，即可投入服务。所以现在有越来越多的 IDC 服务商开始建立自己的 CDN 网络，但因为还在起步阶段，带宽总容量低，所部署的节点数量比较少，主要分布在各大城市，并且节点的网络质量参次不齐。
更多的服务商加入到 CDN 行列，已经把带宽资费拉到普通多线带宽的水平。现在越来越多的网站开始使用 CDN 服务，给网站的静态内容(如：图片)进行加速，而动态内容依然使用自有多线服务器提供访问服务。而有部分大型网站则开始建立自己的 CDN 网络 (如：6.cn) 自主 CDN 网络的可控性高，可以根据自己的各项服务需求进行细节调整，但维护成本则相对购买第三方的 CDN 服务要高得多。
我们需要根据自身网站的实际需求、技术能力和资金，综合分析应该怎样使用 CDN 服务进行访问加速。因为 CDN 服务商只能提供一定域名数量的加速服务，如果你的网站需要给大量的域名访问进行加速，则需要自行建立 CDN 网络了。(如果您需要进一步了解 CDN 服务，我是能够提供一些建议的
---------------------------------------------------------
Yo2 是博客服务商，需要给大量的博客进行访问加速，所以选择自行建立 CDN 网络。并且在服务器节点的页面缓存技术方面，相对普通的 CDN 服务商有一定的优势，我们的缓存系统已支持动态页面的加速服务，除了少量要求即时动态处理的数据以外，其他的博客文章页面、模板、图片等内容均已使用缓存加速。
虽然我们的 CDN 网络还是起步阶段，所部署的服务器节点有限，但我们选择的机房带宽要求都是很高的，同省区的访问速度 < 20Ms，跨省区访问的速度在30~50Ms之间。在 Yo2 的成长过程中，我们将进一步完善自己的 CDN 网络，以提供更快的博客访问速度
Httperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance. The focus of httperf is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro- and macro-level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility to new workload generators and performance measurements.
Httperf 是一个高效的 http 压力测试工具，使用它可以模拟出超过1千的并发访问，能充分测试出 web server 的性能。而之前使用的 siege 测试工具则未能突破 500 个并发测试（如果您知道如何可以实现，请告诉我）
使用 httperf 应该能了解到自己编写 yo2cache 软件性能极限如何了
以下是 gzip 格式访问的测试数据（因缓存文件以 gzip 格式保存，所以性能是最高的）
oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: gzip"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: gzip' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1Total: connections 2000 requests 2000 replies 2000 test-duration 1.304 s
Connection rate: 1533.7 conn/s (0.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.6 avg 0.7 max 6.3 median 0.5 stddev 0.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000Request rate: 1533.7 req/s (0.7 ms/req)
Request size [B]: 81.0Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 0.0
Reply size [B]: header 302.0 content 10482.0 footer 0.0 (total 10784.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0CPU time [s]: user 0.29 system 1.01 (user 22.4% system 77.6% total 100.0%)
Net I/O: 16273.4 KB/s (133.3*10^6 bps)Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
以下是 deflate (2级压缩率)格式访问的统计数据（需要从 gzip 解压，再压缩为 deflate 的数据处理）
oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: deflate"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: deflate' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1Total: connections 2000 requests 2000 replies 2000 test-duration 4.113 s
Connection rate: 486.2 conn/s (2.1 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 2.0 avg 2.1 max 11.8 median 2.5 stddev 0.3
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000Request rate: 486.2 req/s (2.1 ms/req)
Request size [B]: 84.0Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 1.5
Reply size [B]: header 305.0 content 11014.0 footer 0.0 (total 11319.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0CPU time [s]: user 0.91 system 3.20 (user 22.2% system 77.8% total 100.0%)
Net I/O: 5414.3 KB/s (44.4*10^6 bps)Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
以下是 deflate (4级压缩率)格式访问的统计数据
oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: deflate"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: deflate' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1Total: connections 2000 requests 2000 replies 2000 test-duration 5.329 s
Connection rate: 375.3 conn/s (2.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 2.6 avg 2.7 max 32.8 median 2.5 stddev 0.7
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000Request rate: 375.3 req/s (2.7 ms/req)
Request size [B]: 84.0Reply rate [replies/s]: min 374.8 avg 374.8 max 374.8 stddev 0.0 (1 samples)
Reply time [ms]: response 0.6 transfer 2.0
Reply size [B]: header 305.0 content 10457.0 footer 0.0 (total 10762.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0CPU time [s]: user 1.29 system 4.01 (user 24.2% system 75.2% total 99.4%)
Net I/O: 3975.4 KB/s (32.6*10^6 bps)Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
以下是文本格式访问的统计数据
oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: normal"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: normal' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1Total: connections 2000 requests 2000 replies 2000 test-duration 2.349 s
Connection rate: 851.3 conn/s (1.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 1.1 avg 1.2 max 5.8 median 1.5 stddev 0.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000Request rate: 851.3 req/s (1.2 ms/req)
Request size [B]: 83.0Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 0.6
Reply size [B]: header 278.0 content 42562.0 footer 0.0 (total 42840.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0CPU time [s]: user 0.62 system 1.73 (user 26.2% system 73.7% total 99.9%)
Net I/O: 35683.0 KB/s (292.3*10^6 bps)Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
从以上数据可以看到 yo2cache 性能挺好的，最高能达到每秒 1500 个并发处理。性能瓶颈是出现在缓存数据的解压与压缩处理上，如果缓存空间足够大的话，可以考虑保存多种格式的缓存数据，就能解决这个瓶颈问题。
而在 deflate 数据压缩方面，因为2级压缩率与4级压缩率所产生的数据量差距不大，但并发性能有一定差距，可以考虑使用 2 级压缩率。
也许你会发现我们Yo2实行的并不是传统的简单关键字替换操作，我们是为了尽量减少对博客文章的影响，才专门为此开发的功能，只对小部分重点，且日常少用到关键字才做 ** 的替换操作，而其他只是加入干扰码处理。干扰码处理，基本不影响正常的文章阅读。
汉字的自由组合程度很高，这个我们是知道的。也是因此我们才采取了分级处理的方案，并且对于部分关键字不会列入到审核统计数据中，目的就是为了尽量减少正常文章被程序误判的可能性。我们每天都在根据文章审核列表中出现的关键字，对系统的词汇表进行优化，尽量减少对博客正常浏览的影响。
这些过滤程序对 Feed 无效，其他 Feed 服务商读取到的数据都是原汁原味的，当然可能其他的 Feed 服务也会有关键字替换的可能。
WJC 通常是程序自动从互联网上截取页面内容，并寻找其中包含的关键字，如果包含有一定的数量就会触发，递交到WJ手上，WJ并通知机oo房要求删oo除此文章。如果一个IP频密出现这些文章，WJ就很可能要求机oo房停oo止该服务了。
我们为此就更换过三次机房和IP，1月的事情还历历在目。尤其这段时间，WJ的处理更加严格。而我们也只好做出这样的对策，希望用户们可以体谅，谢谢！
(注: 文中 oo 部分为我自己个人的屏蔽操作，与Yo2系统无关)
自家的博客当然得原创，干嘛要转载人家的来充门面呢。Blog 统计
共 99 篇日志 ，559 条评论，6 个分类，66 个标签。
自从搬家到 Yo2 后，博客的评论数量也渐渐多起来。一是我跟大家交流的机会多了，二是Yo2创始人的缘故吧。
自个的英文名是 oneoo 也是 100 的意思，所以我就借此机会总结一下吧。
在过去的一年多时间里，我主要负责 Yo2 WordPress 开发到 Yo2 主站的功能开发，和兼任客服工作。跟网友们度过了一年多的时间，期间有不少问题和挫折，在网友们的支持下，我们能够克服重重困难和障碍，一步一步的，慢慢的走到今天
06年第一阶段，刚开始建立起来的 Yo2 还只限于 WordPress 博客服务，WordPress 版本是2.0，并且模板和插件的数量都是相当的少，还不支持模板上传和编辑的功能。Yo2 的服务器也只有上海电信机房一台。
07年第二阶段，就增加了相册和做事的功能，WordPress 版本是2.1。主站有好几个出于 blogtd.org(乖乖) 非常可爱的广告图片。WordPress 部分就增加了比较多的模板和插件，并且支持模板上传和编辑功能。经过半年多的测试，终于在10月就开始对绑定域名的服务进行收费，这个可以说是我们的里程碑之一。服务器方面呢则在昂贵的电信通机房租用有一台服务器，在比较贵的世纪互联机房租用有两台服务器，和杭州的 cdn 加速服务器。并且在广东建立了自己的数据中心，博客页面的处理工作都是由数据中心负责的。因为用户的不断膨胀，旧的系统因先天性的架构缺陷，导致博客服务质量比较差，经常会出现504页面处理超时的故障。
08年第三阶段，为优化页面处理的效率，对整站系统进行了巨大的升级，WordPress 版本是2.3。新版的服务架构可以说达到了无限制用户量。并且在博客页面的访问上，进行了大量的细致优化，细小到博客的一个css文件和图片。可以说我们 Yo2 提供的WordPress博客服务是地球上速度最快的！（当然国外访问因为跨国线路出口的问题，依然很慢）服务器方面，除了电信通机房的服务器停止使用外，其他机房的服务器都保留，并且在广东的双线机房租用有一台服务器。算起来我们 Yo2 现在已经拥有6台服务器了。
08年展望，这是个奥运年，今年充满了希望，但同样也有危机。因为奥运开博客的网友应该会有一定的增长，而也是因为奥运可能在内容管理上会出现不明朗的问题。为迎接将要来临的奥运，Yo2 会努力解决服务器线路的稳定问题，保持我们的博客服务良好运作。而同时需要对主站的系统来一次大的升级改造，现在主站的功能都比较简单，不能构建起很好网络社区。
在过去的一年 Yo2 可以说是没有任何的网络推广工作，而在今年我们的首要任务就是把我们的服务推广到全国，把 Yo2 品牌建立起来。
经过这一年多服务，我们得到了很多宝贵的经验。现在的博客服务已经由我们优化到了极致，整个系统架构已经非常成熟，只要我们的服务器线路不出什么问题，整套系统绝对能够非常稳定的为大家提供服务！
我非常感谢一直支持我们的网友，没有大家的支持，Yo2 是很难走到今天的。谢谢大家 我们不会辜负大家的期望，竭尽全力为大家提供稳定的、功能强大、自定义能力高的 WordPress 博客服务。
一个网站要让在这三张网下访问都快的话，它就需要租用多线线路，一下子就把电信、网通、教育网的线路都接到服务器上（多线服务器，或许是中国独有的产物吧，当然外国的情况可能有比我们更糟的，我还不知道），自然大家访问的速度就快了。但租用多线线路的费用比单线的贵很多。网站用户多的话，可以在每个线路上都摆放服务器，然后使用智能DNS服务，让访问者可以自动解析到相同线路的服务器上进行访问。Yo2 就同时采用了这两个方式给用户提供服务。
除了网络不互通外，还有其他很多麻烦事。比如内容审查，地区上的电信路由可能会因某些原因，而把你的IP封了，当然你可能不知道它为什么这样做。你联系它也是基本无法解决问题 _-!! 这就造成网站出现地区性的无法访问。
Yo2 在过去的一年时间就经历过，机房被攻击、因敏感内容拔服务器网线、IP被个别地区路由封闭等等突发事件。因我们投入的服务器资源还是比较多的，都分布在不同地区的机房，能够很快就切换到其他服务器上，但怎么快也是需要设置生效时间哦 这还得用户体谅一下。
就在这个月11号左右，我们上海的服务器就出现地区性路由关闭连接的情况，因我们此前已经留有河南的服务器作为备用，在13号确定此服务器所在的网络无法及时修复时，我们就切换到河南的服务器上提供服务了。
也就是说我们要多租用多一倍左右的服务器，以应付这类突发事件。当然随着网站的成长，所拥有的服务器资源会更多，也就可以更快的做出调整，服务器成本也相应降低一些。
我们的服务器一直都是正常运行，系统软件都搭配得很好。从未出现过服务器死机这类问题。但服务器的网络线路不在我们的掌控下，so～ charles 就经常为此而烦恼。把服务器调来调去的 _-!!还真辛苦他了
oneoo 在 尊重是双方的互动 上的评论clovergao's blog 在 尊重是双方的互动 上的评论天天博客 在 尊重是双方的互动 上的评论永远有多远 在 尊重是双方的互动 上的评论人体艺术图片 在 .cn域名“注册”google app 上的评论nestlake 在 .cn域名“注册”google app 上的评论oneoo 在 Twitter 上的评论zstyle 在 尊重是双方的互动 上的评论sam 在 Twitter 上的评论fitenx 在 BSP 与独立博客的对比 上的评论
