1

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

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

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

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

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

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

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

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

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

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

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

2

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

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

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

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

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

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

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

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

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

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

3

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

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

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

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

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

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

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

4

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。