怀念 SinaAppEngine

经历了十几年的运营，SinaAppEngine 终于要走完一个产品的一生，即将下线并永久终止服务了。SAE 是我很早就接触过的平台，也是我人生中的第一份工作。借此契机，回忆一下我在 SAE 期间的一些工作，谨以此文，悼念我心中永远的 SinaAppEngine。

初见

第一次接触 SAE 应该是在大二下学期吧。在那个时代，最火的 CMS 还是 WordPress，那时的我也在折腾着 LAMP/WAMP 的本地运行环境，以及淘宝购买的便宜的虚拟主机，差不多几十块钱一年吧。可想而知，这类便宜虚拟主机的体验其实非常不好，基本上三天两头就会出现问题，不是打不开了，就是数据库满了，即便是服务正常的时候，网络速度也是不敢恭维的，当时虚拟主机几乎也不会有现在 BGP 的网络，大多也还是双线或者多线的接入，但实际体验下来会发现，不管是哪个接入，它的速度都是特别慢，毕竟超售太严重了。也就是在这个时间点，我发现了 SAE 这么一个东西，发现原来在 SAE 上运行 WordPress，速度可以这么快，原来 WordPress 一点也不慢，页面也可以秒开，这对于当时一直在折腾追主机的我来说，是一个巨大的震撼。

不过在试用了一段时间之后，发现 SAE 还是有一些问题的。以 WordPress 为例，在 SAE 的应用商店里面是有一个定制版的 WordPress，直接可以一键安装的，但是如果想在 SAE 上去跑一个标准版的 WordPress，就会发现实际它是没有办法正常运行的，这与 SAE 的分布式、无状态运行环境有关。应用实例无法依赖一个持久且可共享的本地文件系统，而标准版 WordPress 默认依赖本地文件写入，因此无法直接运行。另外就针对这个 WordPress 的一些插件，也或多或少需要进行修改后才能运行。虽然 SAE 的分布式环境让性能有了非常大的提升，但是因为这个架构的变化，导致了很多应用其实不能百分之百地直接运行。在这个 SAE 之上，不仅是 WordPress，还有当时一些比较火的一些框架和项目，如 ThinkPHP、Discuz! 等等, 这些都没办法直接运行在 SAE 上，都需要额外的一些修改，可以说，这也是 SAE 最终不敌其他产品、走向关停的重要原因之一。

入职

说起来入职 SAE 的经历，也是很神奇，在大四的时候，那时还没有现在那种暑期找实习的概念，当时我大学也是名不见经传，也没有什么很大的公司到学校进行校园招聘，所以很轻松的，我就错过了上学期的秋招。不过我当时也是参加了考研，也是稀里糊涂过了国家线，所以当时其实也没那么着急，当然最后确实考研也考上了，只是后来没去上学，这都是后话了。

到了第二年春天的时候，突然的机会，发现了 SAE 的微博发了招聘信息，当时也没多想，也就发了简历，本来也不报任何希望，没想到居然收到了面试通知。面试也是很神奇，一开始约了某天的电话面试，但是到了约定的时间，也没接到电话，一开始还在想是怎么回事，是不是已经招到人了。后来我又尝试性地问了一下，结果是当时的面试官出差，给忘了。好在又重新约了面试时间。一面之后，想着是否还会有技术的二面，结果直接就跳到了 HR 的面试了，一番交流之后，最终还是收到了 SAE 的 Offer，当然也是校招的 Offer，只能说错过了秋招的大巴，没想到又赶上了校招的末班车。

PHP 运行环境！

入职经历了一个稍显平淡的适应期后。我迎来了第一个挑战，给 SAE 的 PHP 运行环境升级 PHP 的版本，彼时的 SAE，PHP 的运行环境下，只支持5.3的版本，而5.3版本已经是一个比较老的版本了，最新的版本已经来到了 PHP 5.6。虽然当时 PHP 升级带来的各项提升都不大，但是一个云平台，一直停留在5.3的这个版本，肯定是不太合适的。

但升级 PHP 版本并不是一件容易的事情。SAE 的架构非常的独特，简单来说，它把所有用户的所有代码，都看成是一个巨大无比的网站，想象一下，你维护了一个网站，这个网站有几十万个域名，代码容量超过1TB，而且由于 SAE 是公有云，各个租户之间的隔离需求，以及租户和平台之间的隔离需求，是需要以最高优先级考虑的，在这样的背景下，传统的基于 vhost 的方式根本行不通，因此，SAE 的 PHP 运行环境，对 PHP Zend 引擎，PHP 的扩展，PHP 的日志等等各个方面都做了大量的定制，甚至在语法层面也做了修改，从而可以实现对海量用户代码的高效运行，这么做的好处不用说了，即使在现在看来，SAE 的 PHP 运行环境依然是独树一帜的，真正意义上做到零访问的情况下零资源占用（当然有代码的存储成本）。任意访问零预热时间，单单从效率这方面，这玩意比后来的基于容器的或者其他方案的 PaaS 平台高到不知道哪里去了。甚至对比很多 Serverless 平台，也毫不逊色。

