回顧過去看應用 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年，開始基於單元化架構進一步往混合雲架構演進，這個準確來說不算架構級變遷，這個階段要處理的主要問題是：
-
雲的IaaS和自有IaaS的不同，在資源管理層面的介面需要適配多套，這個狀況隨著容器、k8s介面標準化後會好很多；
-
運維時無縫的操作混合雲場景裡的機器。
所以這個階段更多的還是在處理資源層、運維層的問題，不像前面的幾輪架構改造，深刻的影響到了開發態、執行態以及運維態。
應用PaaS的Next
寫Next前先來個簡單的投票：
上面講的PaaS的這個過程，和上篇IaaS有很大的差別，應用PaaS由於和架構對應，所以準確說不一定是個演進關係，更多的還是看對於企業而言什麼架構是合適的。
但上面無論是哪個過程，都可以看到的一點是應用PaaS一直在解決的問題是在這個架構體系下一些通用的技術問題，使得業務系統的開發同學在基於這些技術元件，或開發框架時可以不用過多的關心這個架構體系對應的技術問題，降低了研發門檻，使得業務研發可以更加聚焦業務，從而提升了業務需求迭代的效率。
按照這個，可以看出應用PaaS演進的核心動力就是怎麼讓業務研發能更加的聚焦業務，這個在每個架構體系裡都會不一樣，就像上面的演進可以看出，其實並沒有本質提升這個核心動力，而只是滿足了不同架構體系下的這個動力訴求。
但到了雲時代，看到了讓這個核心動力往前真正提升的機會，就是通過Serverless的思想（繼續強調，Serverless!=FaaS），使得在進入分散式架構、單元化架構、混合雲架構這樣的體系下時，聚焦業務這事能夠有更本質的提升，具體在 Serverless：雲時代的軟體架構核心思想 這篇中已經闡述了我的觀點，再放一張內部同學幫提煉的觀點的圖在此：
對於做業務系統的開發同學而言，如果有機會做比較新的系統，我建議是更多的去使用雲產品，這樣很大程度其實就是一種Serverless的實踐（當然，由於現在雲廠商在這塊還有差距，所以沒那麼強的感受）。
對於做Serverless平臺的同學而言，我的建議就是思考好上面圖片裡說的本質問題，基於你的Serverless平臺，是否可在很低的研發/運維門檻的情況下，實現一個較為複雜的線上業務系統。
過去的多年，更多的是架構的演進帶動了應用PaaS的發展，但云時代的來臨、Serverless思想的提出，使得應用PaaS真正的迎來了一個質變的時代，在這個時代中，誰能先給出一個受廣大開發者群體歡迎、好用、開放的Serverless框架，誰就有機會擁有像Spring在Java圈一樣的地位，並且會更加重要。
歡迎關注我的公眾號hellojavacases，
聊聊程式設計能力的高階進階，
聊聊系統設計，
聊聊技術方向，
聊聊職業生涯的發展。
