1

2008年的時候，我接觸到了Google App Engine（簡稱GAE），它允許你用自己喜歡的語言如Java, Python來開發應用程序，然后部署到GAE上運行，完全不用考慮應用程序的伸縮問題，GAE可以幫助你從0擴展到全球規模。

你只需要關注你的業務邏輯，而無需關心底層的基礎設施，也不用考慮防火墻等安全功能，并且可以按使用付費，用多少，付多少，這就是激動人心的PaaS?(Platform as a Service)。

國內的新浪和百度也迅速跟隨推出了自己的產品，Sina App Engine, Baidu App Engine。?

事實證明，這種模式并沒有發展起來，為什么呢？?

市場需要的是更加“低級”的產品：計算，存儲，數據庫，隊列，或者是虛擬機。這應該是IaaS（Infrastructure as a Service）層面的東西， 于是亞馬遜的AWS反而發展起來了，吸引了很多應用程序的入駐。

大家都去用AWS，Google的Cloud該怎么辦呢？?

這個時候Docker出現了， Build Once , Run Anywhere ,?使用Docker可以讓應用程序在任何地方以相同的地方運行，因為它把代碼和依賴的運行環境打包，放到了一起。

這是個非常美妙的特性，應用程序可以在服務器之間遷移，那也可以在云之間進行遷移，不用被某個云鎖定了。?

但是，僅僅是單個Docker是搞不了什么事情的，尤其是在微服務架構的情況下，需要很多Docker協作，編排，擴展。?

于是Google下了一步棋， 搞了一個叫做Kubernetes (k8s)?的東西來做這些工作，經過一番爭斗，干翻了Mesos，Swarm等競爭對手，成了事實的標準。?

應用程序所需要的基礎設施層被Google搞定：k8s + docker， 應用程序可以在微軟的云，亞馬遜的云，Google的云，IBM的云之間遷移， 只要支持k8s， 大家站在了同一起跑線上，就看誰提供的服務更穩定，更高效。

2

前面提到了微服務， 微服務想有效地運行起來，還需要很多的基礎設施：服務發現，降級限流，負載均衡等等。?在這方面搞得最好的是Netflix這個網絡視頻點播的公司。

Netflix不但在生產環境大規模使用微服務， 還為Spring Cloud貢獻了大量的、著名的開源組件，包括Eureka， Hystrix， Zuul ，Ribbon?等，可以說是功勛卓著。

在Spring Cloud似乎已經統治了微服務市場的時候，不斷翻新的IT界又冒出了新的概念：?Service Mesh?。?

Service Mesh 說：現在在微服務的執行過程中，需要一個依賴庫，實現微服務的發現，監控和保護， 這個依賴庫和和業務密切綁定，例如Hystrix，Java語言寫的， 別的應用想用的話還得再重復開發一份。

Service Mesh 提出了新的方式，把依賴庫和業務剝離開，讓業務代碼清清爽爽。把依賴庫的功能放到一個叫做代理的模塊中，兩個微服務之間不再直接通信，而是通過這個代理來通信：

這絕對是個釜底抽薪的辦法，這是要革Spring Cloud的命啊！

Google趁機落子，和IBM等大佬提出了一個Service Mesh的框架，叫做Istio， 大有后來居上，收割成果之勢。?

除了Istio, Google還有gRPC來進行微服務之間的調用，支持多語言，多種平臺，并且面向HTTP/2 （也是Google搞出來的，一會詳細說）。?

在跨越網絡調用遠程服務的時候，Python對象，Java對象，C++對象必須序列化才可以跨越網絡的千山萬水，可以把這些對象變成文本，如JSON/XML，還可以把變成二進制的數據。?

Google提出的序列化協議是Protocol Buffers，這個序列化機制也是語言中立，平臺中立的，性能高，數據傳輸過程中壓縮得比較小。

3

從基礎設施到應用框架，Google 都落下了自己的棋子，最后，Google把眼光移向了底層的通信協議。?

Google先是對HTTP1.1動手，做了一個叫做SPDY協議的實驗，非常成功，成為了HTTP 2的基礎。

HTTP 2把基于文本的協議改成了基于二進制的，把HTTP請求和響應變成數據幀，這樣就實現了多路復用：在一個TCP連接上可以“混合”著發送多個HTTP的請求和響應，效率大大提高。

（來源：?https://www.slideshare.net/lmacvittie/http2-changes-everything）

然后，Google對傳輸層協議開刀，搞出了一個新的傳輸層協議QUIC，解決了TCP了諸多問題，有望把TCP給替換掉。基于QUIC，新的HTTP協議，即HTTP/3正在制定當中。

剛開始的時候我還在想，為什么是Google在折騰這些協議？?有那么多實力強大的公司，他們怎么不去做？?

后來突然想到，Google干這件事情是比較合適的，因為他有瀏覽器Chrome，自己還提供了很多服務(Gmail,google.com....)， 既然瀏覽器端和服務器端都掌握了，那修改一下中間的協議做做試驗是很自然的事情，普通用戶才不管這些，只要覺得網速變快了就行。

4

好了，Google現在搞定了基礎設施（Docker+ K8s)，搞定了微服務框架(gRPC+protobuf)，甚至改進了底層的協議(HTTP/2 , QUIC, HTTP/3)，正在用Istio對微服務的降級限流，服務發現等這些依賴庫進行精準打擊，有望成為下一代微服務的基礎架構。

Google是在下棋嗎？我也不知道，我能看到的這家公司把重要的點都給占住了，實在讓人佩服。估計在相當長的一段時間內，都會對后端開發產生重大影響，甚至占據統治地位，大家可以關注一下。?

總結

以上是生活随笔為你收集整理的Google下的这盘“小”棋的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。