分享

通信系统设计是一个相对比较复杂的工程问题。相关的工程设计和实现人员，通常是网络背景的比较多，或者只有网络背景。

这是不够的。

通信系统，特别是高端通信系统，已经演变成一个大型的分布式计算系统。

分布式计算与网络计算，从理论上而言，是需要不同的知识背景和技能的。

本文试图探讨一些通信系统中的分布式计算的相关理论基础，起到抛豆腐引美女蛇的作用，从而希望对相关读者们有所帮助。

相关的内容组织如下

0。分布式系统简介

1。 通信系统体系结构概述

2。 基于消息的通信系统

3。 通信系统中的时序逻辑

4。 微观分布式并行计算简介

5。 通信系统的分布式调度

6。 分布式系统设计与调试方法

7。 TBD

8。 结束语

［欢迎同学们发表看法，从而我可以把相关章节组织好。］

分享

分享

有诗云：人之老，其言真；人之去；其行善。

系统软件设计是软件系统的皇冠中的宝石。绚烂美丽。令无数男女痴迷。

在系统软件，特别是通信系统软件的设计上，有没有一些可以提炼的方法论？

今身处幽州（北平），心在大宋。聊聊数语。谈谈我对大宋年轻一代的系统软件工程师的期望。

1。 The Thinner vs. The Thicker
年轻人都以为有些事情需要粗，有些事情需要厚。其实，合适就好。。。

系统软件一定要越细越好；越薄越好。

我在华为做speech的时候，也提到过：能把系统软件做薄，才是一代高手。

最可怕的就是为了做而做。

最高境界是：能不做就不做。

每一行代码，都会成为历史（Legacy）；每一份恋情都会成为过去。

工程的事情，就是要简简单单。

内在算法的复杂不代表外在的臃肿。

一个女人，要的是清澈美丽；而非妖娆迷人。

智慧者应该做的是cut；而非单纯的add。

2。 Re－Create vs Re－Search

ReCreate是工程之大忌。任何一个问题，必须首先养成良好的科研习惯：
－－是否陈首席已经解答过类似的问题。
－－是否友商（敌商）解决过类似的问题。
－－是否Open Source领域已经解决过类似的问题。
－－是否Google和Baidu已经解答过类似的问题。

如果有，拿来主义基础上的改良主义就是最好的。重复发明已经发明了的算法，模型是兵家之大忌。
学术界的Research的意思是：伊人已经在阑珊处；要的是反复寻找，找到你的爱人。
工业界的Recreate是：瞎折腾。利己但害公司。

3。 Qualitative vs Quantitative
大宋文化博大精深，但似乎更多的是在形而上，在君臣父子，为相为官上做文章。

自然科学在中国的错失是我们大宋百年之痛之根本之一

定性和定量分析的有机结合，是成为一个优秀的系统软件架构师的基本素养。

只有定性分析的胶片，是研发之大忌。

一定要养成能case study，算法分析的良好工作习惯。

要的是数据说话；不要的是框架忽悠。
4。 Feature Parity vs Disruptive Innovation

大宋某公司特别喜欢玩一个词汇：技术断裂点。还有一些：领先世界产品的优势点。

这基本上是胡扯。或者从大样本的角度，是胡扯。是文革作风。是党八股。

作为一个工程设计人员，不要羞于Feature Parity。学习和模仿美军，伪军的东西，是提高自己的最佳方法。不要上来就是什么断裂点。

邓公稼先都说：我们这几代人要做的是使得国家不要差距加大。

我们这2，3代人能做的是：Follow。领先基本上不存在现实。

这其中，最大的问题不是工程，而是教育的落后。教育的落后使得我们不存在成为一个高科技大国的基础yet。

所以，不要有强迫症，没事玩断裂点。跟上并略微有改良就好。

这就好比，明明不是AV明星，非要玩AV明星的动作。。。受罪。

请把创新留给90后和00后吧。。。

5。 Semi－Optimal Optimization vs Full－Optimal Optimization

工程上，没有最好的算法；只有最好的折衷。
爱情上，没有最好的恋人；只有心中的情人。

不要过分追求最佳算法。要能把握算法带来的时间和空间上代价的折衷。更为重要的是，在工程上，如果出了问题，调试，调优和定位带来的代价。否则，能解决问题的算法，就是好算法。

6。 Application vs System

系统是为应用服务的。

男人的钱是为你爱的女人而挣的。

