数据交换是目前我们非常头痛的一件事情，数据仓库从数据库拉数据，不同的IDC之间要相互同步数据，一旦结构变更，没有及时的通知到一方，数据交换就出问题了，靠解日志的方式，也多少存在一些问题。
这些问题的根源都是一个问题，异构性。
Java的成功让我们知道，解决异构性的最好方案就是虚拟机，这种虚拟化机制能不能用到我们的数据交换中呢？
企业系统总线可能是一个可以借鉴的方案，我这里就YY了一个数据交换总线，Data Exchange Bus。

在DEB架构中，客户端并不直接访问数据库，而是访问DEB的访问接口。每个连上来的应用需要连接不同的数据库，怎么分辨，这里引入“数据通道”的概念，我们称一个点对点的数据连接为一个数据通道，每一个源点发出的请求，会被分发到与它连接的每个数据通道中，这个分发的任务，就由数据路由模块完成。数据路由模块还应该有一个虚拟化功能，将多台分库的数据源虚拟为一个单点数据源，暴露给数据通道控制器时就是一个点。
由于是异构系统，所以需要对各种数据库之间不同的SQL进行转译，一个方式是在数据通道里配置客户端结点的SQL版本和目标结点的SQL版本，然后SQL翻译模块进行翻译。还有一种办法就是规定客户端使用我们指定的SQL版本，例如SQL92，这样SQL翻译模块做起来就简单多了。
数据路由分发请求后，如果SQL要求排序分组等操作时怎么办？这个时候就需要做分布式排序操作，这恐怕是这里最难实现的。通过分布式计算系统提供基本的MapReduce接口，然后分布式排序引擎对每个分库选出来的数据分别排序，然后做归并，直接返回给用户，如果还存在分组，那么数据传递给分布式分组函数引擎，对排序后的数据再进行分组加工，然后返回给客户端。

其实这里面的每个模块，我们都是可以实现或者已经实现的，但是却没有有效的整合在一起，做成一套整体的数据交换平台。我这里纯属YY一下。

随机显示文章

• 2010年03月15日 -- NTP同步配置 (0)
• 2010年02月28日 -- 每周推特 2010-02-28 (0)
• 2010年07月18日 -- 每周推特 2010-07-18 (1)

作者: Fenng | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/database/craigslist_database_arch.html

Craigslist 绝对是互联网的一个传奇公司。根据以前的一则报道：

每月超过 1000 万人使用该站服务，月浏览量超过 30 亿次，(Craigslist每月新增的帖子近 10 亿条??)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18 名员工(现在可能会多一些了)。

Tim O’reilly 采访了 Craigslist 的 Eric Scheide ，于是通过这篇 Database War Stories #5: craigslist 我们能了解一下 Craigslist 的数据库架构以及数据量信息。

数据库软件使用 MySQL 。为充分发挥 MySQL 的能力，数据库都使用 64 位 Linux 服务器, 14 块 本地磁盘(72*14=1T ?), 16G 内存。

不同的服务使用不同方式的数据库集群。
论坛
1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到 17G。最大的表接近 4200 万行。
分类信息
1 主 12 从。 Slave 各有个的用途. 当前数据包括索引有 114 G , 最大表有 5600 万行(该表数据会定期归档)。 使用 myIsam。分类信息量有多大? “Craigslist每月新增的帖子近 10 亿条”，这句话似乎似乎有些夸张，Eric Scheide 说昨日就超过 330000 条数据，如果这样估计的话，每个月的新帖子信息大约在 1 亿多一些。
归档数据库
1 主 1 从. 放置所有超过 3 个月的帖子。与分类信息库结构相似但是更大， 数据有 238G， 最大表有 9600 万行。大量使用 Merge 表，便于管理。
搜索数据库
4 个 集群用了 16 台服务器。活动的帖子根据 地区/种类划分，并使用 myIsam 全文索引，每个只包含一个子集数据。该索引方案目前还能撑住，未来几年恐怕就不成了。
Authdb
1 主 1 从，很小。

