五年Skype架构师之路的感言.pdf

五年 Skype 架构师之路的感言 简介 作为架构师和设计者，我们常把手头的事情作为工作焦点，很少反思过去如何。我们应该温故而 知新。我从作为 skype 架构组领导的 55 个月经历中总结了 6 个经验。其中一些是技术性的，另外一些 是架构师较为软性的观点。首先介绍一下 Skype 的背景资料。 Skype 背景 Skype 是让用户可以进行音频视频通话的软件，也可以拨打普通电话以及发送短消息。公司成立 于2003 年，从成立以后就有令人难以置信的成长曲线。公司现在有超过五亿两千万注册用户，大 约650 名员工。这些用户同时产生平均 21万个通话，其中大约三分之一包含视频。这个数字大致上 是全世界国际通话的 8% 。 不用多加说明也能知道，这个通讯量产生了罕见的扩展性挑战。在 Skype 一直使用端对端（ peer to peer ）技术作为处理类似挑战的主要武器。对等网络（核心用 C语言实现）主要是由 C++ 编写的服 务器端服务及 Postgre 数据库支持组成，并结合强大的 Python 脚本。 Web 服务使用 PHP 搭建。 技术方面 经验法则不适用 在作为软件工程师的职业生涯中，一些模式会慢慢浮现出来，一些经验规则会显现出来。显然，你 愿意无论何时何地都一直使用这些规则。毕竟它们过去都很有效，是不是？ 事实证明，即使你有好用的锤子，也不要把身边所有东西都当成钉子。在快速变更的现代科技社会 ，经验法则不会一直适用。例如，我们看看 Skype 数据库是如何架构的。 传统智慧说永远不要在数据库里面实现业务逻辑。为何这个说法传播如此广泛？大多数架构师都有 类似经验，这会导致原始数据库在硬件方面如巨兽般增长，无法运行，也非常难维护。 这个假冒克苏鲁恐怖神出现的原因是主要数据库平台常常缺乏两个重要而且立等可用的特性：横向 划分数据库的能力（比如根据数据实体划分数据）和纵向划分数据库的能力（不同的数据库实体放 入不同数据库中）。当然，我们可以自己建立这两种特性，但是数据库管理团队以外的人常常也想 处理类似问题。对于 DBA 来说这是赖以生存的手段而不是用于解决问题的能力。也就是说，对数据 库做划分或者队列的技术常常要存在于数据库之外，使得开发者需要自己处理协议转换、多种接口 、数据集成等问题。 在 Skype ，维护数据库的这些人恰巧也是 Postgre 的重要贡献者。从很早开始他们就拒绝把数据库看 成是系统架构角落一个大而无当的罐子，反而以积极地态度去学习技术，解决他们遇到的扩展性、 性能及可维护性方面的问题。像你猜想的一样，这些还不够，即使最好的数据库架构也会在轻率地 编码中被废掉。幸运的是， Skype 数据库管理员从很早开始就掌控了需要进入数据库层的开发工作 ，在执行了一系列非功能需求、代码实现、同事评审过程来确保实现代码适合数据库层以及其他相 关部分的设计之前， Skype 的DBA 不放弃控制。 图一解释了他们如何使用这些工具建立 Skype 数据库架构。 这里由四层构成： 所有这些都是为了保证数据库可扩展性对于开发者不是问题。我们把必要的业务逻辑尽量贴近数据 ，让它最有效的工作，也就是 ”业务逻辑应该远离数据库 ”的经验法则并不适用。当然会有类似发布、 调试以及单元测试之类的困难，但是我们不害怕原始数据库肆虐发威。 图一：数据库层 架构模式也是一样。在工程师之间建立通用技术词汇表、提供验证过的常见技术问题处方是非常重 要的事，应该小心对待。 Skype 的端到端网络就是很好的例子。如果问题以 设计互联网电话“ ”这种方 式提出，多数情况下，人们会设计使用 SIP 来实现要求。但是如果 Skype 通过基于 SIP 实现服务就不 会给通讯工业带来变化。 Skype 早期的工程师不愿把自己限制于这件事通常如何完成，而是找到他 们能建立的最佳可能方案。 总之，略微不同的组织和技能，就可能有必要建立完全不同的架构模式的应用。你应该随时欢迎这 些差异对自己的传统思维挑战。 忽视功能架构吃尽苦头 我们很少有机会在项目初期搭建阶段就作为首席设计师参与工作。