Trunk.ly CTO 董洵谈架构

【编者按】：本期的架构师杂志我们请到了Trunk.ly 的CTO 董洵（Alex Dong，@alexdong）来谈谈他眼中的架构和架构师。

InfoQ：你好，Alex。能向我们的读者介绍一下你自己和目前正在从事的工作吗？

Alex：大家好，我是董洵，目前是 Trunk.ly 网站的 CTO，它是一个专门提供社会化书签服务的站点。由于目前公司的主要员工只有两人，因此，即便我是公司的 CTO，我仍然会每天花很多时候编写代码。就网站后端来讲，目前主要做的是搜索；前端则进行一些站点 UI 的设计和开发。就像大多数创业公司一样，我们非常关注我们的功能特点、站点流量，而且会经常跟投资人打交道。至于架构师这个头衔，其实谈不上，只不过做架构是我们平常工作的一部分吧。在这之前，也曾经用过.net 之类的技术做过企业项目。

【编者注：如果想进一步了解 Alex，读者可以访问他的个人站点以及《程序员》杂志对他的访谈。关于Trunk.ly 域名的含义， @36 氪上的这篇文章中有这样一段描述：我问 @alexdong 为什么用 trunk.ly 这个域名，他说：“是个一语双关. 在航海时代，每个周游世界的人随身要带一个箱子, 这个箱子就叫trunk。现在英联邦国家仍然叫后备箱trunk。我们就是一个链接的百宝箱。”】

InfoQ：作为互联网的创业者，在同行业中有哪些站点的架构会引起你的注意，让你觉得值得钦佩？

Alex：这一点怎么说呢，像 Google。就我个人讲，我会花些时间（虽然我也没有太多的空闲时间）去读 Google Research 上发表的这些论文。像一些大的互联网公司，比方说 Google、Yahoo 和 Amazon 都有自己的 research 部门，他们经常会把自己解决某个问题的经验写成论文发表出来。对于一些架构上的实际问题，比方说 Timeline，这些公司会做一些科研实验，比较各种实现方式的优劣，最终把这些内容总结成文。我会比较多的看这些论文，从中了解这些公司如何解决架构中的某个问题，以及这些问题都有哪些解决方案，以及每种解决方案的好坏。从网站的架构来说，我会比较关注这些内容。除此之外，还有一些东西的架构我也会比较关注，这也是我个人比较感兴趣的方面。比如说 MongoDB、Linux 或者是 HyperTable，像这些新型的数据库、应用服务器等，我也花了不少时间去研究了解它们的架构是如何演进的。

就钦佩这个词来讲，可能有点不太准确。在我看来，它更多的是一种静态的感觉。比方说，当你看到大概有 5 年或 10 年历史的一个架构，第一眼看上去可能会觉得“了不起，想得真是很全面。”，这时你会产生出一种钦佩的感觉。但对我来讲，像 MongoDB，在它还是 1.0 的时候，我就在自己的系统中用它们。更多的时候，我看到了它发展的轨迹。在这种情况下，说钦佩可能不太合适。更多的一种感觉是他们做的这些事情很有意思，很有特点。这也是为什么我会在邮件中提到，相比起架构本身，我会更关注架构背后的人，觉得他们更有意思。通过这些，你可以看到，同样一个问题，由不同的人来解决，最后的解决方案会特别的不一样，而且对应于它的社区，你会发现用这些解决方案的人也特别的不一样。所以这些事情是最令我感兴趣的。

InfoQ：是的，架构本身也是动态发展而来的。人本身有其自身的缺陷，很难设计出来一种面面俱到，一劳永逸的架构。就架构决策而言，应该是架构师在当时环境所能做出的最好决策了。随着时间的发展，周围的环境也会发生变化，这时就需要他来根据环境进行调整。

Alex：没错，这也是我觉得一位好的架构师，他真正的价值不在于从第一天开始就拿出一个蓝图，它有多漂亮、多干净。我认为好的架构师首先应该是知识面比较宽广，需要清楚有哪些选择，每个选择在解决当前问题的同时还会带来哪些影响，也就是每种解决方案好的一面和坏的一面。其次，当遇到架构上的问题时，能够通盘的考虑，发现问题的本质，进而提出自己的解决办法。比如像 Linus，他实现的 Git 其实已经融合了他对于分布式开放源代码项目的管理以及协作方式的思考和理念。

InfoQ：那么做架构决策时，就有点像权衡各方面的因素，从而使架构达到一个比较好的状态？

