尹自强.DoSomething()

一步步构建大型网站架构　之前我简单向大家介绍了各个知名大型网站的架构，MySpace的五个里程碑、Flickr的架构、YouTube的架构、PlentyOfFish的架构、WikiPedia的架构。这几个都很典型，我们可以从中获取很多有关网站架构方面的知识，看了之后你会发现你原来的想法很可能是狭隘的。　　今天我们来谈谈一个网站一般是如何一步步来构建起系统架构的，虽然我们希望网站一开始就能有

最初Peter Deutsch从J2EE的企业开发中总结了7大谬误，后来，James Gosling在其基础上增加了一条，再后来，Ted Neward又在其上增加了两条，总共为“十大谬误”。这段时间正在看两本书：《Effective Enterprise Java》和《J2EE AntiPatterns》，恰好两本书都提到了“分布式计算的*大谬误”，我在这里简单引荐一下这“分布式计算十大谬误”：）

在 我的架构经验小结（二）－－ 关于三层架构 一文中，已经比较深入的介绍过三层架构方面的一些经验了，现在，我们来使用一个更小的比例尺来近距离观察我所理解的三层架构。一．三层架构图二．系统各层次职责1.UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务

在06、07年的时候，我写过一些关于三层架构方面的东西，现在看来，觉得有很多实用性的内容需要补充到里面去。我们还是先从架构图看起，然后一一解释，你就会发现相比于两年前，这个架构做了哪些变化和调整。一．三层架构图二．系统各层次职责1.UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。  Web表

年底了,又是一年过去了.今年感觉收获颇多..做web开发将近4年时光,期间没有做过任何完整的winApp,一直从事者网络开发.从最初的留言本--新闻--企业网站--论坛--聊天室--大型门户网站--大流量下载网站--网站系统优化,一路走来,不仅仅是技术上的进步,更重要的是思想上的成熟..今天之所以发这样一篇文章,是希望和大家探讨开发,探讨如何最大的节约开发时间,避免走弯路..给初入开发门径

在 我的架构经验小结（一）－－ 常用的架构模型 一文中简单介绍了我常采用的几种架构模型，本文将稍微深入地介绍其中的一种 －－ 三层架构模型。一．三层架构图二．系统各层次职责1．UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。与UI平行的Service Interface层用于将业务发布为服务