做系统不能玩意淫。不能为做系统而做系统。

一切要为人民服务，为应用服务。

只有人民的需要，才是系统软件的需要。

“爱系统软件就是爱人民。是等价的”。这是愚弄人民。

不能本末倒置。

应用和系统是相通的。你能写汇编，也能写object－C。都是逻辑的表达而已。

7。 Proprietary vs Open Source

拿来主义，没人反对。也需要提倡。但如何贡献和反馈给社区，这是每一个大宋系统软件工程师应该反思的。知识共享不仅仅是一个方法论，也应该是一种精神家园。

天天信息安全，什么都藏着，躲着，非一代天骄之所为。

成大事者，必有大胸怀。公司也好；个人也罢。

分享

分享

本文摘自即将于2011年4月份出版的《大话存储2》的第15章-集群存储系统，著作权所有，转载请注明出处与作者

IBM自从亮相了XIV之后，EMC接着出了V-Max，接着HDS也推出了VSP。这三者都宣称自己是Scale-Out架构，在业界也引发了一些讨论，有人认为只有XIV才是真正的Scale-Out，而V-Max与VSP则不算Scale-Out。对于这个问题，我是这么看的。

大家知道服务器多CPU架构变迁过程，一开始是单CPU，后来发展到双CPU或者多CPU的SMP架构，也就是多CPU共享相同的内存、总线、操作系统等资源，每个CPU访问全局内存任何地址耗费的时间都是相等的。还有一类AMP架构，即不同CPU做的事情是不同的。但是由于共享访问冲突，SMP架构扩展性-效率曲线已经达到瓶颈。为了消进一步提高CPU数量的同时保证效率，NUMA架构出现了，也就是将多个SMP进行松一点的耦合，多个SMP之间通过CrossBar Switch高速交换矩阵互联，每个SMP都有各自自己的内存，一个SMP内部的CPU访问自己的内存时与之前没什么两样，但是要访问其他SMP处的内存，就需要走交换矩阵，导致延迟增加，所以，NUMA通过牺牲了内存访问的时延来达到更高的扩展性，比如可以将数百个CPU组成NUMA架构。SMP和NUMA架构对于软件程序方面的影响不大，同一台主机内都使用单一操作系统。但是由于NUMA访问远端内存时的时延问题，导致NUMA架构下的效率也不能随着CPU数量的增加而线性增长，只是比SMP要好罢了。此时，MPP架构就出现了。MPP可以说已经与CPU已经关系不大了，MPP说白了就是将多台独立的主机使用外部网络来组成一个集群，显然MPP架构下，每个节点都有各自的CPU、内存、IO总线和操作系统，属于最送的耦合，而且运行在MPP集群中的软件程序的架构也需要相应改变，变为大范围并行化，并尽量避免节点之间的消息传递。由于软件程序发生了变化，那么MPP的效率随节点数量的增长就可以呈线性关系了。其实，如果在NUMA架构下，软件也可以避免尽量少读取远端内存的话，那么NUMA效率也会线性增长，但是NUMA架构下的操作系统仍然是同一个，内存仍然是全局均匀的，而程序架构又尽量保持不变，那么就不可避免的时不时访问远端内存了。MPP相当于把内存强制分开，把操 作系统强制分开，把程序架构也强制改变从而保持海量计算下的效率线性增长。

那么再说回到存储系统。与服务器CPU架构演进相同，可以把存储系统的控制器类比为CPU，而后端磁盘柜类比为一条条的内存。一开始的单控，后来的双控互备份（传统双控存储），一直到双控并行处理（目前只有HDS的AMS2000存储系统为双控并行架构），到这个阶段就类似于AMP（双控互备）和SMP（双控并行）架构，后来则有多控并行对称处理架构，Oracle的RAC集群也可以视作一种多点SMP，各种共享底层存储的集群文件系统及基于这种文件系统所构建的存储系统也属于多点对称SMP。同属多点对称SMP架构的还有华为赛门铁克的VIS以及S8100和N8000存储系统。

同样，由SMP到NUMA的过度也出现在了存储系统中，比如EMC的V-Max，相当于多个SMP（一对控制器组成一个Director等价于一个SMP矩阵）利用高速交换矩阵（RapidIO）来共享访问每个SMP上掌管的内存。

