作者：畢玄
文章來源：微信公衆号HelloJava
和上周那篇回顧過去看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年，開始基于單元化架構進一步往混合雲架構演進，這個準确來說不算架構級變遷，這個階段要處理的主要問題是：
- 雲的IaaS和自有IaaS的不同，在資源管理層面的接口需要适配多套，這個狀況随着容器、k8s接口标準化後會好很多；
-
運維時無縫的操作混合雲場景裡的機器。
是以這個階段更多的還是在處理資源層、運維層的問題，不像前面的幾輪架構改造，深刻的影響到了開發态、運作态以及運維态。
應用PaaS的Next
上面講的PaaS的這個過程，和上篇IaaS有很大的差别，應用PaaS由于和架構對應，是以準确說不一定是個演進關系，更多的還是看對于企業而言什麼架構是合适的。
但上面無論是哪個過程，都可以看到的一點是應用PaaS一直在解決的問題是在這個架構體系下一些通用的技術問題，使得業務系統的開發同學在基于這些技術元件，或開發架構時可以不用過多的關心這個架構體系對應的技術問題，降低了研發門檻，使得業務研發可以更加聚焦業務，進而提升了業務需求疊代的效率。
按照這個，可以看出應用PaaS演進的核心動力就是怎麼讓業務研發能更加的聚焦業務，這個在每個架構體系裡都會不一樣，就像上面的演進可以看出，其實并沒有本質提升這個核心動力，而隻是滿足了不同架構體系下的這個動力訴求。
但到了雲時代，看到了讓這個核心動力往前真正提升的機會，就是通過Serverless的思想（繼續強調，Serverless!=FaaS），使得在進入分布式架構、單元化架構、混合雲架構這樣的體系下時，聚焦業務這事能夠有更本質的提升，具體在
Serverless：雲時代的軟體架構核心思想這篇中已經闡述了我的觀點，再放一張内部同學幫提煉的觀點的圖在此：
對于做業務系統的開發同學而言，如果有機會做比較新的系統，我建議是更多的去使用雲産品，這樣很大程度其實就是一種Serverless的實踐（當然，由于現在雲廠商在這塊還有差距，是以沒那麼強的感受）。
對于做Serverless平台的同學而言，我的建議就是思考好上面圖檔裡說的本質問題，基于你的Serverless平台，是否可在很低的研發/運維門檻的情況下，實作一個較為複雜的線上業務系統。
過去的多年，更多的是架構的演進帶動了應用PaaS的發展，但雲時代的來臨、Serverless思想的提出，使得應用PaaS真正的迎來了一個質變的時代，在這個時代中，誰能先給出一個受廣大開發者群體歡迎、好用、開放的Serverless架構，誰就有機會擁有像Spring在Java圈一樣的地位，并且會更加重要。
作者簡介：
畢玄，2007年加入阿裡，一手打造了HSF，十多年來更見證參與了阿裡在基礎技術上的演進與發展：如淘寶在2007-2009年的分布式應用架構更新、2013-2016年的阿裡電商異地多活架構更新等。