目前 Craigslist 在 Alexa 上的排名是 30，上面的数据只是反映采访当时(April 28, 2006)的情况，毕竟，Craigslist 数据量还在每年 200% 的速度增长。

Craigslist 采用的数据解决方案从软硬件上来看还是低成本的。优秀的 MySQL 数据库管理员对于 Web 2.0 项目是一个关键因素。

从Fenng的博客上翻出了这篇博文，大网站也不一定要跟高端的设备，依赖优秀的架构，合理的方案才是王道。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2011年11月29日 -- 如何杀掉空闲事务 (1)

我最早是使用Visio画UML的，但是用的很不爽的是它把不通类型图的图形放一块，画一个UML图往往要翻好多次选择栏才能找到要的图形，大而全但不方便使用，并且不能生成代码，用它做了一个学校系统的类图后就放弃了。后来看了大象书（Thinking in UML），把Retional那一套东西下载下来，试用了下Rose，太臃肿，不敏捷并且收费，放弃。然后看邱郁惠的《系统分析师务实手册》，了解了StarUML这个东西，感觉很好，用了一段时间，做了几个项目的需求分析建模~后来再搜索其他的开源UML工具，发现了不少，还跨平台，开源的世界果然是强大的。发现的另一个比较好的就是argoUML，基于Java的，用了一会，感觉图比StarUML美观，但是用起来有点不是很顺手。
这里还是把starUML和argoUML这两个开源界比较好的UML工具拿出来比较一下吧。

先说starUML

StarUML是一个基于GNU GPL的开源UML建模工具。
由于starUML的目标是竞争商业UML工具像微软的Visio和IBM的Rational Rose，所以拥有一套完整的UML建模功能。

starUML的优点
»支持大多数的UML 2.0规定的图表。
»非常丰富的功能和格式选项。
»拥有从UML图表生成代码的能力。
»将现有代码反向工程到UML图表。
»支持的语言：C + +，C＃和Java。
»加载速度和执行效率比其他UML工具高。
»类似Visual Studio这样的用户界面，容易上手。
»支持图表导出成JPG/XMI等格式。

starUML的缺点
»不支持导出成SVG格式。
»图形个人感觉不是很美观。

ArgoUML

ArgoUML是用Java编写的，以BSD授权发布。
ArgoUML尚未完全开发完成，仍处于0.xx版本中。

ArgoUML的有点
»用Java编写，所以在所有有Java的平台上都可以运行。
»支持从UML图表生成代码
»目前支持的语言有C + +，C＃，Java和PHP。
»能管理待办事项列表。
»导出UML图表到XMI/JPG/ SVG/PS等格式。
»个人感觉生成的图比较美观。

ArgoUML的缺点
»不完全支持UML 2.0标准。
»没有撤消功能！这是致命的，要求用ArgoUML的开发人员永远不会犯错误。
»因为Java编写，所以运行比starUML慢的多。
»缺乏格式选项。

总得来说，我推荐使用StarUML，开源社区里我还没发现比StarUML更好的工具。如果你有更好的，请推荐给我。

随机显示文章

• 2010年05月23日 -- [转]算法的上帝——Donald E.Knuth (0)
• 2009年10月14日 -- ORM or ROM？ (0)
• 2010年07月11日 -- [转] 所谓”优秀生” (0)

有些东西必须动手做起来才能明白真正的含义，要不然只是空中楼阁。就像我高数反复看书，书上的题一看都能看懂，考试一做就Over，还是要做习题册才能理解，好吧，我穿越了。 

对于SOA，总是停在一个很浮的角度上，做了一些大东西，开始明白SOA真正的含义，对表现层、业务层、持久层的划分也有了更明白的认识，为什么要这么做。

