分享

[ 编者注: OceanBase是一个支持海量数据的高性能数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务，由淘宝网核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。其源代码已于8月31日遵照GPL2开源。

本文第一部分转载于淘宝网核心系统研发部博客, 原始链接位于http://rdc.taobao.com/blog/cs/?p=956

第二部分转载于OceanBase主程序员杨传辉同志的个人博客 , 原始链接位于 http://www.nosqlnotes.net/archives/tag/oceanbase

OceanBase的源码可于http://code.taobao.org/project/view/587/ 处得到]

OceanBase是什么

OceanBase是一个支持海量数据的高性能数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务，由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。

OceanBase解决什么问题

许多公司的核心资产是各种各样的商业数据，例如淘宝的商品、交易、订单、购物爱好等等，这些数据通常是结构化的，并且数据之间存在各种各样的关联，传统的关系数据库曾经是这些数据的最佳载体。然而，随着业务的快速发展，这些数据急剧膨胀，记录数从几千万条增加到数十亿条，数据量从百GB增加到数TB，未来还可能增加到数千亿条和数百TB，传统的关系型数据库已经无法承担如此海量的数据。许多公司，尤其是互联网公司，正在探索各自的解决之路。
一个思路是通过类似map-reduce模型进行处理，例如Google的 GFS+MapReduce以及Hadoop的HDFS+MapReduce。这类方式为离线数据处理及挖掘提供了一个不错的选择，但难以满足在线实时服务系统的需求。
另一个思路降低一致性来换取数据规模，例如BigTable和HBase实现了单行事务的海量数据的存储访问，Amazon的Dynamo以及由Facebook开源的Cassandra实现了最终一致性，这类系统常常被称为NoSQL数据库，它们在一些网站(例如Google，Facebook和Twitter等)得到了应用。
一个新近出现的系统是Google的Percolator，它在GFS/BigTable基础上实现了海量数据(PB级)的分布式事务。由于Google并没有把Percolator开源，其他公司无法使用它，此外事务响应时间偏长(平均2s-5s)以及单机效率低(Google声称Percolator的效率大致为DBMS的1/30)也限制了Percolator的使用(更多信息，请参见Daniel Peng和Frank Dabek的“Large-scale Incremental Processing Using Distributed Transactions and Notifications”一文)。
从Eric Brewer教授的CAP(一致性C: Consistency， 可用性A: Availability，分区容错性P: Tolerance of network Partition)理论来看，第一种思路重点在于支持CP特性，第二种思路重点在于支持AP特性。作为电子商务企业，淘宝和其他公司的业务对一致性和可用性的要求高于分区容错性，数据总量庞大且逐步增加，单位时间内的数据更新量并不大，但实时性要求很高。这些需求建议我们提供一套更加偏重于支持CA特性的系统，同时兼顾可分区性，并且在实时性、成本、性能等方面表现良好。

OceanBase的一些基本概念

OceanBase逻辑架构简图

主键

row key，也称为primary key，类似于DBMS的主键，与DBMS不同的是，OceanBase的主键总是二进制字符串(binary string)，但可以有某种结构。OceanBase以主键为顺序存放表格数据

sstable

一种数据存储格式，OceanBase用来存储一个或几个表的一段按主键连续的数据

tablet

一个表按主键划分的一个(前开后闭的)范围，通常包含一个或几个sstable，一个tablet的数据量通常在256MB左右

基准数据和动态数据

OceanBase以增量方式记录一段时间内的表格数据的增删改，从而保持着表格主体数据在一段时间内相对稳定，其中增删改的数据称为动态数据(通常在内存，也称为内存表)，而一段时间内相对稳定的主体数据称为基准数据，基准数据和转储后(保存到SSD固态盘或磁盘)的动态数据以sstable格式存储

ChunkServer

保存基准数据的服务器，通常是多台，为了避免软件硬件故障导致的服务中断，同一份基准数据通常保存了3份并存储在不同ChunkServer上

UpdateServer

保存动态数据的服务器，一般是单台服务器。为了避免软件硬件故障导致的服务中断，UpdateServer记录commit log并通常使用双机热备

MergeServer

进行静态动态数据合并的服务器，常常与ChunkServer共用一台物理服务器。MergeServer使得用户能够访问到完整的最新的数据

RootServer

配置服务器，一般是单台服务器。为了避免软件硬件故障导致的服务中断，RootServer记录commit log并通常采用双机热备。由于RootServer负载一般都很轻，所以它常常与UpdateServer共用物理机器

冻结

指动态数据(也称为内存表)的更新到一定时间或者数据量达到一定规模后，OceanBase停止该块动态数据的修改，后续的更新写入新的动态数据块(即新的内存表)，旧的动态数据块不再修改，这个过程称为冻结

转储

出于节省内存或者持久化等原因将一个冻结的动态数据块(内存表)持久化(转化为sstable并保存到SSD固态盘货磁盘上)的过程

数据合并(merge)

查询时，查询项的基准数据与其动态数据(即增删改操作)合并以得到该数据项的最新结果的过程。此外，把旧的基准数据与冻结的动态数据进行合并生成新的基准数据的过程也称为数据合并

联表(join)

一张表与另一张或几表连接的关系，类似于DBMS的自然连接

COW

Copy on Write的缩写，在OceanBase中特指BTree在更新时复制数据备份写入，避免系统锁的技术手段

OceanBase有什么特点

OceanBase设计和实现的时候暂时摒弃了许多不需要的DBMS的功能，例如临时表，视图(view)，SQL语言支持等，这使得研发团队能够把有限的资源集中到关键的功能上，例如数据一致性、高性能的跨表事务、范围查询、join等。
虽然数据总量比较大，但跟许多行业一样，淘宝业务一段时间(例如小时或天)内数据的增删改是有限的(通常一天不超过几千万次到几亿次)，根据这个特点，OceanBase把一段时间内的增删改等修改操作以增量形式记录下来(称之为动态数据，通常保存在内存中)，这样也使得了主体数据在一段时间内保持了相对稳定(称之为基准数据)。
由于动态数据相对较小，通常情况下，OceanBase把它保存在独立的服务器UpdateServer的内存中。以内存保存增删改记录极大地提高了系统写事务的性能。此外，假如每条修改平均消耗100 Bytes，那么10GB内存可以记录100M(即1亿)条修改，且扩充UpdateServer内存即增加了内存中容纳的修改量。不仅如此，由于冻结后的内存表不再修改，它也可以转换成sstable格式并保存到SSD固态盘或磁盘上。转储到SSD固态盘后所占内存即可释放，并仍然可以提供较高性能的读服务，这也缓解了极端情况下UpdateServer的内存需求。为了应对机器故障，动态数据服务器UpdateServer写commit log并采取双机(甚至多机)热备。由于UpdateServer的主备机是同步的，因此备机也可同时提供读服务。
因为基准数据相对稳定，OceanBase把它按照主键(primary key，也称为row key)分段(即tablet)后保存多个副本(一般是3个)到多台机器(ChunkServer)上，避免了单台机器故障导致的服务中断，多个副本也提升了系统服务能力。单个tablet的尺寸可以根据应用数据特点进行配置，相对配置过小的tablet会合并，过大的tablet则会分裂。
由于tablet按主键分块连续存放，因此OceanBase按主键的范围查询对应着连续的磁盘读，十分高效。
对于已经冻结/转储的动态数据，OceanBase的ChunkServer会在自己不是太繁忙的时候启动基准数据与冻结/转储内存表的合并，并生成新的基准数据。这种合并过程其实是一种范围查询，是一串连续的磁盘读和连续的磁盘写，也是很高效的。
传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间，但数据规模受到严重制约，缺乏扩展性；现代云计算提供了极大的数据规模、良好的扩展性，但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长，OceanBase的设计和实现融合了二者的优势：

1. UpdateServer：类似于DBMS中的DB角色，提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性
2. ChunkServer：类似于云计算中的工作机(如GFS的chunk server)，具有数据多副本(通常是3)、中等规模数据粒度(tablet大小约256MB)、自动负载平衡、宕机恢复、机器plug and play等特点，系统容量及性能可随时扩展
3. MergeServer：结合ChunkServer和UpdateServer，获得最新数据，实现数据一致性
4. RootServer：类似于云计算中的主控机(如GFS master)，进行机器故障检测、负载平衡计算、负载迁移调度等

上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间，还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。

OceanBase现在有什么应用

OceanBase现在已经应用于淘宝收藏夹，用于存储淘宝用户收藏条目和具体的商品、店铺信息，每天支持4～5千万的更新操作。后续将陆续推广至其他淘宝应用。

OceanBase的创新之处在哪里?

ppt已上传到Slideshare上。

从大学的数据结构课程可以知道，数据量比较大时，有两种数据结构很常用：哈希表和B+树，分布式系统也是类似的。如下图：

Amazon的系统实现了一个分布式哈希表，而Google Bigtable, Yahoo PNUTS，Microsoft SQL Azure实现了一颗分布式B+树。分布式哈希表实现相对简单，但只支持随机读取；而分布式B+树支持范围查询，但实现比较复杂，主要有两个难点：

1, 状态数据的持久化和迁移。更新操作改变系统的状态，数据库系统中更新操作首先以事务提交日志（MySQL称为binlog, NOSQL称为commit log）写入到磁盘，为了保证可靠性，commit log需要复制多份并保证它们之间的一致性。另外，机器宕机时需要通过commit log记录的状态修改信息将服务迁移到集群中的其它节点。

2, 子表的分裂和合并。B+树实现的难点在于树节点的分裂与合并，在分布式系统中，数据被顺序划分为大小在几十到几百MB大小的数据范围，一般称为子表，相当于B+树结构中的叶子节点。由于每个子表在系统中存储多份，需要保证多个副本之间的分裂点是一致的。由于子表在分裂的同时也有更新操作，保证多个副本之间一致是比较困难的。

对于这两个问题，不同的系统有不同的解决方法：

1, 状态维持。Google Bigtable将状态数据写入到GFS中，由GFS提供可靠性保证，但GFS本身是一个巨大的工程；Yahoo PNUTS将状态数据写入到分布式消息中间件，Yahoo内部称为Yahoo Message Broker；Microsoft SQL Azure直接通过网络将数据复制到多机，由于一台机器服务多个子表，这些子表的副本可能分布在整个集群中，因此，任何两台机器都可能建立数据复制的网络通道，需要处理与这些通道有关的异常情况。

2, 子表分裂。由于底层有GFS保证可靠性，Google Bigtable设计时保证每一个子表同时只被一台机器(Tablet Server)服务；Yahoo PNUTS通过引入复杂的两节点提交(Two-phase commit)协议协调多个副本之间的一致性，使得他们的分裂点相同；Microsoft SQL Azure干脆不支持子表分裂，牺牲一部分扩展性从而简化系统设计。

淘宝Oceanbase设计之初对淘宝的在线存储需求进行分析发现：淘宝的数据总量比较大，未来一段时间，比如五年之内的数据规模为百TB级别，千亿条记录，另外，数据膨胀很快，传统的分库分表对业务造成很大的压力，必须设计自动化的分布式系统；然而，在线存储每天的修改量很小，大多数情况下单机的内存就能存放下。因此，我们采用将动态数据和静态数据分离的办法。动态数据的数据量小，采用集中式的方法解决，这样，状态数据维持从一个分布式的问题转化为单机的问题；静态数据的数据量大，采用分布式的方法解决，因为静态数据基本不变，实现时不需要复杂的线程同步机制，另外，保证静态数据的多个副本之间一致性是比较容易的，简化了子表的分裂和合并操作。通过这样的权衡，淘宝Oceanbase以一种很简单的方式满足了未来一段时间的在线存储需求，并且还获得了一些其它特性，如高效支持跨行跨表事务，这对于淘宝的业务是非常重要的。另外，我们之所以敢于做这样的权衡，还有一个重要的原因：我们内部已经思考了很多关于动态数据由集中式变为分布式的方案，即使我们对需求估计有些偏差，也可以很快修改原有系统进一步提高可扩展性。

分享

分享

下载方法：

1。 从Apple的app store，search “weconnect”。／／要按回车键 after typed “weconnect”

2。 从 www.weavermobile.com 主页，download page下载。

分享

分享

［请看6：58的慢镜头。罗伯斯的手。。。在这种高强度的速度下，基本上等于是让刘翔的重心和速度都变了样。可惜！］

分享

分享

序一  寻宝处理器的引人入胜之旅

         当出版社的编辑介绍万木杨的这本书给我时，我对书名《大话处理器》是有一定担心的，其一：处理器和计算机的发展几十年来风起云涌，其间有天才的创新、看似偶然的分叉和囿于商业市场考量的成功与失败，一部技术发展史绝不比波谲云诡的社会史逊色。一部“大话”处理器的书会不会流于一部围绕处理器发展种种轶事的大话技术史？读书时固然会津津乐道，兴趣斐然，然而掩卷沉思后，会不会仍然无法对处理器的体系结构有更清晰的认识？其二：处理器的发展是和软件、操作系统的发展互为作用的，其中很多技术点和概念都值得深入讨论。采用“大话”的方式能否既保证技术书籍叙述的准确性，又不至于陷入对某些概念旁征博引的“Rat hole”式的罗列，而变得像很多剪贴式编著的IT书籍一样？

         但其后数次断续读稿时沉浸其中的体验打消了我的顾虑。我几次阅读书稿都是在出差途中（如飞机上），一个很深的体验是一旦开始阅读就不愿终止，一直读到不得不将书稿收起走路为止。另一个体验是，从任何一个间断点，都可以把本书当作入口，去找寻别的书籍进一步深入学习其中的一些关键技术，就好像函数调用一般，这是我所期望的带领读者进入处理器世界的导游书籍，因此非常愿意向广大的读者推荐这本书。

         在技术书籍的阅读中，我偏爱爱因斯坦阐释的方法——“在所阅读的书中，找出可以把自己引向深入的东西，把其他的一切统统抛掉。”这就是抛掉使大脑负担过重和把自己诱离要点的一切。

         万木杨的这本书，在选材上围绕处理器的核心技术，从计算机发展的形态、历史展开叙述，在简略介绍了处理器的周边设备后，迅速深入处理器的抽象模型，以计算机软件生态系统中最重要的指令集体系结构ISA切入到探索处理器的微架构，对处理器微架构的一些核心技术，如流水线、乱序执行、指令级并行、线程级并行、缓存结构和算法、缓存一致性等概念，言简意赅地做了原理阐释。而了解这些核心概念，是理解其后第六章优化代码效率的基础。窃以为这些章节是本书的“hardcore”，很值得一读。

         在本书的写作风格上，作者运用了很多崭新的网络元素和鲜活的比拟来厘清概念，比如用《我的兄弟叫顺溜》中的顺溜装配子弹的例子来开展指令流水线的讨论，既不流于表面、为举例而举例，又一以贯之地将每个案例充分展开、把问题说透，这样的例子在本书中比比皆是，也是我推荐该书的原因之一。这体现了“抛掉使大脑负担过重”的原则，以及作者对所叙述的技术的深度把握。没有这种把握，是很难用好这种比拟的，反而容易变成“画虎不成反类犬”。

        由于长期从事性能优化工作，此前也出版了一本针对并行优化指南的书，因此对本书中阐述并行处理和编写高效代码的章节仍觉意犹未尽，这让我想起了两件事：

         其一，我在2001年左右从事针对多核DSP的手写汇编代码优化工作，就是本书里所总结的VLIW并行实现机制，当时一个很深的感触是，人类大脑的并行度很低，至少在汇编这个层级，能够持续对多个计算单元实现高效并行处理编程的上限恐怕就是四级并行了，人的大脑有所谓“一心不可二用”的限制，因此，此后在IA平台上，多核、多进程一直到大规模集群的并行开发的方向就很清楚了，就是必须依赖高级语言的开发工具，支持并行实现的编译器、数学库和线程，MPI进程追踪工具和类似Vtune这样的指令微架构行为的示波器，来解放人的大脑。另一方面就是开发新的并行编程模型和语言，进一步释放多核处理器的性能。

        其二，在一本论述并行超级计算机体系架构的英文专著上，我曾读到一段话，似可借来总结处理器性能发展的方向。即，要做快、做好一件事，基本上有三种方法。一是把事情本身缩短、少做事，这就是处理器流水线效率、分支预测命中率等等技术的发展，体现在软件上就是更好的算法和更短的代码关键路径。二是做得更快、更勤些，这就是处理器上更多的浮点计算单元、更高效的缓存、新的高效指令集直到AVX这样的高密度向量计算指令。三是让别人去做或者和别人一起做，这就是并行，多线程和多进程的并行工作。处理器的发展，从性能上看，基本上也可以归为上述三点，比照本书的结构，读者也可以做个归纳。

        未来的发展，我们看到了SOC的兴起，我们看到CPU和GPU的混合计算，我们也看到英特尔即将推出的、针对大规模并行应用、集成众核架构的协处理模式的处理器。正如丘吉尔所言，“你能看见多久的过去，就能看见多远的未来”。回顾本书中提到的那些引人入胜的处理器技术的来龙去脉，背后的技术原因或是市场竞争要素，奇妙之处在于，处理器的技术史是我们创造出来的，而身处其中之人却难以知晓，那就让我们“把其他的一切统统抛掉”，一起踏上本书寻宝处理器的引人入胜之旅！是为序。

 何万青 博士

英特尔数据中心产品部 高性能计算/工作站架构师

当当网预售链接

c114网友评论

楼主很强很油菜！——robotbob

顶起，很直观，很具体，楼主快点。——gdxky

LZ这样的高人应该推荐到高校做教授，那将是民族之幸哦。写的理论透彻、根本，文字通俗简练，语言风趣形象，好！ ——shore70

希望中国多点像楼主那样的人才！——davidchan110

楼主真强悍，讲解通俗易懂，顶一下！——汉江之畔

真的讲的好，让我这个处理器的门外汉也产生了兴趣！——tian_mengguang

要是做总的软件架构工作，你一定能成为大师级的。——我爱生活

楼主，我虽然不是学数字信号处理出身，但是你的讲解太伟大了。我真的手不释卷啊！快点刷新吧。——中飞人1234

越牛的人讲的东西越通俗易懂。——时光机器007

写得真好！通俗易懂，比较形象化。——ksyjk

属于深入学习的人才能写出这种文字，现在太需要这样的人才了，更希望看到的朋友也别顾着只叫好，大家以大侠为榜样，在各自的领域中都能做到深入浅出，与己与人都是一笔财富！——yucheng_xiao

呵呵，佩服楼主的专业知识是如此的给力啊！——xiao麦子

写的不错，通俗易懂，楼主威武啊！——caodianxin2011

楼主太有创意了，这样的帖子太强了！——lsmx01

分享

分享

上周炒得沸沸扬扬的QE3问题在周五终于揭晓，伯南克不打算立即再次量化宽松。他宣称美联储拥有足够的手段来刺激经济，九月会再讨论经济刺激的问题。并且，他坚信下半年美国的经济发展会好转。同时，他也批评了华盛顿处理债务上限危机的方式，并且警告，如果再像这样下去，会让国外投资者对于美国金融资产的信心受到沉重打击。
QE3不推出并不出乎意料，这个我在微博上也进行了分析。现在再推QE3，对经济的刺激作用可能并不那么明显。现在并不是企业或者银行手里没有现金，目前的问题是现金堆积在公司帐号或者银行资本储备里，却不拿出来使用。QE之后，现金没有流向扩展生产和贷款，而是被截住了。奥巴马本打算大规模筑路修桥，花费政府的钱来解决就业问题。但是由于现在美国债台高筑，加上共和党坚决抵制加税，奥巴马要通过这个办法需要克服很多障碍。捷径是刺激房地产市场，让房价再次升起来。据CNBC报道，一个可能的方案是让银行放松对Refinance的房主信用门槛，使得数百万购房者可以得到refinance的贷款。
现在投资者对银行信心不足，如果再放松信贷，很可能银行自身借债都会困难。巴菲特此时买入银行，一方面是为了自己获利，同时也帮了美国银行和美国政府一个忙，可以说一举多得。他用自己影响力巨大的信誉给银行业投了信任票。
伯南克相信下半年美国经济会复苏，没有立即动用任何手段，也稳定了市场的信心。现在市场看的就是接下来的经济数据会否好转，以及奥巴马和国会能否排除分歧，达成共识。如果这两点可以做到，那么市场会有一个很大的涨势。本周将发布一些关键数据，包括消费者信心，房价指数，以及Chicago PMI指数等。本周的走势很可能是上扬的，之前市场对于美国政府不作为的反应已经很激烈，现在的情绪可能是保持着对政府采取行动的期望。美国国会九月会回来工作，奥巴马也已经宣称要在最近发表新的经济提升计划。同时，数据很可能证明美国经济并没有真的陷入衰退那么悲观。但是市场的中期走势，主要还是看行动和经济数据。
新浪微博 蓝海财经－美股

分享

分享

这个题目是在暑假在北京时胡编的。当时，刚把略带黄色的Cache Coloring的文章写完。据说Cache Coloring的文章在江湖上还是受到一定的肯定。。。，特别是那些有过实战经验的同学。。。这种妈咪小姐的讲解体系结构高级话题的教学方式估计是大牌教授们或者CAP们无法达到的境界。。。

为什么想写这个《浅谈高端通信系统中的一些分布式理论基础》呢？

大概是这样的。

＊ 是一个交叉学科。通信的人对IP Header，Protocol比较熟悉一点。知识面相对而言，不太懂OS，System，和Distributed System。分布式系统的人对网络比较薄弱一些。对Queue的敏感度略微差。另外，分布式系统的人做通信的人比较少，去Lab，或者互联网公司比较多一些。单纯做分布式系统的人比较浮。单纯做网络的人比较扎实，但基础不够从而导致后劲不足。

＊现代通信系统，特别是高端通信系统，基本上是分布式通信系统的结构了。要把握好，必须具备一些基本的知识结构。

本文将会站在网络工程师的角度，来考察分布式系统。而非otherwise。

本文的读者应该是一些对通信系统有强烈兴趣的年轻人［学名：菜鸟］，而非那些已经在江湖上的碗儿。

什么是分布式通信系统？

如果用洋文来说：What the hell is Distributed Networking System？

与经典的Distributed System是一个什么关系？ 与Google，Facebook等大型Internet公司的分布式系统是什么概念上区别？

这貌似是个不容易的问题。

分享

分享

弯曲的朋友们，陈首席，各方大侠，潜水的大牛：

我是猎头顾问willson，上次多亏借助贵宝地，帮助客户寻找到合适的候选人。这次受客户（全球500强，通讯领域的领导者）委托，寻找下一代通讯领域研究的大师，主要是研究下一代通讯技术的方向，未来10-20年通讯领域最前瞻的技术发展方向。

要求在存储、网络安全、光网络、传统通讯领域、下一代网络、高性能及分布式计算等领域有过一个或两个领域有过非常深入的研究，有过成功的产品架构设计的经验，并对该领域有独到的认识和理解，对未来技术走向有独特见解。

工作地：全球。

有兴趣的朋友可以直接把简历或联系电话发到我的邮箱：willson25@live.cn, 以便深入沟通。非常欢迎各位朋友推荐身边的朋友，尤其是硅谷的朋友，欢迎推荐业界的大牛的，在此感激不尽，千言万语汇成一句话，拜托了。

感谢各位朋友的支持和帮助，感谢首席，感谢所有成为弯曲的以及将要加入弯曲的朋友。

分享

分享

——————————————————–前言————————————————————–

在Netscreen的日子里是我生命中最重要的一段时光。我从一个懵懵懂懂的初级工程师，成长为Juniper中国研发中心的总监，期间收获巨大。

早期的岁月里，每天工作12-14个小时，总有干不完的活，但是心情却很愉快，因为每次都学到很多。前几天接受一个前IBM资深讲师的培训，说到每个人在成长过程中都会有一段Trash Time，就是别人总把各种各样的垃圾工作(Trash)扔给你，你就好像一只垃圾桶一样。有些人会怨天尤人，期望换个环境规避，殊不知这是自己成长的最重要的阶段。如果你没有经历过这个阶段，你就无法迈入职业生涯中的更高境界。

06年自己创业，创办了Hillstone山石网科，在国内安全界算是后起之秀。接触许多优秀的年轻人，在他们的期待下，写出这段经验，和大家分享。

—————————————————————————————————————————-

97年的春夏之时，我接到邓锋一个电话，问我有画图的软件没有。我找出来后，他约我一起见见。

第一次见面好像是在一个中餐馆里，邓锋身材高大，相貌英俊，也善于谈吐。他解释说他和两个同学准备创业，要做防火墙。那时我对网络的概念一点都没有，当时接触的多是电信上的东西。他介绍说Cisco就是靠把路由器变成Appliance而成功，他们要做的就是防火墙硬件化。随即他邀请我加入。我其实没有任何概念，加上当时业余时间也没有什么事，就随口答应了。

既然要加入，总得个面试程序，虽然他们还没有成立公司。我们约好在Mountain View的一家粥店与他的另一个伙伴谢青见面。去之前邓锋给我简单介绍了他们的情况，当时邓锋在Intel担任Mobile Chipset开发小组的经理；谢青在Healthon任IT总监；第三个创始人，柯严，在Cisco是ATM产品的软件架构师。他们的创始团队里还有一个人，不是创始人，算是第一个员工，Charles Shao。邓锋，柯严，谢青都是清华大学无线电系81级的同班同学，后来谢青因为身体原因，休学一年，和82级一起毕业。Charles是无线电系80级的，是当时学校里赫赫有名的学生勤工俭学三联公司的总经理。面试没有什么印象了，随后安排开始工作。

这里有个情况向大家介绍一下，我当时是拿H1-B签证，也就是工作签证。美国的劳工法很严，不允许非法打工。拿工作签证的只允许在当初申请签证的公司工作。因此我在邓锋那里，只算是帮忙，不能拿报酬，何况当时他们也没有钱付我薪水。

第一次上工是在邓锋家里。他刚在West San Jose买了房子，记得客厅里木头地板刚打过腊，光亮光亮地，有趣的是，每个椅子的腿都套了个袜子，看得出来他很爱惜，怕家具挪来挪去，划伤了地板。一进门，见到了一个老朋友，五字班（清华85级）的Jian Gong。Gong和我在学校里在同一个教研组做毕业设计，他比我高一班，因此相识。邓锋曾经担任过五字班的辅导员。

Gong是湖南人，和我算是老乡，个头不高，但是很能干。他在负责原型机电路板的PCB设计。我的工作主要是帮邓锋看他设计的原理图，板子回来后参加调试。

就这样，我和开始邓锋认识，并一起共事七年。

—————————- 版权所有 Hillstone 老童 欢迎转载  —————————-

分享