Alex：说达到一个比较好的状态可能有点欠妥。我可以举一个反面的例子。我之所以说它反面，并不是说这个抉择或决定本身不好，而是说它有不可忽视或是很致命的缺点。像 Python、Ruby 和 V8 Engine 它们都使用了 GIL（Global Interpreter Lock），它的问题在于若是我用 Python 写一个计算密集型的多线程程序，它的性能可能会比不使用多线程还要差。这就是它的运行环境或者说编程语言本身设计理念中埋下的引子。像 Python 之所以用 GIL，是因为 Van Rossum 一开始最主要的设计目标是要非常容易的写 C Extension，即写一个 C 模块，在 Python 中可以很容易的去调用它。有了这个锁之后，使得写 C 模块变得非常的容易。假如没有这种锁，要想实现从 C 调用 Python 或是从 Python 调用 C，就没法做。在我看来，这是 Python 为了实现这种设计目标而不得不做出的极大牺牲。而这一点，就目前看来，其实还是非常致命的，对我们自己应用的影响也很大。

我举这个例子的原因在于，权衡这个词在很多时候看上去很优美，没有负面感觉。可就对我个人来说，很多架构的决定，包括我现在用的很多软件，权衡这个词实际上有着很大的负面感觉，或者说你接受它【架构决策】时不得不承受很大的痛苦。而且很多时候是现实情况下不得不接受，或者说是一种对现实的妥协。因为，就当前情况而言，面对各式各样的约束条件，已经没有其他更好的选择了。假设我有充足的时间和资源，我可能会要求做得更好。

InfoQ：的确，每种工具或架构有其本身适应的环境或者说是前提条件。假设你当前应用的环境跟这个前提或环境有冲突时，就会造成你刚才所说的那种在应用上非常痛苦的一面。

Alex：你说得非常的准确，就是这种感觉。每个架构决策就会使架构僵硬一点，将你推向某个极端或某条路。当然，实在不行的时候，我就会必须将某些东西扔掉。我们做 Trunk.ly 也是沿路扔了不少东西，而且每次也都是在实在没有办法不得不这样做的情况下采取的这项行动。

InfoQ：这些优秀的架构给你的工作带来的怎样的影响？

**Alex：对于这个问题，我想通过《设计模式》来谈一谈。我读这本书大约是在 8、9 年前的事情了，当时的第一感觉是，这些模式设计得真是不错，真的很好。由于当时我用 C++/C#** 的机会比较多，在之后的几年里，我都尽量地去使用它们。可后来我认识到，这些模式其实是只是一种规则。我觉得最理想的，作为架构师，你在读这些规则或者是在用这些规则的时候，要知道这些规则之后的规则是什么。然后将这些背后的规则去用到自己的工作中，而不是单单生搬硬套，为用而用。

也就是说，我希望架构师能够理解这些规则之所以呈现出现在这个样子的原因。一名优秀的架构师，当然是要多看别人设计的架构，但是在看的同时，需要了解到使其架构成型的现实的限制和现实的原因。除去你看到的架构本身，你需要看到一种动态的架构，知道其背后的推理和它的思维。这样，等遇到问题时，就可以应用这些思维方式，而不是简单的应用架构。以 Trunk.ly 的后台搜索引擎的存储为例，到目前为止总共经历了 4 次大的变更，从最初的 MySQL，到 Sphinx，到 Lucene 和 Solar，再到目前的 HyperTable。每次修改都是因为我们知道我们遇到了哪些问题，又因为知道业界都有哪些解决方案，每个解决方案的优缺点是什么，最后有针对性的进行抉择和行动。我举这个例子想说明，正是因为我关注业界目前的动态，以及每种解决方案的优缺点，这样，当我遇到问题时，我就能想得起来去用它们。而作为架构师，是需要通过这种方式去建立起自己的工具箱，而不是单单让自己的手中就握着个锤子。

InfoQ：前面你曾提到相比起架构本身，你对于导致当前架构成型背后的人和故事更感兴趣。能详细谈谈吗？

Alex：我觉得这是件挺有意思的事情。当你做架构做到某一天，就会遇到所谓“治理（Governance）”的挑战。尤其对于开源软件，在这样一种松散的组织结构，谁也不能将自己的设计理念强迫别人接受的条件下，要保证设计目标的达成、版本、特性不断地推陈出新，这时所面临的挑战和协调的艺术，要远比企业内实现同样目的要难得多。大部分的开源软件，到最后都会有一个所谓的“善意的独裁者（benevolence dictator）”，他们来决定特别艰难的决定该如何做。但是，不同的人做“独裁”决定的时候会特别的不一样。