持久层将类与数据库绑定在一起，提供一个代理，简单的说就是将数据库中的数据翻译存储到类中，这样到了业务层，类只要关心怎么处理业务流程即可，根本不需要关心类中的数据怎么从数据库获得，数据库也不用考虑怎么配合类，持久层会做好这个事。

业务层只负责处理业务流程，既不关心数据怎么来的，也不关心数据怎么显示，数据由持久层绑定好了，显示由表现层呈现。用例驱动整个业务流程。

表现层只负责把数据呈现出来，不需要关心数据的处理是怎么完成的，只需要把数据从表现层中获取出来，以合理的方式呈现出来即可，同时把交互的消息传达给业务层，业务层接受消息再处理业务。

通过这样的三层分割，系统中最重要的三个部分：数据、处理、显示，就完全的被分割开来，剥离了耦合，实现了内聚，软件工程中的高内聚、低耦合目标就达到了。数据库构架师负责持久层，程序员负责业务层，用户体验师负责表现层，层层分工。

然后SOA，实际上就是把“服务”当做“用户”来对待，一个用户想要进入一个系统，先要注册，然后系统知道了这个用户，给他分配一些资源，给他一些权限等等。

对于服务也是一样，在一个SOA系统中，想要加入一个服务，就把这个服务注册，系统为其分配权限和资源，服务利用这些权限和资源自给运行，处理自己的业务。当系统不需要这个服务的时候，就将其注销，从系统中去掉。这样服务业成为动态的了，跟业务不耦合，SOA核心系统只需要提供服务注册、服务接口、权限及资源分配即可。

但是说起来简单，想要把服务当成一个用户一样来处理，还是需要非常高的水平才能做到的，像我这种小菜鸟就不行。要通过企业服务总线ESB将所有服务连接起来，服务从ESB上获取数据，通过SOAP进行数据交互。

顺便说一句，XML很好很强大！

类似的文章

• 2009年05月1日 -- 小规模低性能低流量网站设计原则 (3)
• 2009年04月12日 -- eBay数据库构架方案分析 (0)

就目前建模软件来说，Rational Rose、PowerDesign、Visio三个是比较常用的系列了，在这里对它们做一些比较，我只用过PowerDesign、Visio和一个跟Rose很像的免费工具StarUML，下面有些内容来自网络，我也找不到源头了，就懒得标注从哪来的，就是网络来的。

ROSE是直接从UML发展而诞生的设计工具，它的出现就是为了对UML建模的支持，ROSE一开始没有对数据库端建模的支持，但是在现在的版本中已经加入数据库建模的功能。ROSE主要是在开发过程中的各种语义、模块、对象以及流程，状态等描述比较好，主要体现在能够从各个方面和角度来分析和设计，使软件的开发蓝图更清晰，内部结构更加明朗（但是它的结构仅仅对那些对掌握UML的开发人员，也就是说对客户了解系统的功能和流程等并不一定很有效），对系统的代码框架生成有很好的支持。但对数据库的开发管理和数据库端的迭代不是很好。

PowerDesigner原来是对数据库建模而发展起来的一种数据库建模工具。直到7.0版才开始对面向对象的开发的支持，后来又引入了对UML的支持。但是由于PowerDesigner侧重不一样，所以它对数据库建模的支持很好，支持了能够看到的90%左右的数据库，对UML的建模使用到的各种图的支持比较滞后。但是在最近得到加强。所以使用它来进行 UML开发的并不多，很多人都是用它来作为数据库的建模。如果使用UML分析，它的优点是生成代码时对Sybase的产品PowerBuilder的支持很好（其它UML建模工具则没有或者需要一定的插件），其他面向对象语言如C++，Java，VB,C#等支持也不错。但是它好像继承了Sybase公司的一贯传统，对中国的市场不是很看看好，所以对中文的支持总是有这样或那样的问题。