但很明显，当前这种魔改 PHP 方法带来的问题也是巨大的，PHP 运行环境变得不太好维护了，上一次升级，仅仅是将 PHP 从5.3.3升级到5.3.29，一个补丁版本的升级，就花费了差不多半年时间。因此，我们一开始预估 PHP 5.6 运行环境的适配周期至少需要半年，实际可能还会更久。

当然这也就是我开动小脑筋的时候了，我问了自己一个问题，如果现在不考虑以前的方案，从零开始，应该怎么做呢？当然，这次必须额外考虑一个需求，那就是在保证高效运行的前提下，PHP 的升级和维护必须变得更加容易，最好是能够形成一套方法，针对当前的5.6版本，以及未来更新的版本都能以类似的方法快速适配。最终，我把老 PHP 运行环境里每个修改的部分都研究了一遍，做了一遍逆向，反推出当时修改的原因，并基于这些需求，再确认哪些是必须保留的特性，哪些是必须通过修改 PHP 源码本身才能实现的特性，以及哪些是可以通过其他方式实现的特性，从而形成了一套相对完整的升级方案。

好在 PHP 引擎整体的架构设计得相当灵活，大概95%的需求，都可以通过扩展注入的方式实现，这就意味着可以在不修改 PHP 源码的情况下，可以直接通过扩展来修改 PHP 本身的行为，做到对 PHP 版本的解耦，而剩下的5%的需求，依然还是需要对 PHP 的源码进行修改，而这次，会使用一个聪明的办法来实现，将所有的修改都放到单独的文件里，这样当 PHP 源码变化很小时，Patch 可以被直接 Apply。

最后呢，PHP5.6的升级项目大大快于预期，差不多只用了3个月的时间就完成了，而且在后续的升级中，非常的顺利，后来即使是 PHP7.0（Zend 大改版）的适配时间也没有超过1个月。

关于 PHP 运行环境，还有很多故事可以说，后面再慢慢总结吧。

RDS（托管式数据库服务）

SAE 一直是有数据库服务的，之前 SAE 支持的数据库服务叫 RDC（Relational Database Cluster），但是呢，这玩意的实现是一个共享的模式，也就是说，会有一堆人，一堆应用共享一个 MySQL 的端口，而在当时，一方面，MySQL 本身还不是非常的成熟，大部分的 MySQL 表使用的还是 MyISAM 引擎，另外一方面，硬件上 SSD 还没完全普及，导致数据库的性能并不理想。于是，冲突就产生了，如果不加限制，会很容易出现某个用户或者某个应用因为不规范的使用数据库，导致把整个数据库端口拖垮，从而影响在这个端口上所有的其他用户，甚至有可能影响到整个平台，这在要求多租户强隔离的云计算场景下是完全不能接受的。因此为了解决多租户隔离的问题，RDC 对用户使用做了非常多的限制，包括但不限于单表行数限制，单 SQL 扫描行数限制，数据库容量限制，索引限制等等，这些限制一方面在 RDC 架构层面必须存在，无法解决，另一方面对于用户来说是实实在在的障碍，导致了 SAE 对于用户门槛的进一步提高，更关键的是，PaaS 化的数据库服务，在云计算平台中，绝对是溢价最高的服务之一，对于整体的营收和利润帮助巨大。

基于这些因素，SAE 需要一个对于应用或者用户级别独享的、基于 CPU/内存/存储等底层资源限制，而不是基于业务层面限制的数据库服务，这也就是后来的 RDS 独享数据库服务。其实在当时 RDS 服务并不罕见，不说 AWS，就说当时的阿里云，就早早的推出了 RDS 服务。而 SAE 的 RDS 服务，也是瞄准了阿里云的 RDS，一开始就希望可以把产品追平阿里云，但不得不说，在整体的投入上，SAE 和阿里云有着很大的差距，特别是阿里云有相对成熟的 VM 虚拟化层做支撑，而我们并没有类似的技术，这方面的劣势是巨大的，甚至对我个人而言，这几乎成了当时的心病，拥有一套成熟的 IaaS 体系，对于一个云计算平台来说，实在是太重要了。