很多时候,我们都想使用(开发)USB式(热插拔)的应用,例如,开发一个WinForm应用,并且这个WinForm应用能允许开发人员定制扩展插件,又例如,我们可能维护着一个WinService管理系统,这个WinService系统管理的形形色色各种各样的服务,这些服务也是各个"插件式"的类库,例如: public interface IJob { void Run(

以前写的关于架构经验方面的文章（如上一篇实战中演化的三层架构）都是从整体的角度出发的，采用全局的视角，本文我们将拉近镜头，聚焦于日志记录这一块。随着做软件的时间越长、经验积累得越来越多，就越觉得日志记录的重要。      日志记录的主要作用可以从正反两个方面来说：（1）如果程序运行出现问题，可以通过相关日志快速定位到出问题的地方，找到问题的根源，从而快速解决问题。对于已上线的系统来说，如果

1 - Web负载均衡 1.1 - 使用商业硬件实现 最常用的F5 与citrix netscaler。比如12306前端的web好像用的就是F5 的BIGIP。如果公司资金足够的话，相对使用开源软件来说理方便。优点：维护方便，性能稳定 缺点：费用太高 1.2 - 使用开源软件 可选择使用lvs或者nginx做web应用的负载均衡。 Lvs工作在tcp

经过这几年的积累，在系统架构方面逐渐积累了一些自己的经验，到今天有必要对这些经验作个小结。在我的架构思维中，主要可以归类为三种架构模型：3/N层架构、“框架＋插件”架构、地域分布式架构。一．三种架构模型1．3/N层架构       这是经典的多层架构模型，对于稍微复杂一点或特别复杂的系统，不使用分层架构是很难想象的。下图是经典的3层架构：    如今，凡是个程序员都能侃侃而

一个组件与另一个组件之间的关系可以通过三种方式建立起来：事件、依赖倒置、Bridge。现在我们只考虑单向依赖的关系，即信息提供者和信息消费者。事件是一种松耦合的信息发布方式，事件发布者（信息提供者）不需要关心事件预定者（即信息消费者）的任何信息，但是事件预定者需要依赖事件发布者；依赖倒置则反转了这种关系，在依赖倒置的方式中，信息提供者依赖信息消费者（你也许对这句话觉得奇怪，后面的例子会说明），而信

[引言]在.NET框架下的C#语言,和其他.NET语言一样提供了很多强大的特性和机制.其中一些是全新的,而有些则是从以前的语言和平台上照搬过来的.然而,这种巧妙的结合产生了一些有趣的方法可以用来解决我们的问题.这篇文章将讲述如何利用这些奇妙的特性,用插件(plug-ins)机制建立可扩展的解决方案.后面也将提供一个简要的例子,你甚至可以用这个东西来替换那些已经在很多系统中广泛使用的独立的程序.

一、引言    1. 问题的引入    假设你设计的程序已经部署到用户的计算机上，并且能够正常运行了。但是有一天，用户打来了电话——他们要求增加新的功能。确定了用户的需求后，你竟然发现原有的软件架构已经无法胜任新增任务的需求——你需要重新设计这个应用了！但问题是，就算你又用了一个开发周期完成了用户需要的应用，却不能保证用户的需求不会再次变更。也就是说，需求蔓延的可能性依然存在。因此，这种情

插件的本质在于不修改程序主体（平台）的情况下对软件功能进行扩展与加强，当插件的接口公开后，任何公司或个人都可以制作自己的插件来解决一些操作上的不便或增加新的功能，也就是实现真正意义上的“即插即用”软件开发。平台+插件软件结构是将一个待开发的目标软件分为两部分，一部分为程序的主体或主框架，可定义为平台，另一部分为功能扩展或补充模块，可定义为插件。    在进行软件开发之前，是否采用平台+插件

我们知道，进程是操作系统用于隔离众多正在运行的应用程序的机制。在．Net之前，每一个应用程序被加载到单独的进程中，并为该进程指定私有的虚拟内存。进程不能直接访问物理内存，操作系统通过其它的处理把这些虚拟内存映射到物理内存或IO设备的某个区域，而这些物理内存之间不会有重叠，这就决定了一个进程不可能访问分配给另一个进程的内存。相应地，运行在该进程中的应用程序也不可能写入另一个应用程序的内存，这确保了任

我与很多人都在找这问题的答案。还好，我很幸运，没有进入很多人都进入的死胡同而漫长的讨论中。因为我找到了这篇文章黄天不负有心人，终于全身而退，哈哈文章说得很明白，我去掉其他设置，只使用以下代码时AppDomain.CurrentDomain.SetShadowCopyFiles();在文章发布的几天后，我在微软的MSDN上发现了这文章。似乎阐述得更为系统http://

在软件开发的领域中，插件技术一直是一项非常实用的技术。许多优秀的软件产品都提供了通过加载插件来扩展、丰富产品本身功能的能力。而像Firefox、Eclipse之类的软件，更是将插件的功能发挥到了极致。顺便做点广告的是，我们的Mussel框架便是一套基于插件扩充应用功能的框架：），在这里我们来分析一下.Net中常用的插件技术。我们先从最简单的加载方式来讲起，我们知道在Assembly类中，提

在C++中加载和卸载DLL是一件很容易的事，LoadLibrary和FreeLibrary让你能够轻易的在程序中加载DLL，然后在任何地方卸载。在C#中我们也能使用Assembly.LoadFile实现动态加载DLL，但是当你试图卸载时，你会很惊讶的发现Assembly没有提供任何卸载的方法。这是由于托管代码的自动垃圾回收机制会做这件事情，所以C#不提供释放资源的函数，一切由垃圾回收来做。

互联网系统一般会有几个特色标签：用户基数大、高并发高访问量、海量数据存储、业务更新频繁。看似复杂的系统也不是一蹴而就，任何事情都会经历一个由小到大的发展过程。今天我们就来看看一个系统是如何随着业务的扩张而不断演化的。1. 早期的系统由于业务简单，应用服务器和数据库都是在一台服务器。2.  随着用户访问量逐渐增大，系统资源慢慢成为瓶颈。此时可以考虑将应用服务器