像 Linux 社区，这个“独裁者”会要求你在邮件中把自己的设计理念讲得特别清楚，然后他会通过邮件来进行讨论。但像 Python 就不一样，它一开始就确定了一些理念。作为社区，如果你要贡献源代码就必须承认它们，否则就不会被接受。还有一些开源软件则采用了“不同意就 fork”的道路，假设一两年之后，他们觉得这些 fork 不错，这些 fork 还有可能会重新被接受。比如 Python 社区就有几个著名的 fork，如 pypy，它是用 Python 来写 Python，现在的性能也越来越好了。

通过看这些开源社区的意见领袖如何用“非强制”的手段来保证架构的一致性，消除意见分歧，我觉得是一件特有意思的事情。这就类似在现场看一个直播，对我来讲这比起架构本身成为什么样子要有意思得多。而且在这个过程中，你也可以了解这些软件解决方案诞生的全过程，大家对于问题 / 特性应用场景的讨论和投票，给你带来一种参与感，这是特别过瘾的一件事情。

InfoQ：刚才说了那么多其他人的故事，现在是不是可以说一下你们自己的故事？谈谈 Trunk.ly 经历了几个阶段，每个阶段都有哪些，未来它准备朝什么方向发展？

Alex：做创业公司是有两个阶段的。第一个阶段是摸索阶段，在这个阶段，我还不清楚我的商业模式是否行得通，不知道今天的用户是否就是给我带来收益的那些用户。这个阶段是非常重要的，英文叫做“product/market fit”，在之前的所有架构都不是为了架构本身，也不是为了站点的 Scale，而是为了能让我尽快的去做实验，更快地验证我的假设。

InfoQ：更像一个原型？

Alex：是的，但它不是那种可抛弃的原型，因为我没有这个奢侈去把它抛弃重头再来。我们在去年 12 月份 Trunk.ly 上线的时候，我们对其的定位是一个书签服务，但它是一种透明的书签服务。跟传统的 delicious 不一样的是，你不需要显式地给它去打标签，它会自动收集你在 Facebook、Twitter 和 Delicious 上共享的链接，把它们弄进去进行全文检索。这样，当你想找以前的链接时，你可以通过我们的搜索引擎去找到它。所以，在第一阶段时，为了满足这个商业目标，我们就拿 Django 和 MySQL 快速地把它给实现了。后来数据库就有点顶不住了，于是就换成了 MongoDB，同时有一部分功能就采用了异步的方式实现。

接下来，我们发现之前的商业目标虽然不错，但是这个市场的价值并不是特别的大。然后，通过日志和分析用户的行为特征，我们发现有些用户经常会去看别人共享了哪些链接，所以我们很快就增加一个 Timeline 的功能，这样你在一个地方就能看到你关注的人每天都共享了哪些链接，这样用户就不用跑到每个人那里去看了。这个时候，关于网站的商业目标和定位就有了一点点的变化。这个时候，我前面说的那些网站的论文提供了一些帮助。而且，这个时候大概每周都有百分之二三十的用户增长，比起原来要快多了。而且，很多人会邀请他的朋友来注册 Trunk.ly。你要是在 Twitter 上搜索 trunkly，你会看到每天有四五十条这样的信息，这就是我们的第二个阶段。

第三个阶段就是我们发现这个市场还是不够大。因为，要想把 Trunk.ly 做成一个让人们每天都来的地方，这样做的市场开销特别大，而且不是每个人都有这样的需要。所以，我们开始着手做 Social Search。与 Google 这样把所有人的链接都搜索出来不同，我们的这个功能允许你搜你朋友的链接，这样搜出来的结果相比起前者来讲要更准确，而且跟你的相关性更强。我自己在测试这个功能的时候，也经常因此而“走神”，开始访问起那些链接的内容来。

在这个功能完成上线之后，我们还准备做的一件事情是“Topic”，即允许用户自己来建立自己的主题页面和链接。我们相信，从广告和利润分成来说，这对我们是一个非常大的市场。从我刚才说的这些内容，你可以看出 Trunk.ly 的整个发展过程。我们目前还处在“product/market fit”之前，我想如果一旦证明我们设想的商业模式是正确的话，可能架构还要再变，到时候可能就会更 Scalable 一些，而且架构挑战也就不一样了。

InfoQ：对于未来的互联网架构师，作为过来人，你有什么经验之谈是值得他们注意和避免的？

Alex：我想我上面讲的内容应该已经是我的经验之谈了。如果非要总结的话，那就是，视野放宽一点，不要手里拿着榔头就满眼尽看到钉子；另一点就是好的架构都需要一个过程，多关注一下架构背后的事情。这就是我能想到的经验之谈，也不是什么非常了不起的道理。

InfoQ：非常感谢你能抽空接受我的采访，谢谢！

Alex：不客气。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。