由NUMA到MPP的过度一样也出现在存储系统中，IBM的XIV就属于松耦合MPP架构，多个节点之间彻底松耦合，各自都有各自的CPU/内存/总线/磁盘/IO接口，使用外部以太网交换机，使用TCPIP协议互相通信。而HDS的VSP则更像是一个紧耦合的MPP，MPP对软件架构变化很大，所以传统存储厂商很难将之前的架构演变到MPP上来。另外一种属于MPP架构的存储系统就是各种分布式文件系统（注意，并非共享存储的集群文件系统）。

至于谁才是真正的Scale-Out，这个是个无定论的问题了。SMP/NUMA/MPP其实都算Scale-Out，只不过程度和形态都不同罢了。有人说MPP才是真正的Scale-Out，可能是基于MPP流行的原因。但是不能一概而论。MPP架构的存储，例如XIV，由于特定场景下，由于单路IO就可能导致整个MPP集群中的磁盘资源全部牵动（每磁盘同一时刻只能执行一个IO），在多路大块连续IO并发的情况下，反而效率很差（比如多流大块连续地址IO）；而某些特定场景下，多路IO之间牵制很少，则表现出线性增长的性能（比如小块高随机IO）。这也可以类比为将一个程序并行分解成多个执行颗粒（类比为高随机IO），颗粒间的关联性越少，则并行执行的效率越高，一个道理，所以MPP自身为Share-Nothing架构，那么运行在它上面的程序颗粒之间最好也Share-Nothing。SMP、NUMA和MPP各有各的好处，也各有各的应用场景。比如SMP适用于扩展性要求不太高而又不想对程序改变太大的场景，而MPP则使用海量数据下的高扩展性需求场景，需要对程序有较大改变才能获得良好性能。同样对于存储也是这样，比如一旦决定用MPP架构的存储，那么就需要面对多流大块连续IO场景下性能不佳以及效率-扩展曲线的线性不佳这2个事实。或者你去修改上层应用，将大块连续IO改为高随机IO，而这显然荒唐。并且为了适应存储去修改应用，这一般是不可能被接受的。而MPP架构却被广泛用于互联网运营商的底层Key-Value分布式数据库，其高随机小块读访问场景下能获得巨量的性能以及线性的效率-扩展曲线。

本文摘自即将于2011年4月份出版的《大话存储2》的第15章-集群存储系统，著作权所有，转载请注明出处与作者

分享

分享

         近来又碰到多个初学者面对这几个词时候显得概念混乱，不知所措。qq上经常有留言咨询各种问题，其中也不乏一些问题描述的让我根本没法看懂，所以鄙人感觉有必要写一篇小文有针对性的澄清一下这几个概念。。
LAN、WAN、SAN、FC、ISCSI、NAS、LAN-Free、Frontend-Free

LAN：Local Area Network
        这个都知道，局域网。但是好像大家都叫习惯了，反而有人不理解LAN的本质意思了。好好看看这三个字，“局域网”，你在你的本地站点看得见摸得着的所有网络，任何形式的网络，都属于LAN。比如：本地电话交换网络，本地以太网络，本地存储网络。有人质疑，本地存储网络也属于LAN？存储网络不是SAN么？这就是一种概念不清并且不统一。将本地SAN归纳到LAN中将会很好的统一这些概念，随着本文的继续读者将会体会到。

WAN：Wide Area Network，广域网
        泛指跨越远距离的链路，或者地理上相隔很远的两个网络互连起来也形成了广域网。广域网这个词在应用的时候大部分时候指代长距离传输链路，即WAN常用于指代长距离链路而不是网络。比如在说“将本地站点通过WAN连接到远程”，这里的WAN就是指长距离传输链路。为何WAN一词会被赋予这种指代，原因是因为长距离链路普遍都是点对点链路而不是多点互访型链路，所以一个广域网，其具有广域网意义的也就是局域网之间的这条链路了。你说以太网链路是否可以作为广域网链路，当然可以，FC链路也同样可以跨长距离，所以此时也属于WAN链路。
