OpenAPI的业务环节、系统架构与运营

今天，OpenAPI作为互联网在线服务的发展基础，已经成为越来越多互联网企业发展服务的必然选择。随着OpenAPI的发布数量不断增加，它的存在也开始暴露出越来越多的问题。一个基本的观点是：OpenAPI并不是万能的良方妙药，而是一个新的生态。

Twitter的运营问题

前几天在网上看到这样的一则有关Twitter的消息：
尽管最近又拿到了一笔风险投资，但Twitter似乎遇到了中年问题，前几天居然因为一台数据库服务器崩溃(原因是居然是连接数过多!）而导致禁止了很多关键功能。接连几天，服务都极不稳定。或许是数据库崩溃问题带来的雪球效应吧。因为这一系列问题的困扰，用户怨声载道。Twitter 倒是做了“改进”：开辟一个子站点用于即时报告各项服务的状态问题。值得一提的是，Twitter开发Blog上回答用户的技术询问倒是态度端正。然而，现在技术问题成了Twitter进一步发展极其严重的瓶颈，在所有的 Web 2.0站点里，这种情形是比较少见的。尽管Twitter过去号称把性能提升了 100多倍，看来还远远不够。

前一段时间，有小道消息说Twitter准备放弃RoR，倒是Twitter忙不迭辟谣，表示这种转型不会发生，然而Ruby on Rails在从事这类密集的消息服务工作的同时，确实面临前所未有的压力。在恼火的用户面前，Twitter也承认架构上的一些问题：“Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system.”然而我们必须看到，最初Twitter的架构是面向内容管理系统而不是消息系统的，这个转变过程还需要一段时间。

从Twitter得到的启示

从Twiiter这段时间的表现，我们可以发现一些问题，这些问题正是与OpenAPI相关的。因为Twitter的整个应用模式建立在OpenAPI的基础之上，它是一个提供Web、IM、SMS等服务的提供商。值得注意的是，大多数用户并没有通过这个网站发布内容与其他用户互动，更多的形式是通过即时通讯软件（例如Gtalk、MSN等）、各种基于其OpenAPI的客户端（例如Twinkle等）进行的交互，可以说Twitter正是一个存活于OpenAPI基础之上的互联网服务中心。在过去的一年中，我曾大量使用Twitter，可以明显感受到的是，其服务中断次数和低质量服务数量正在随着Twitter用户数量的猛增而持续增加着。其实，问题在于两个系统架构和一个系统运营之间的问题：

1.OpenAPI是对业务环节的重要考验。一个定性错误的业务，会导致OpenAPI的全面失败。Twitter一直没有把自己转变成为消息中心，而认为自己是一个blog系统或是SNS。虽然我并不能说这个网站正在逐渐走向失败，但是其业务本身的质量确实受到了持续的影响。

2.OpenAPI是对于系统架构的重要考验。正确的理解业务，确定架构基础出发点和考虑方面，对业务和系统架构做出合理的修正，才能使得OpenAPI真正的实施好。如果Twitter在预计到业务快速发展的同时，对其系统架构作出了合理的修正，今天我们看到的Twitter也许是另外一番情景。

3.OpenAPI是一个系统运营的重要考验。因为OpenAPI必须要在系统运营中面对一群代码识别优良好坏，不让不良请求干扰系统的正常运行。当然也正是需要在系统运营过程中对系统架构和系统进行一轮又一轮反复的重构。

一个Google的两个案例

很多读者可能并不明白系统运营的意义，我们可以使用一个生动的例子来看看，这是一个Google财¾¬（http://finance.google.com/finance?q=SINA）的显示（图1）：

在网页的右侧是一个与这支股票相关联的信息，它们体现着这个股票的波动参考。而在谷歌中国的网站（http://finance.google.cn/finance? q=SINA）中，我们看到的是这样一个网站（图2）：

这两张图片尽管看起来极其相似，然而在关键性内容上，我们却可以看出两者明显的不同。如果按照谷歌中国所分析的这种情况，那么是否大家都应该认为中国外汇超市网在主导着新浪的股价？

总结起来，国内做OpenAPI的难点在于极度缺乏优秀的系统架构和系统运营能力，使得OpenAPI在性能上成为产品的短板。对于一个OpenAPI的提供商而言，开放某一个或某一组API并非难事，但是要持续地确保这组API一直可用，而且不会出现脏数据，这就是一件非常困难的事情了，而恰恰是服务不可用，或大量垃圾信息和数据正在不断伤害着我们的用户。

重新理解OpenAPI运营

再来分析一下这三个Ô¬因：业务环节的理解、系统架构、系统运营。
何为业务环节的理解，OpenAPI如何理解业务环节？作为一个OpenAPI的基础，我们可以发现大多数的OpenAPI可以分为三类：信息发布、消息通讯、交易事务。

所谓信息发布，就是说通过OpenAPI需要将内容发布出去，这样的例子从早先我们所说的RSS、Blog PubAPI到现在新兴的Amazon的S3都是以这样的业务环节为基础的。它的基础在于用户贡献一份内容，它将会被多次使用，这样的使用包括阅读、索取等各种操作。它的特点在于整体操作上以读多写少，内容变化不多为基础，通常一份内容会被利用很多次，而这很多次操作都是在读取它的内容。

所谓消息通讯，就是说通过OpenAPI需要将内容分发出去，这样的例子从早先我们所说的SMTP、XMPP到现如今我们刚提到的Twitter都是以这样的业务环节为基础的。它的基础在于用户间的内容具有一定的定向性。它也会被多次使用，这样的使用包括内容的分发、阅读等各种操作。其特点在于整体上读写比例比信息发布要更平衡一些，更重要的是它的内容通常完全不会发生改变，只有增加、删除这样的操作。

所谓交易事务，就是说通过OpenAPI需要完成一个事务型的交易，这样的例子从早先提出的各种电子商务的Web Services到现在我们所知的Amazon的EC2都是以这样的业务环节为基础的。它的基础在于用户的操作是一个带有目标的一次性操作，这样的操作包括支付、系统调用操作等。它的特点在于所有的内容均于一次性的，即时需要知道操作的结果是否成功。更重要的是它的内容在当时即被使用，之后均不可再用。
在准备提供一个OpenAPI前，你必须清晰地知道自己的OpenAPI所支持的业务环节是什么样的模型，对于这样的分析结果会在之后的系统架构中充分的体现出来。

对于系统架构则是一个大家都能理解但通常来讲做的不多的事，系统架构则是通过业务环节的模型，以网络、硬件、系统、开发为基础，对要投入使用的产品进行一个综合的设计的过程。系统架构更多的是从成本、性能、可用性、可靠性等多个方面进行设计。通常来讲，对于以上三种业务环节的模型均有一系列的解决方案，这里不再多讲。

对于最后的系统运营，则是一个新鲜的事务。系统运营的工作则是在系统交付给客户提供服务之后，以一个日常维护的形式保证系统的可用性、可靠性。而在这中，内容的可用性也是系统运营所需要保障的项目之一（在一些企业中也称之为产品运营）。OpenAPI做为一个服务，它所服务的用户是互联网上所有的用户，必须在运行过程中对用户的所有操作进行记录、跟踪和分析，以保证系统及内容的可用性。不应该出现谷歌中国中一系列与本意相冲突的情况。在OpenAPI设计和不断的重构中也应加以重视。

作者简介：
黄冬，有多年软件开发、系统架构、系统运营的¾¬验。长期关注于高可用性、高可扩展性的系统架构设计。主持设计和运行过多个大型高容量产品和系统，也是中国FreeBSD、Python社区的发起和积极参与者，也是国内啄木鸟（http://www.woodpecker.org.cn ）社区的创始人之一。他的Blog为http://blog.opensource.org.cn/hdcola

（本文来自《程序员》杂志08-07期）

11310314_200807221106311.jpg

11310314_200807221106312.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11310314/viewspace-406805/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11310314/viewspace-406805/