Visio原来仅仅是一种画图工具，能够用来描述各种图形（从电路图到房屋结构图），也是到VISIO2000才开始引进软件分析设计功能到代码生成的全部功能，它可以说是目前最能够用图形方式来表达各种商业图形用途的工具（对软件开发中的UML支持仅仅是其中很少的一部分）。它跟微软的 office产品的能够很好兼容。能够把图形直接复制或者内嵌到WORD的文档中。但是对于代码的生成更多是支持微软的产品如VB,VC++,MS SQL Server 等（这也是微软的传统），所以它可以说用于图形语义的描述比较方便，但是用于软件开发过程的迭代开发则有点牵强。

三种产品各有侧重点，各有优缺点，主要是看你的选择和你的开发方式和环境。
俺也来从自己的经验谈谈。
我是从目的和支持的角度来谈的。
首先谈一个目的问题。现在都讲究面向对象的分析和设计，俺也就基于oo讲起吧。版本就是Rational Suite 2002 VS PowerDesigner 9.5 VS Visio 2002。
第一，Case软件的一个基本功能就是作图。
在软件工程中，我们做的图大概有以下几种：系统框图/树图；UML图；ER图；Gantt图；任意流程图；其他任意的图表。
系统框图/树图用在比较随意、没有形成特定的文档的时候，在这个环节上面，Visio最好，rose不支持，PowerDesigner支持一点点不好用。
UML图中，三者都支持，Rose支持全系列的，而且很容易体现迭代、用例驱动等特性，相关性最好，缺点是图形质量差，逻辑检查与控制差，没有Name和 Code的区分（PowerDesigner的特性）不太适合中国人，生成文档不好也不适合自定义，也没有设计对象的字典可以快速查找。 PowerDesigner 9.5全支持，优点就是图形质量好，生成的文档容易自定义，逻辑检查与控制好，有设计对象的字典可以快速查找和快速在图形中定位，缺点就是相互之间的衔接稍微麻烦一点，对UML和RUP不熟练的人用了，体现不出来迭代和用例驱动，熟练的人用了还算比较好解决。相比较起来Visio的图形质量是最好的，但是衔接和相关性也是最差的，逻辑检查和控制勉强能做一点点。
ER图不用说了，做得最好的是PowerDesigner，Rose和Visio比较业余。
Gantt图用于项目计划，Visio可以做，其他的都不支持。但是建议你不要用Visio做，还是用Project做好啦。
任意流程图不被Rose支持，Rose只支持面向业务的活动图和面向用例的活动图，限制比较多。PowerDesigner 9.5支持，用起来还可以。Visio最好，因为它的图形质量最好，而且预定义的元素也最多。
Rose不支持其他任意的图表。PowerDesigner 9.5支持，但是预定义的元素不多。这一点Visio最好，不用多说了。

第二，好的Case软件支持Case文档与代码、Case文档与数据库之间的双向转换。
Rose文档能够与代码、数据库双向转换，是通过中间插件实现的。PowerDesigner最好，大集成，支持与代码和数据库之间的双向转换，而且不需要插件。Visio是通过VBA和宏实现的，用起来稍微麻烦，虽然这个技术不难，但是现在懂这个的好像不太多。