SAN：Storage Area Network，存储区域网络
        即专用于传输对存储设备IO数据的网络。可以是任何形式的网络，比如FC网络，以太网络，SAS网络，Infiniband网络，或者，任何形式的IP网络。使用FC网进行IO传输的叫做FC-SAN，同理，使用IP网络的叫做IP-SAN。基于SAS网络的呢？当然叫SAS-SAN了，以此类推。那么，有人推出来个Ethernet-SAN，是不是也可以呢？上文说SAN也可以基于以太网络。没错，你可以这么说。你可以把FCOE称为一种Ethernet-SAN。那么IP-SAN是否也属于Ethernet-SAN呢？部分属于，因为IP-SAN的底层链路一般情况下都是使用以太网的，但是绝对不能说IP就是以太网。比如你使用ADSL通过Internet，一样可以连接到ISCSI Target，那此时就不能称其为Ethernet-SAN了，只能叫IP-SAN。以上列举的这些个访问方式，或者说协议，目前都是基于Block形式的SCSI协议+底层传输协议。还有另外一种存储IO访问方式协议集将在下文描述。

NAS：CIFS和NFS以及其他第三方厂商自行开发的基于文件偏移量IO的文件型IO协议
        业界将能够提供文件型IO访问而存储数据的存储设备称为NAS，即Network Attached Storage。NAS设备在局域网内部目前都是使用以太网来作为底层传输链路的，寻址路由和传输保障协议分别使用IP和TCP这两种目前最为广泛的协议。在这之上便是CIFS、NFS等上层协议了。NAS是一种设备，而不是一个网络。但是可以用NAS来指代文件型IO的访问方式，比如描述某个设备的IO方式是Block方式还是NAS方式，注意，但是避免用这种描述“某个设备使用SAN方式还是NAS方式”，原因下文再述。

SAN所包含的元素：
        关于SAN这个词有几个误区或者不成文的说法，比如只把将基于FC的数据传输方式叫做SAN，或者反过来，当说SAN的时候只表示FC-SAN而忽略了IP-SAN，这样容易对阅读方造成不便、混乱和误解。比如在描述某款产品的时候，“前端支持SAN方式访问”，其实这个设备只支持FC-SAN，但是他没有明确指出是否支持IP-SAN，这样就给阅读者带来了不便。
        另外，SAN是一个网络，但又不仅仅只表示由交换机组成的底层网络，而它包含更加丰富的元素，比如磁盘阵列、磁带库、虚拟化设备、备份服务器等。可以说SAN这个词与SA（Storage Area）近乎同义了，或者说SAI（Storage Area Infrastructure）。比如可以这样说“某SAN中包含两台xx磁盘阵列，一台备份服务器，一台磁带库”。

笔者建议：今后在描述具体技术参数时杜绝单独使用“SAN”一词，代之以“FC-SAN”“IP-SAN”“NAS-SAN”等，或者干脆直接只用协议来描述，比如FC，ISCSI，CIFS，NFS。比如“前端支持FC、ISCSI访问方式”，这样就没有任何歧义了。
各种关系论：

• LAN与WAN的关系：LAN与WAN就是本地和远程的对应关系，本地的就是LAN，远距离的就是WAN。以太网与LAN的关系：绝对不要把LAN等同于以太网。LAN是一个大涵盖，不仅仅包括本地以太网络。如果某人描述“客户端与服务器通过LAN连接，服务器与磁盘阵列通过SAN连接”，这句话不是不对，但是描述太含糊，“通过LAN连接”，那种底层链路？没说。虽然大部分还是理解其意思，但是终究是不严谨。不如直接说“通过以太网连接”。另外，本地SAN也属于LAN，所以这句话追究起来，就是个病句了。
• SAN与LAN和WAN的关系：如果一个SAN，或者说SA，完全在本地，则可以把这个SAN归属于LAN。如果某个SAN是跨长距离链路部署的，则可以说这个SAN跨越了WAN或者WAN链路。
• SAN与FC和ISCSI的关系：FC泛指一种传输协议，即Fibre Channel。用FC协议来承载SCSI之后产生的协议叫做FCP。ISCSI指用IP网络来承载SCSI之后产生的协议。SAN与FCP和ISCSI的关系，就是网络与协议的关系。数据在SAN网络内传输时使用的多种协议中包含了FCP和ISCSI协议。
• SAN与NAS的关系：NAS指一种设备，SAN或者说SA指的是一种网络和这个网络区域内的各种元素，NAS当然也属于存储区域中的元素，所以NAS属于SAN。

乱七八糟的Free：

