SD2大会上，听了钱宏武的课，发现自己作了9年的网站，竟然连带宽的单位都没搞明白，汗颜。特收集整理这部分信息如下：

典型的误解，包括之前的我

一般偷懒的时候，我们会说网络带宽是10兆，不要以为最大下载流量可以达到每秒下载10兆的文件。其实是10/8 =1.25兆。原因是因为带宽的单位和硬盘的单位是不一样的，具体如下：

容易误解的技术概念：Kb是否等于KB

经常遇到这样一个疑惑，假设我们明明申请的100Mb带宽的光纤，可是当我下载本地网站的软件时，下载速度只能达到10MB左右的速度，而电信部门却说我的网络速度非常正常。原因在哪里呢？

细心的读者肯定会发现，我上面的两个数据中，单位不同，一个是Mb，另外一个是MB。具体的差别就是在这里了。我们在日常的书写中，经常会不注意上面的细节，而这两个单位，真正的含义是不同的。Mb（全称为Mbps）这是电信部门衡量网络带宽的单位，意思是兆比特位每秒（M与K是什么含义，相信不用再解释了吧），而MB（Mbytes）是电脑文件容量的单位兆字节。由于我们在查阅资料时，忽略了这一点微小的差别，造成了对Kb与KB的误解。

带宽单位详解：在我们的记忆中，我们恐怕最熟悉的就是当初用Modem接入互联网时，接入的速度仅仅为56Kbps。在这个单位中，bps是bit Per Second的缩写，翻译成中文就是比特位每秒，也就是表示一秒钟传输多少位（bit）的意思。那么，位与字节之间，又有什么联系呢？

存储单位详解：我们最常听到的一句话就是，80G的硬盘。G就是硬盘容量的单位，也是存储的单位。存储的最小单位是字节Byte，对于存储单位，有以下几个单位，GB、MB和KB，那么这三者之间的换算关系是：1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。

Kb与KB之间的关系：我们在电脑原理中知道，电脑的最小存储单位是字节Byte，一个字节，是由八位二进制位组成的。由此，我们可以这样认为，一个字节是由8个位组成的，或者说一个字节与八个位所占的空间是相同的。因为，当我们使用100Mb带宽的网络下载时，理论上的速度应该是100除以8等于12.5MB。

点评：看了以上的介绍，我们就会明白，网络带宽的单位与下载的单位，其实是不同的。因此，我们在阅读技术资料，或者写作时，必须仔细阅读每一个细节。

带宽1M,是1024K个bit，即16个64K bit
磁盘是1M，是1024K个byte ( 1M = 1024K = 1024*1024 byte =1024*1024 * 8bit )

由于网络的传输最早基于bit处理的，所以到现在还是以bit为单位，一般以nn Kb/s，或者nnMb/s表示，比如v.90的modem的理论最大传输速度是6Kb/s，
而磁盘是并行传输的，最早是以byte传输的，所以到现在还是以byte为单位，一般以nnMB/s表示，比如ultra scsi是40MB/s的传输速度。
注意：一个是以bit , 一个是byte! 简单来说他们就是有8倍的差异。

收集整理自：

http://bbs.51cto.com/viewthread.php?tid=12915&fpage=1&highlight=%B4%F8%BF%ED

http://zhidao.baidu.com/question/5778382.html

http://www.cnitblog.com/zfly/archive/2005/12/22/5682.aspx

http://tech.sina.com.cn/c/2001-09-29/6195.html

http://www.021sh.com.cn/html/kuandaishangwang/ADSLkuandai/20070808/479.html

昨天在听云风讲的《高性能健壮系统中的内存管理》中，对于其中一些观点很有感触，虽然云风是用C来做网络游戏的，C来做游戏在内存管理上跟网站的内存管理是由很大差异的，但是有很多理论也是相通的。

缓存是大家都知道的东西，对于网站来说，一个请求过来，有可能返回用户需要的数据过程中，使用了不止一个缓存，是多个缓存。即软件架构中，多缓存并存。这时候要注意什么？

简单来说一句话。

你如果要在A缓存外再起用了一个B缓存，那么B缓存能提高的性能应该比起直接访问A，性能要提升10倍以上。

更具体说一个实际的例子，

CSDN某个具体论坛的帖子列表功能，它启用了三个缓存。从用户访问到数据库，依次是：

1、IIS输出缓存

即ASPX页面的如下设置
<%@ OutputCache Duration="30" VaryByParam="*" %>

2、每个请求进程的缓存；

            CommunityUser user = null;
            //检查用户信息是否在HttpContext中存在
            HttpContext context = HttpContext.Current;
            if (context != null)
                user = context.Items[cacheKey] as CommunityUser;

使用这个缓存是因为一个页面，我们有很多ASCX控件，再加上MasterPage页， 而这些页面对应的代码中，都会需要一些当前用户的信息，如果每次都从更底层的缓存取的话，这个消耗其实也不小。

3、进程外服务上的缓存；
为了保证缓存数据的可扩展性，非IIS进程，其他服务器也可以访问，CSDN的最底层的缓存是使用企业服务来实现的。访问这里的缓存会导致跨进程的，甚至跨服务器的访问。

