今天，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财¾¬