• LAN-Free：
      这个词根本不应该存在。
      关于他的由来，是起源于备份领域的一种技术。一般在某个企业网络系统内，客户端与服务器是使用以太网络进行数据通信的，而传统的备份系统中，备份服务器和介质服务器也需要使用以太网络与需要备份的服务器进行通信，将服务器上需要备份的数据通过同一个以太网络传输到介质服务器上从而写入介质保存。由于客户端与服务器通信的以太网络的繁忙程度直接关系到客户端的响应速度，本来对延迟就比较敏感。而备份数据流也通过同一个以太网进行传输，只能是火上浇油。那位说了，以太网交换机目前这么便宜，再买一个，服务器上再加个网卡，专门用于备份数据流的传输，井水不犯河水，客户端以太网不就是Free了么，不就行了么？是啊，所以说“LAN-Free”这个词真的让人摸不着头脑了。为什么这么说呢？上文说过，很多人都直接用LAN来指代客户端与服务器通信的前端以太网，或者不管前端还是后端，就指以太网。这样的话，刚才那个例子，再用一个单独出来的以太网专用作备份数据流的话，这样到底叫不叫LAN-Free了呢？如果说，“LAN-Free”中的“LAN”仅指代前端以太网而不是备份专用以太网的话， 那么上面的方法就是LAN-free；但是如果这个LAN指的是以太网的话，那么上面的方法依然用到了以太网，就不是LAN-Free。到底是不是呢？乱了。再说了，LAN本来的意思是局域网，即本地网络，不管你再怎么折腾，只要还在本地备份，那么都属于LAN之内，那么就不是所谓“LAN-Free”。彻底乱了。所以说，这个词根本不应该存在。哪个词更能表达这种不消耗前端客户端网络的备份方式呢？鄙人发明的一个词叫做“Frontend-Free”。
• Frontend-Free：前端网络Free，即不管你怎么折腾，只要不耗费前端网络资源，管你再用一台以太网交换机也好，或者直接使用FC网络来存取备份的数据也好，都是Frontend-Free。这不就解决了么？

笔者在做一些方案或者写一些文章的时候，都会时刻注意这些词的应用，力求清晰严谨。

分享

分享

        存储和计算结合之后，是什么样的产品形态啊？计算，存储，都很牛叉的机器？