其次谈一个支撑和协作问题。
Rose有相对最新最完整UML支持，PowerDesigner和Visio稍微滞后一点。Rose有RUP体系的支持和一系列支持RUP的软件与 Rose协作，这一点是PowerDesigner和Visio望尘莫及的。但是PowerDesigner有一个优点就是“一站式”分析设计，不需要任何插件就可以与代码和数据库双向转换，Rose这方面需要Rational公司提供的相应的插件(数据库不要，只是客户端代码要），这个冬冬的钱真他×× 贵！这方面PowerDesigner真好：）。Visio感觉不入流。

可能还有其他方面，我也不一一罗列了，大家可以根据自己的环境取舍。我的建议是：如果你的团队对业务和英文比较熟悉但是对RUP不太熟悉，建议你使用 Rose，因为它有完整的RUP理论支撑而且相关性很好；如果你的团队对业务和英文稍逊而且系统分析员能够良好地理解RUP，那么建议你采用 PowerDesigner；当然，如果你不准备全面采用RUP开发过程，PowerDesigner是最好的；Visio都是必需的，但是只是作为 Rose或者PowerDesigner的补充。

  做图  Case文档与代码、Case文档与数据库之间的双向转换  支撑和协作 
系统框图/树图  UML图  ER图   Gantt图   任意流程图   其他任意的图表  　  　 
ROSE(Rational Suite 2002 VS)  诞生目的就是支持UML建模, 一开始没有对数据库端建模的支持. 对系统的代码框架生成有很好的支持。但对数据库的开发管理和数据库端的迭代不是很好。  不支持  Rose支持全系列的，而且很容易体现迭代、用例驱动等特性，相关性最好，缺点是图形质量差，逻辑检查与控制差，没有Name和Code的区分（PowerDesigner的特性）不太适合中国人，生成文档不好也不适合自定义，也没有设计对象的字典可以快速查找。  业余  不支持  不支持  不支持  中间插件实现的  Rose有相对最新最完整UML支持;RUP体系的支持 
PowerDesigner(PowerDesigner 9.5)  对数据库建模而发展起来的一种数据库建模工具. 直到7.0版才开始对面向对象的开发的支持，后来又引入了对UML的支持。支持了能够看到的90%左右的数据库, ，对UML的建模使用到的各种图的支持比较滞后。但是在最近得到加强。对中国的市场不是很看看好，所以对中文的支持总是有这样或那样的问题。  支持一点点不好用  PowerDesigner 9.5全支持，优点就是图形质量好，生成的文档容易自定义，逻辑检查与控制好，有设计对象的字典可以快速查找和快速在图形中定位，缺点就是相互之间的衔接稍微麻烦一点，对UML和RUP不熟练的人用了，体现不出来迭代和用例驱动，熟练的人用了还算比较好解决。  最好的  不支持  用起来还可以  支持，但是预定义的元素不多  最好,不需要插件  对最新最完整UML支持稍微滞后; 无RUP体系的支持 
VISIO(VS Visio 2002)  原来仅仅是一种画图工具. 也是到VISIO2000才开始引进软件分析设计功能到代码生成的全部功能，它可以说是目前最能够用图形方式来表达各种商业图形用途的工具（对软件开发中的UML支持仅仅是其中很少的一部分）用于软件开发过程的迭代开发则有点牵强  最好  Visio的图形质量是最好的，但是衔接和相关性也是最差的，逻辑检查和控制勉强能做一点点。  业余  Visio可以做还是用Project做好啦。  Visio最好  这一点Visio最好  Visio是通过VBA和宏实现的. Visio感觉不入流  对最新最完整UML支持稍微滞后;无RUP体系的支持 
三种产品各有侧重点，各有优缺点，主要是看你的选择和你的开发方式和环境。
如果你的团队对业务和英文比较熟悉但是对RUP不太熟悉，建议你使用Rose，因为它有完整的RUP理论支撑而且相关性很好；
如果你的团队对业务和英文稍逊而且系统分析员能够良好地理解RUP，那么建议你采用PowerDesigner；
如果你不准备全面采用RUP开发过程，PowerDesigner是最好的；Visio都是必需的，但是只是作为Rose或者PowerDesigner的补充。
 
 

 Rational Rose、PowerDesign、visio的比较收藏
出身  做图  Case文档与代码、Case文档与数据库之间的双向转换  支撑和协作 
系统框图/树图  UML图  ER图   Gantt图   任意流程图   其他任意的图表  　  　 
ROSE(Rational Suite 2002 VS)  诞生目的就是支持UML建模, 一开始没有对数据库端建模的支持. 对系统的代码框架生成有很好的支持。但对数据库的开发管理和数据库端的迭代不是很好。  不支持  Rose支持全系列的，而且很容易体现迭代、用例驱动等特性，相关性最好，缺点是图形质量差，逻辑检查与控制差，没有Name和Code的区分（PowerDesigner的特性）不太适合中国人，生成文档不好也不适合自定义，也没有设计对象的字典可以快速查找。  业余  不支持  不支持  不支持  中间插件实现的  Rose有相对最新最完整UML支持;RUP体系的支持 
PowerDesigner(PowerDesigner 9.5)  对数据库建模而发展起来的一种数据库建模工具. 直到7.0版才开始对面向对象的开发的支持，后来又引入了对UML的支持。支持了能够看到的90%左右的数据库, ，对UML的建模使用到的各种图的支持比较滞后。但是在最近得到加强。对中国的市场不是很看看好，所以对中文的支持总是有这样或那样的问题。  支持一点点不好用  PowerDesigner 9.5全支持，优点就是图形质量好，生成的文档容易自定义，逻辑检查与控制好，有设计对象的字典可以快速查找和快速在图形中定位，缺点就是相互之间的衔接稍微麻烦一点，对UML和RUP不熟练的人用了，体现不出来迭代和用例驱动，熟练的人用了还算比较好解决。  最好的  不支持  用起来还可以  支持，但是预定义的元素不多  最好,不需要插件  对最新最完整UML支持稍微滞后; 无RUP体系的支持 
VISIO(VS Visio 2002)  原来仅仅是一种画图工具. 也是到VISIO2000才开始引进软件分析设计功能到代码生成的全部功能，它可以说是目前最能够用图形方式来表达各种商业图形用途的工具（对软件开发中的UML支持仅仅是其中很少的一部分）用于软件开发过程的迭代开发则有点牵强  最好  Visio的图形质量是最好的，但是衔接和相关性也是最差的，逻辑检查和控制勉强能做一点点。  业余  Visio可以做还是用Project做好啦。  Visio最好  这一点Visio最好  Visio是通过VBA和宏实现的. Visio感觉不入流  对最新最完整UML支持稍微滞后;无RUP体系的支持 
三种产品各有侧重点，各有优缺点，主要是看你的选择和你的开发方式和环境。
如果你的团队对业务和英文比较熟悉但是对RUP不太熟悉，建议你使用Rose，因为它有完整的RUP理论支撑而且相关性很好；
如果你的团队对业务和英文稍逊而且系统分析员能够良好地理解RUP，那么建议你采用PowerDesigner；
如果你不准备全面采用RUP开发过程，PowerDesigner是最好的；Visio都是必需的，但是只是作为Rose或者PowerDesigner的补充。 

各种工具的比较：
 

目前最新版：

IBM Retional Rose V7.0 

Sysbase PowerDesigner V15

Micorsoft Office Visio 2007

类似的文章

• 2009年03月14日 -- UML之父——Ivar Jacobson介紹SMART方法 (0)

荣耀属于Fenng牛

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术
动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要
很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要
因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎
不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能
这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的
这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展–>发现问题–>反馈–>解决问题(执行力)–> 改进->进化到下一阶段–新问题出现(循环)有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

–EOF–

好的业务模式(产品) + 很好的技术 = 大赚钱
好的业务模式(产品) + 能用的技术 = 也赚钱
差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
差的业务模式(产品) + 差的技术 = 自己浪费资源

类似的文章

• 2009年08月20日 -- SOA构架与三层结构 (2)
• 2009年04月12日 -- eBay数据库构架方案分析 (0)

UML之父——Ivar Jacobson介紹SMART方法

PPT下载
CSDN下载
本站下载

类似的文章

• 2009年03月18日 -- 明智軟件開發的共鳴與思考 (0)
• 2009年07月11日 -- Rational Rose、PowerDesign、Visio的一些比较 (0)
• 2009年06月1日 -- 关于需求的文档区别 (0)