我們看 PaaS / CaaS 的區(qū)別和各自的市場(chǎng)，PaaS 的思路基于應(yīng)用平臺(tái)，而 CaaS 并不限于應(yīng)用平臺(tái)，因此它也并不能理解應(yīng)用平臺(tái)的問題；所以兩者面對(duì)的市場(chǎng)還不太一樣，如果著眼于應(yīng)用平臺(tái)那 PaaS 比較好，如果是希望把各種資源管理起來，當(dāng)做虛機(jī)使用，通過容器實(shí)現(xiàn)，那 CaaS 比較好。
關(guān)于 Docker 和微服務(wù)
我認(rèn)為將 Docker 等同于微服務(wù)是一個(gè)誤導(dǎo)性的看法。微服務(wù)由兩個(gè)組成部分：運(yùn)行環(huán)境（運(yùn)行于容器中是很好的運(yùn)行環(huán)境的選擇），開發(fā)框架（比如服務(wù)動(dòng)態(tài)注冊(cè)、發(fā)現(xiàn)和調(diào)用等）。業(yè)內(nèi)很多人只重視到了第一部分，而忽略了第二部分，比如 Docker 微服務(wù)化最常見的就是微服務(wù)的動(dòng)態(tài)發(fā)現(xiàn)和調(diào)用則幾乎完全依靠第三方平臺(tái)來實(shí)現(xiàn)，如 ZooKeeper、Consul 等，但是這些工具的缺點(diǎn)是當(dāng)集群達(dá)到一定量之后就會(huì)出現(xiàn)不穩(wěn)定的問題，而且平臺(tái)要適應(yīng)各種代碼需求有困難，我認(rèn)為程序的事情歸程序來解決，而不是平臺(tái)。最佳實(shí)踐是采用程序框架從根本上解決問題，比如 Netflix 就進(jìn)行了徹底的改造，他們的服務(wù)注冊(cè)、發(fā)現(xiàn)、治理、限流都是通過程序框架（也即后來的 Spring Cloud ）來實(shí)現(xiàn)的，經(jīng)受了大規(guī)模的應(yīng)用考驗(yàn)。用平臺(tái)解決代碼層面問題是有缺陷的，因?yàn)槠脚_(tái)解決的是平臺(tái)問題，不能包攬代碼的工作；代碼框架是解決代碼的問題：服務(wù)注冊(cè)發(fā)現(xiàn)更適合在代碼層面實(shí)現(xiàn)。
當(dāng)然，微服務(wù)還有一個(gè)更關(guān)鍵的問題：如何對(duì)服務(wù)進(jìn)行合理的分解和定義，不是說巨石應(yīng)用隨便按模塊拆分就可以了。經(jīng)常會(huì)有人問，微服務(wù)對(duì)業(yè)務(wù)進(jìn)行升級(jí)以后多個(gè)模塊如何一起部署，問這個(gè)問題就是微服務(wù)沒有做好，學(xué)了微服務(wù)的形，沒有學(xué)到微服務(wù)的實(shí)質(zhì)，最終微服務(wù)的效果也會(huì)大打折扣。問這個(gè)問題的根源在于微服務(wù)解耦的不好，沒有遵循微服務(wù)分解的方法論。如果微服務(wù)分解的好，那很大程度上是可以單獨(dú)部署而不會(huì)影響其他模塊。
微服務(wù)做好了以后怎么運(yùn)維？故障發(fā)現(xiàn)、自動(dòng)恢復(fù)，根據(jù)業(yè)務(wù)請(qǐng)求量的彈性伸縮等等這些工作，要么通過 PaaS 去自動(dòng)實(shí)現(xiàn)，要么自主研發(fā)實(shí)現(xiàn)，但是這樣工作量很大。最終，微服務(wù)的價(jià)值在于讓開發(fā)人員只關(guān)注業(yè)務(wù)邏輯代碼，不用關(guān)注非功能性相關(guān)的技術(shù)問題，這些技術(shù)問題交由微服務(wù)框架和運(yùn)行環(huán)境來解決，而且微服務(wù)最終要能通過平臺(tái)實(shí)現(xiàn)運(yùn)維自動(dòng)化，就是未來的熱點(diǎn)" NoOps "，目前的 ServerLess，Serverless 不是目的，目標(biāo)是 NoOps.前幾年談 NoOps，大家總覺得太遙遠(yuǎn)，其實(shí) PaaS + 微服務(wù)，使得 NoOps 越來越近。
下一個(gè)技術(shù)熱點(diǎn)： 數(shù)據(jù)微服務(wù)
容器是 2015 年最大的熱點(diǎn)，但是 2016 年容器的熱度在下降；2016 年的熱點(diǎn)是微服務(wù)；2017 年我認(rèn)為是數(shù)據(jù)的微服務(wù)化。
為何認(rèn)定是技術(shù)熱點(diǎn)？
之所以認(rèn)為數(shù)據(jù)服務(wù)在 PaaS、CaaS 上的框架這個(gè)會(huì)成為新的熱點(diǎn)，是因?yàn)椋菏紫冗@個(gè)技術(shù)是微服務(wù)的延續(xù)，而且是必然的延續(xù)，微服務(wù)已經(jīng)解決了運(yùn)行環(huán)境-容器的問題，又解決了框架的問題- Spring Cloud 和 Spring Boot，下一步就是數(shù)據(jù)的問題了，而且數(shù)據(jù)服務(wù)化還沒有完全成熟。其實(shí)一個(gè)技術(shù)成為熱點(diǎn)的時(shí)候就是它的對(duì)應(yīng)技術(shù)方案即將成熟又未成熟之時(shí)，容器和微服務(wù)成為業(yè)界注意力中心的時(shí)候都是這樣，也就是大家對(duì)它將懂未懂，最需要了解的時(shí)候，這種狀態(tài)就是技術(shù)熱點(diǎn)狀態(tài)。
以今年火爆的微服務(wù)為例，SpringBoot 很早就開始有研發(fā)；2014 年以產(chǎn)品形式出現(xiàn)，但是當(dāng)年月下載量是十萬級(jí)別，而今年單月的下載量就可以上千萬，兩年不到增長(zhǎng)百倍，這就是熱點(diǎn)。根據(jù)數(shù)據(jù)服務(wù)化的相關(guān)開源項(xiàng)目在社區(qū)的反饋和貢獻(xiàn)量來看，現(xiàn)在也快達(dá)到了同樣的臨界點(diǎn)。
并且，創(chuàng)建大數(shù)據(jù)應(yīng)用仍很痛
現(xiàn)在做大數(shù)據(jù)應(yīng)用，需要裝很復(fù)雜的大數(shù)據(jù)環(huán)境。如果將其服務(wù)化，只需要點(diǎn)擊創(chuàng)建即可，使用者不必關(guān)心后面的 GreenPlum、Hadoop 等是怎么安裝部署的。Hadoop 那么多組件，一個(gè)個(gè)安裝太麻煩了。
目前我們做的數(shù)據(jù)服務(wù)化的技術(shù)儲(chǔ)備包括大數(shù)據(jù)服務(wù)化、數(shù)據(jù)服務(wù)化、流數(shù)據(jù)服務(wù)化，這三類技術(shù)正在逐步達(dá)到生產(chǎn)可用……因?yàn)榇蠹易鐾陸?yīng)用之后就開始考慮數(shù)據(jù)怎么辦，數(shù)據(jù)按照傳統(tǒng)方式來做是肯定沒有問題的，但是應(yīng)用微服務(wù)之后，要求數(shù)據(jù)要和微服務(wù)應(yīng)用對(duì)應(yīng)，原來的巨石應(yīng)用分拆為微服務(wù)了，那原來的大一統(tǒng)的大型數(shù)據(jù)庫，也要根據(jù)微服務(wù)進(jìn)行拆分，拆分之后要分析數(shù)據(jù)是用傳統(tǒng)的 SQL 數(shù)據(jù)庫，還是新的 NoSQL，或是緩存加持久化。所以我認(rèn)為這個(gè)就是將來熱點(diǎn)。以 Spring Data 為例，它負(fù)責(zé)數(shù)據(jù)抽象，至于最后落到哪類數(shù)據(jù)庫 MySQL、Oracle 甚至是 NoSQL 類的 MongoDB 的技術(shù)細(xì)節(jié)，開發(fā)者不必關(guān)心，到部署的時(shí)候再綁定，這就要求數(shù)據(jù)能夠服務(wù)化。