JIM GRAY，有一篇论文谈到，真正成本最高的地方在网络…我们也确实可以感觉到，在同步数据，或者做灾备的时候，最头疼的还是两个节点之间的通道有多大
       这里有个观点，叫做三统，哪三统呢？首先是集群的统一，大家知道目前有各种各样的集群，比如计算集群 、存储集群，存储集群中又分为汲取SAN、集群NAS、分布式文件系统、集群文件系统等，那么如此多样的集群，其本质无非就是一堆x86的节点，用某种网络连接起来，后面挂了大量磁盘的，他就是存储集群中的节点，拥有大量CPU和内存的，它就是计算节点，如果两者皆有，那就是统一集群了。为何计算与存储以前要分开呢？因为以前的DAS直连存储性能和容量均跟不上，而且是属于孤岛形态，必须要将其与计算分开独立发展，先发展为双控制器传统网络存储，此时计算与存储无法合体，但当外置存储发展到集群化形态之后，虽然其表像仍然是分的，但是其里面却是合的，对外合为一体的。此时，计算与存储集群经历了长久分开之后，也必将会重新合体，寻回其本源。大家可以看到这是一个轮回。如今，存储系统正在向集群化发展，而计算也是集群化，那么计算集群与存储集群就可以完美的被融合起来了，形分神合。这种形态也属于之前提过的“自助型存储集群”。除了主机集群与存储集群的合体之外，集群SAN与集群NAS其实也可以统一，目前很多厂商都推出了块虚拟化产品，它们的Lun在后端其实就是一个文件，可以被打散存放在底层磁盘各处。既然SAN设备底层都使用类文件系统来管理了，那么SAN与NAS的后端其实就已经被统一了，剩下的，就是前端访问协议的统一了（见下）。此外，集群硬件也将变为一个平台，其上的各种协议、应用，则变成了一种服务，比如SAN服务、NAS服务，而分布式文件系统则是集群NAS的支撑层，其本身与集群NAS属于一种本质上的东西。至此，集群硬件形态与上层软件充分解耦。
       其次是访问协议的统一。既然集群已经变为一个通用集群，那么访问这个集群的方式也应该被融合。上文中曾经提到过，文件与块的本质其实是一样的，只是组织与访问方式不同罢了。如今块虚拟化的存储系统比比皆是，它们无一例外都将Lun像一个文件一样来对待，恨不得直接在纯种文件系统中用文件虚拟出一个Lun来岂不快哉？既然这样，底层其实是被文件系统给统一了，那么外围的访问方式上，也应该被统一。本质上讲，不管是块还是文件，其实它们都用同一种协议访问：操作码、目标、起始偏移、长度。对于块访问，目标就是Lun ID，而对于文件，目标就是某路径，比如/a/b/c.txt，那么是否有一种东西来屏蔽目标的不同呢？其实早就有这种协议，说到这里大家可能就悟到了，这就是对象存储系统，对象存储协议就是将文件与块访问大统一的最佳候选协议了，只要时机成熟，文件、块大统一的访问方式必将席卷存储技术领域。块与文件这两种访问协议分开太久了，有合的趋势与欲望，底层技术也很给力。其实对象存储协议早在上世纪80年代就被提出了，时隔30年，如今终于有了用武之地，就是利用对象协议，可以将文件与块的访问完美的融合统一起来。如果真的可以用对象存储做到统一，那么主机端会出现一种新的HBA，即OSD HBA，其将OSD Initiator集成到硬件中，存储对象既可以表现为一个目录，又可以表现为一个卷。
       最后，就是网络的统一。不管第一网第二网还是第三网（分别指代前端业务LAN，中间的存储SAN以及后面的集群通信网），如果有一种网络可以同时满足需求，那么为何不统一呢？比如以太网。
       做到这三统，这才是真正的统一存储，而不是同一个机头同时出块和文件协议，这就叫统一存储？噱头而已，看似统一，实则意义不是很大。
       再说回来，这种统一之后到底是个什么牛x机器？答案是不是单独的机器，就是一群机器，通过软件模块联系起来，对于计算机来讲，硬件属于物质本源，属于阴，属于形；软件则属于精神本源，属于阳，属于神。用软件模块将计算和存储颗粒汇总起来发挥作用，并且将原本的以计算为中心的计算方法变为以存储为中心的计算方法，把计算颗粒分配到存储了计算所需要的数据的节点上，在哪存储就在哪计算，大幅提高效率和速度，避免了频繁大量数据传输，这也回答了你的另外一个问题“成本最高的是在网络上”，其实这句话暗指，数据移动起来成本太高了。网络本身成本不高。但是如果要容灾，依然可以使用这个思想，即在哪存储就在哪计算，可以在业务层面进行双份，而不是数据层面，比如一笔交易，可以在业务层面将其同步到远端，远端针对这笔交易生成自己的数据然后下盘，一个实际例子比如数据库日志同步方式的容灾，同步量相比直接底层数据同步来的少很多。
       你说的那种“计算与存储都很牛x的机器”，也不是没有，但是还不到时候，到了量子计算和分子存储时代，那时候计算机形态又会轮回到初始原点状态，单台机器，确实很牛x，大家都拿高速网络来连接到这台超级计算机上获取资源
       最后，预知详情，请阅将在明年3月出版的鄙人专著《大话存储2》

分享

分享

【陈怀临注：今天与Tilera创办人Anant Agarwal教授见面的时候，他给我带来两篇其Lab的最新文章–Factored Operating System和另外一篇关于云计算OS的–An Operating System for Multicore and Clouds: Mechanisms and Implementation。我非常感动与自豪。感动的是Anant的谦卑。自豪的是我对OS的热爱和理解能让他这样著名的教授appreciate。。。我答应会仔细的阅读文章并给他反馈意见。】

分享

分享

【陈怀临注：这是多伦多大学Livio对过去N年来操作系统领域Top会议文章的一些调查数据。调查数据表明，在系统软件领域，工业界Applied Research的贡献的比重在不断的上升。由此可见，系统软件确实是一个强应用的学科。。。另外，对作者人数的调查发现，基本上都是团队作战。很难相信一个人能整一个系统软件。。。。。。另外，在2000年，Bell Lab的Rob Pike曾经发表了其著名的系统软件无路可走的观点–Systems Software Research is Irrelevant。 在学术界和工业界，其实附和的观点很多。我个人认为，在多核，众核和将来Massive核，然后是NUMA basedMassive核的将来，系统软件的将来还是明朗的。有许多事情值得去创造。经典的OS是不适合新的应用的。新的应用会催生新的系统研究的发展。。。BTW，Rob现在在Google当差。。。Google的美金和宽松文化吸收了太多太多的精英。。。很难想象世界上哪个公司能抗衡。。。。。。】

分享