上面三个缓存， 每个缓存一但命中，对他的访问，比下一级的缓存都起码有10倍以上的性能提高。就类似.net的垃圾回收中的0级对象区，1级对象区，2级对象区。 级数越低，访问性能越高，但是高级数的却是不可缺少的。

今天在SD2大会上，K2大中华区CTO彭靖灏分享了他们公司在做K2的时候，对使用WPF的心得，我觉得很有启发。整理这部分的听课笔记如下：

K2是一个很流行的工作流设计软件 http://www.k2.com/zh-CN/index.aspx 他们在最新的K2版本中使用了 WPF，WCF，WF。

他们是在做商业软件，商业软件使用WPF的一些心得，对我们作软件时候，很有醒示作用。

他们在做K2时候，界面采用WPF来实现感觉到的优点：
1、动画技术可以让软件更易用，更能引导用户使用软件。可以很明确的告诉用户，你正在干啥，下一步应该干啥。
2、Template技术,让他们的工作流软件更简单。
3、预览图技术，当一个数据变化的时候，你可以看到数据变化的预览图，很直观。
4、sliverlight2.0后，WPF和sliverlight的代码互用性很高了。

他们使用WPF碰到的问题
1、WPF的XAML都是向量图，很多美工对Expression Blend 这个工具不适应。招到能很高的设计XAML的美工很不容易 。至于让程序员来做这部分活，只能说做出来很丑。一个强大的工具，仍然需要有高手来使用。
2、跟他们已有功能的互操作，即跟Com的互操作，Interop
3、WPF是一项翻天覆地的变革，要用好它，就需要新的设计哲学，新的开发模式，这个转换门槛不低。

另外，他们的工作流每一个工作项的配置这里，没用WPF之前是使用得类似向导的方式来实现的，下一步下一步这样的方式。这种方式其实有很多弊端，他们在使用WPF后，则解决了这些问题。

他们的软件有Ajax，winform，WPF，Sliverlight的版本 ，比较下来，还是WPF的更易用。

另外听到的一个数据是：
国内在Sliverlight方面，同比其他国家，做的很好。但是WPF方面，同比其他国家，则很低。

       今天在SD2大会上，听了李建忠老师讲的《.NET框架中的几个典型设计模式》课程收益非浅，李建忠老师的课总能给人醍醐灌顶的感觉，去年的《WPF内核机制》让我们可以从根本上理解WPF的革命。今年的设计模式，也是从根本上理解设计模式产生的原因，适用的场景。

       下面是我对课程整理的一些笔记和心得，跟大家分享：

       软件的需求一直在变化。很变态，但是很多人都碰到过的情况：一直到代码编写完毕前，需求都可能在变化，需求的冻结要到编码完毕时才完成。
       为此，软件的开发方法从最初的瀑布开发， 到迭代开发再到敏捷开发。他们都是适应软件的需求、设计迟迟不能冻结定稿的产物。上面提到的开发方法，一个比一个需求、设计定稿的时间要晚。
       当然，变化不能一直不稳定，那么我们软件就永远不能发布了。

       软件的架构也受到这些影响：
       我们预计到会变的因素我们会写在配置文件ini或者XML配置文件中。
       甚至我们预计要变得东西单单配置文件都不可以搞定了，我们要把这些预计要变的东西写成解析执行的脚本语言。今天早上蔡学镛讲的《Scriptable Software与DSL的设计》，下午周爱民讲的《JavaScript + Delphi + ErLang = ？》从这里提到的变化角度来说，都是为了适应这种变化对架构的影响采用的方法。
       [魔兽世界]编写插件用的LUA语言，[文明4]用的Python语言...都是这方面的典范。

       对于设计模式，也同样的是受变化影响的。
       我们预计到一个地方是稳定的，就一个选择，我们如果还用设计模式，就是愚蠢的性能低下的做法。设计模式应该用到我们预计到这里会发生变化，为了保证复用性，我们对变化进行抽象，抽象出一个稳定的抽象。抽象出来的这个类，如果时不时都会变化一下，那简直要疯了，这个抽象的类一定要保证稳定性。这才是OO思想,设计模式的思想.
       应对变化，提高复用，这是OO设计的基本原则,也是设计模式的基本原则。
       晚绑定机制就是对这些变化的支持。.NET的晚绑定有四种方法：虚函数，委托（函数指针），反射，范型。对应的23种设计模式都是用这些来实现的。 
       MSDN的WebCast中，李建忠老师对C#设计模式有25节课的讲座，详细介绍了23种设计模式。在下面地址可以看到，下载：http://www.microsoft.com/china/msdn/events/webcasts/shared/webcast/consyscourse/CsharpOOD.aspx
       这节课对具体的设计模式讲解的时间也不多。但是你理解了变化、稳定、复用的意义，你再看设计模式就会事半功倍。

       这些年的开发经验积累下来，我发现我的设计、架构很多时候都是一个四不象，或者是一个性能，可扩展性等中庸折中的取舍方案。一定要想清楚哪些是要变化的，不会变化的，不要画蛇添足的装酷。对于要变化的要做到应对变化，提高复用来抽象，高水平的技术人员，抽象出来的东西不会三天两头就变的。