今天，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都是以这样的业务环节为基础的。它的基础在于用户的操作是一个带有目标的一次性操作，这样的操作包 括支付、系统调用操作等。它的特点在于所有的内容均于一次性的，即时需要知道操作的结果是否成功。更重要的是它的内容在当时即被使用，之后均不可再用。