RDS 服务算是我人生中第一个经历完整研发流程的项目，从开始的产品调研，到需求评审，再到设计、开发、测试，最后上线运营，整个过程都参与其中，这让我对一个完整的产品生命周期有了深刻的理解和体会。甚至后来很多年都很少有类似的机会，可以真正意义上的按照类似的生命周期去参与一个产品的开发。虽然当时的 SAE 是个不算特别大的团队，但是针对这个项目，表现出整体的专业性也是比很多草台班子要强得多的。

当然在研发过程中，特别是后端的开发过程中，也是遇到了太多的问题，一开始我们期望使用 Docker 来实现隔离，我们算是国内较早接触并在生产环境中使用 Docker 的团队之一，在那个 Docker 刚刚出现，连 OS 都还没完全准备好的时候，我们就已经开始尝试在生产环境中使用它，这带来了巨大的挑战。不过今天肯定也不会聊太多的技术内容了，和 PHP 运行环境一样，留给后面的文章吧。

死局

在16年初的时候，SAE 迎来了一次巨大的调整，整体人员规模缩减到了原来的1/3，也许是因为当前不挣钱，也许是因为想达到挣钱的预期投入太高了，高层们的决策逻辑无从考究，但无论如何，SAE 持续投入的基础没有了。

这几乎是必然的，公有云 PaaS，特别是像 SAE 这样的公有云纯 PaaS 平台，面向的市场实在太小了。PaaS 平台都会宣传（至少 SAE 是这样宣传的）自己可以无限自动扩展，没有流量不花钱，但为了达到这样的目的，必然有额外的代价，PHP Runtime 和 RDC 的例子就在这里，其他的服务也是会有各种各样的限制，也就是说，你的应用，必须首先满足某些严苛的要求，才能支持在 PaaS 平台上运行，这个要求，一下子就拦住了大部分的开发者，在一个公司内部，这样的开发规范是完全没问题的，因此 PaaS 平台在某个公司内部，作为同一个运行平台是非常合适的，但是如果把 PaaS 拉到公有云平台，要求你的客户，特别是个人开发者去为你一个平台去做改造，除非你的平台有着无可比拟的优势，否则这是一个非常不现实的事情。

除了平台限制和改造成本，还有个必须要面对的问题，虽然 PaaS 平台宣传上都可以做到无限自动扩展，但很显然这在技术上不可能行得通，随着流量的增大，架构必须要持续的演化，因此，当公司规模增大之后，一定会产生一些平台无法满足的需求，从而催生着公司的架构远离这个平台，曾经创业初期的滴滴，就是运行在 SAE 上的，但是很快地，架构都切回到自建了。当一个公司需要更加灵活的算力时，你却没有，这时候 SAE 没有 IaaS 能力的劣势就变得巨大无比。而且对云厂商而言，toB 业务通常更容易形成稳定的现金流和利润，没有 toB 的业务，也就没有了持续增长的可能。

最后，SAE 这种纯 PaaS 平台，就变得一根筋两头堵了，针对个人开发者，门槛高，限制多，也不一定便宜，更不一定挣钱，而面对企业级客户，架构不够灵活，没有 IaaS 层，没办法针对客户业务做针对性优化，企业想花钱也花不了，注定是个死局。

没有如果的如果

从16年死局确定，到现在，10年时间，有了很多的变化，从19年开始，曾经 SAE 最缺失的 IaaS 层最终还是被我做出来了，经过这几年的迭代发展，可以说在技术上也不输公有云的 IaaS 服务，也在和公有云的正面竞争中获得了不少的份额，但毕竟当前的这个 IaaS 服务自始至终都是面向私有云场景设计并开发，和公有云对于 IaaS 服务的要求还是有一些差距的，虽然这些差距在一定的投入下还是可以弥补的，只是不知道是否真的有机会看到这个平台推向市场的那一天了。

从23年开始的 AI 大爆发，给了云计算市场巨大的增长潜力和机会，截至最近的一次财报，微软，谷歌，AWS 的云计算服务，都迎来了爆炸式的增长，在 AI 应用还没有实现大规模盈利的时代，起码这些出售算力和基础设施的云厂商已经赚的盆满钵满了。每次遇到一些 AI 产品部署相关的需求，我都会不由自主地想起 SAE，在 AI 的时代，编码不再是瓶颈，原型需要快速部署，不访问时没有基础消耗，这些特性实在是太适合 SAE 了，可以说，SAE 对应用改造要求较高这一劣势 AI 时代被大大削弱了，SAE 的很多优势，恰好契合了当前 AI 应用原型快速部署、按需运行的需求。
我时不时得还会忍不住问自己，如果10年前的 SAE 破除了死局，坚持到今天的话，是否也能赶上 AI 的浪潮呢？只可惜，这个问题，再也不会有答案了。