<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>漫天风 &#187; web架构</title>
	<atom:link href="http://blog.thinklet.net/mantian/tag/web%e6%9e%b6%e6%9e%84/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.thinklet.net/mantian</link>
	<description>把细小的事情做到极致</description>
	<lastBuildDate>Mon, 18 Jan 2010 16:28:45 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Sd2.0大会的web系统架构经验分享精华</title>
		<link>http://blog.thinklet.net/mantian/2008/12/30/sd20%e5%a4%a7%e4%bc%9a%e7%9a%84web%e7%b3%bb%e7%bb%9f%e6%9e%b6%e6%9e%84%e7%bb%8f%e9%aa%8c%e5%88%86%e4%ba%ab%e7%b2%be%e5%8d%8e/</link>
		<comments>http://blog.thinklet.net/mantian/2008/12/30/sd20%e5%a4%a7%e4%bc%9a%e7%9a%84web%e7%b3%bb%e7%bb%9f%e6%9e%b6%e6%9e%84%e7%bb%8f%e9%aa%8c%e5%88%86%e4%ba%ab%e7%b2%be%e5%8d%8e/#comments</comments>
		<pubDate>Mon, 29 Dec 2008 16:24:00 +0000</pubDate>
		<dc:creator>mantian</dc:creator>
				<category><![CDATA[Kills]]></category>
		<category><![CDATA[Tech]]></category>
		<category><![CDATA[web架构]]></category>
		<category><![CDATA[架构]]></category>

		<guid isPermaLink="false">http://blog.thinklet.net/mantian/?p=77</guid>
		<description><![CDATA[一，不要过设计：never  over  design
这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化 一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最 快最有效的响应。。
ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架 构。
web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的
二，web架构生命周期：web  architecture‘s life  cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你所设计的架构需要在1－10倍的增长 下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长。
google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。
三，缓存：Cache
空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓 存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快 速为好。。
缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定。
老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具
钱宏武谈架构设计视频  http://211.100.26.82/CSDN_Live/140/qhw.flv
Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?
我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理 能力低于请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存
四，核心模块一定要自己开发：DIY  your core  module
这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访 问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其 代码是非常可怕的
五，合理选择数据存储方式：reasonable data  storage
我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) [...]]]></description>
		<wfw:commentRss>http://blog.thinklet.net/mantian/2008/12/30/sd20%e5%a4%a7%e4%bc%9a%e7%9a%84web%e7%b3%bb%e7%bb%9f%e6%9e%b6%e6%9e%84%e7%bb%8f%e9%aa%8c%e5%88%86%e4%ba%ab%e7%b2%be%e5%8d%8e/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<a style="display: none;" href="http://mcinside.com/">MC Inside</a>