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是在下棋吗？我也不知道，我能看到的这家公司把重要的点都给占住了，实在让人佩服。估计在相当长的一段时间内，都会对后端开发产生重大影响，甚至占据统治地位，大家可以关注一下。
往期精彩回顾
编程语言的巅峰
1787
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
