回顾过去看应用 PaaS 的 Next

和上周那篇回顾过去看IaaS的Next一样，这篇我将通过回顾我自己所经历的应用PaaS的发展，来找找应用PaaS发展的动力，从而更好的寻找创新方向。

PaaS是个非常广泛的词，这里主要还是说说应用PaaS，我对应用PaaS狭隘的理解为应用开发所需要依赖的基础技术框架或者一堆基础技术组件，或者另外一种说法是，通常现在大家去做一个业务系统时并不会从零开始研发，一般是会先选择一个开发框架，或一堆的技术组件来进行开发，可以认为选择的开发框架或者一堆的技术组件就是应用PaaS，按照这个定义，可以看出应用PaaS的内容主要取决于应用所选择的架构，所以我就按照我自己经历过的几个典型的架构来讲讲应用PaaS。

单体式架构

大部分的应用系统目前是单体式架构，所谓的单体式架构是指整个业务就是一个应用系统，存储可能是数据库、文件系统之类的。

对于单体式架构而言，如果是Java的话，应用PaaS通常就是类似Spring这样的框架，Spring的IoC、AOP、数据库操作的封装、MVC这些基本上可以满足开发一个单体式架构应用系统的技术诉求。

单体式架构->分布式架构

淘宝在07年开始了单体式架构->分布式架构的改造，在这轮改造开始时，发现首先得解决分布式后多个系统之间怎么交互的问题。

两个系统之间交互，通常会有同步、异步的方式，同步交互采用服务化的方式来解决，异步的方式通常采用消息的方式来解决，于是在这轮架构改造过程中淘宝诞生了服务框架HSF、消息中间件Notify。

数据库单机能支撑的能力有限，需要分库分表，而分库分表后业务开发上会非常复杂，于是做了一个分库分表访问的中间件TDDL。

除了上面的问题外，由于集群化、规模的原因，cache、存储都很难用一台机器解决了，于是分布式cache、分布式文件系统也差不多同时诞生了。

当淘宝进入分布式架构时代后， 应用PaaS就从只是一个简单的Spring，演进成了Spring、HSF、Notify、TDDL、分布式cache、分布式文件系统多个技术组件构成。

当年淘宝在做这轮架构改造时，外部直接可用的开源产品实在太少，所以只能自己研发，但到了今天，要做一个分布式架构的应用，通过开源组件基本就可以搭建出来，门槛大幅度被降低，例如选择memcached、glusterfs/ceph、dubbo、rocketmq一堆技术组件或基于spring cloud这样的框架。

分布式架构->单元化架构

阿里的电商架构在2013年开始了从分布式架构->单元化架构（单元化架构师指整个业务系统可以划分为一些业务单元，例如电商有交易单元，并且这个单元可独立灵活部署）的改造，在这轮改造中，出现的最大的问题是所有的系统交互过程中都没有单元这个概念，因此需要让应用PaaS具备单元这个概念能力，从而准确的去相应的单元操作。

除此之外，单元化架构对数据同步有了比以往更高以及更复杂很多的要求，需要在原有的应用PaaS中再增加一个用于实现跨地域、且可支持复杂同步条件的数据同步组件。

可以看到在上面这轮架构改造中，更多的是对分布式架构时代的应用PaaS中的技术组件进行了一轮升级，增加的主要是一个数据同步组件，单元化架构不像分布式架构，基于框架基本可以完成主体，单元化架构还涉及到比较复杂的系统设计。

单元化架构->混合云架构

差不多是在2015年，开始基于单元化架构进一步往混合云架构演进，这个准确来说不算架构级变迁，这个阶段要处理的主要问题是：

1. 云的IaaS和自有IaaS的不同，在资源管理层面的接口需要适配多套，这个状况随着容器、k8s接口标准化后会好很多；

2. 运维时无缝的操作混合云场景里的机器。

所以这个阶段更多的还是在处理资源层、运维层的问题，不像前面的几轮架构改造，深刻的影响到了开发态、运行态以及运维态。

应用PaaS的Next

写Next前先来个简单的投票：

上面讲的PaaS的这个过程，和上篇IaaS有很大的差别，应用PaaS由于和架构对应，所以准确说不一定是个演进关系，更多的还是看对于企业而言什么架构是合适的。

但上面无论是哪个过程，都可以看到的一点是应用PaaS一直在解决的问题是在这个架构体系下一些通用的技术问题，使得业务系统的开发同学在基于这些技术组件，或开发框架时可以不用过多的关心这个架构体系对应的技术问题，降低了研发门槛，使得业务研发可以更加聚焦业务，从而提升了业务需求迭代的效率。

按照这个，可以看出应用PaaS演进的核心动力就是怎么让业务研发能更加的聚焦业务，这个在每个架构体系里都会不一样，就像上面的演进可以看出，其实并没有本质提升这个核心动力，而只是满足了不同架构体系下的这个动力诉求。

但到了云时代，看到了让这个核心动力往前真正提升的机会，就是通过Serverless的思想（继续强调，Serverless!=FaaS），使得在进入分布式架构、单元化架构、混合云架构这样的体系下时，聚焦业务这事能够有更本质的提升，具体在 Serverless：云时代的软件架构核心思想 这篇中已经阐述了我的观点，再放一张内部同学帮提炼的观点的图在此：

对于做业务系统的开发同学而言，如果有机会做比较新的系统，我建议是更多的去使用云产品，这样很大程度其实就是一种Serverless的实践（当然，由于现在云厂商在这块还有差距，所以没那么强的感受）。

对于做Serverless平台的同学而言，我的建议就是思考好上面图片里说的本质问题，基于你的Serverless平台，是否可在很低的研发/运维门槛的情况下，实现一个较为复杂的在线业务系统。

过去的多年，更多的是架构的演进带动了应用PaaS的发展，但云时代的来临、Serverless思想的提出，使得应用PaaS真正的迎来了一个质变的时代，在这个时代中，谁能先给出一个受广大开发者群体欢迎、好用、开放的Serverless框架，谁就有机会拥有像Spring在Java圈一样的地位，并且会更加重要。

欢迎关注我的公众号hellojavacases，

聊聊编程能力的高级进阶，

聊聊系统设计，

聊聊技术方向，

聊聊职业生涯的发展。