2018：Spring Cloud 的崛起
2018年刚开始接触 sprig cloud 的时候，还不知道 分布式计算 的概念，只知道 Netflix 开源了一套 微服务框架，里面有很多组件组成：
| 组件名称 | 作用 |
|---|---|
| eureka | 服务注册与发现 |
| zuul | 网关路由、反向代理 |
| feign | 客户端侧负载均衡 |
| hystrix | 熔断降级 |
| seluth & zipkin | 链路追踪 |
| config | 配置管理 |
| ... | ....... |
当时按照书上所教的，搭建一个微服务 demo ，就以为 微服务 不过如此。兴冲冲跑去面试，结果遇到一个阿里出来的大佬，他说“只会问你懂的东西，不会问我懂你不懂的东西”，结果就被大佬问到 分布式锁、分布式事务 和 分布式任务调度 要怎么解决？问得我哑口无言，只能灰溜溜地回去。。。
后面经过多番的学习，才知道 分布式计算 是个非常庞大的体系，spring cloud 这套微服务开发框架所包含的知识点只不过是很小的一部分。说到 分布式计算 ，就不得不提 拜占庭将军问题，业界基于这套理论衍生出很多组件：
| 中间件名称 | 作用 |
|---|---|
| redis | 分布式锁 |
| zookeeper | 分布式锁/同步 |
| RocketMQ | 分布式事务 |
| xxl-job | 分布式任务调度 |
| elastic-job | 分布式任务调度 |
| ... | ....... |
说了这么多，事实上只涵盖 分布式计算 很小的一部分，但对于一个普通的 Java Web 开发人员来说，掌握这点知识点已经足够他在北上广深拿一两万工资，过过普通日子。
然而即便如此，在实际的开发流程中，Spring Cloud 这套框架还是暴露出它的致命弱点：
- 侵入性非常强
- 不支持异构应用
首先说说 Spring Cloud 侵入性的一面，强侵入性导致了在将以前单体应用改造为模块化的微服务遇到非常多的麻烦，其中最大的问题是 微服务化改造 过程非常耗时耗力，却没有给公司带来任何短期收益，而且占用原本的产品研发的人力物力。面对这种情况，一般的公司都会选择一边交付新功能，一边改造旧服务的策略。
其次，说起 异构应用，不得不说“明日黄花” PHP 和 “后起之秀” NodeJS。
过去很多公司会采用 PHP 开发 Web应用 ，然而随着 NodeJS 不断崛起，业界流行起 前后端分离 浪潮，PHP 生态虽然受到一定的冲击，但不致命。
然而，一波未平一波又起，业界又兴起 微服务化 的浪潮，不同于以前的是，这次 PHP 彻底掉队了。
之前我在面试的时候，遇到一个唯品会出来的10年开发经验的 PHP 程序员。听他说，前几年公司招了一个技术老总，中层管理大换血，公司的主要技术栈也从 PHP 转向 Java ，他也转向 Java 开发，然而还是逃不过被裁员的命运。。。
这里脑洞大开一下：如果 Spring Cloud 支持 异构应用，或许 唯品会 就不需要付出巨大代价用 Java 重写 PHP 应用，PHP 程序员也不用面临大规模裁员的困境。
Spring Cloud 不支持 异构应用 这一特点，就是一把双刃剑，虽然干掉宿敌 PHP，但并不代表 Java 开发人员就可以高枕无忧。
Spring Cloud 的高光时刻已经过去了，黑暗即将来临：先是 Eureka 和 Zuul 闭源，后面虽然有 Nacos 和 Gateway等代替品，但依旧没解决 侵入性强 和 不支持异构应用 的致命缺陷。
因此面对即将来临的 云原生时代，Java 根本就没有准备好！
2019：云原生时代的曙光
过去的 2019年 可以说是 云原生 元年。
这一年里，Kubernetes 击败了 Docker Swarm、Docker Compose 和 Mesos 等一众对手，坐稳 容器编排 的 第一把交椅
这一年里，Istio 击败了 对手 Linkerd，成为 Service Mesh 的一哥，剑指曾经的大佬 Spring Cloud，大有取而代之的趋势。
说起 Istio 不得不提 Service Mesh，Service Mesh 中文意思就是 服务网格。而在谈之前，还需要讨论一下 Docker。
早在 2015 年，我就听说 Docker 的大名。那时候我还在上大学，每次因为课程作业或毕业设计的缘故需要安装数据库，而 SQL Server 和 MySQL 两者经常发生冲突，每次冲突都只能通过重装系统解决，每个学期重装一次系统都是家常便饭。虽然想过装虚拟机，但那个时候的固态硬盘和内存都特别贵，装完虚拟机后就卡得要死。
当听到 Docker 的时候，我就想用它来代替虚拟机，然而 Docker 并不支持 Windows，还需要安装 Linux 虚拟机才行，所以后面就不了了之。
我敢打包票，即便到了现在依然很多人就跟当年的我一样认为 Docker 就是一个轻量级的虚拟机，所以在 容器 里运行 MySQL 性能会远低于 原生 Mysql，这其实是一个天大的 误会 ！
然而，即便到了 2019 年，Docker 已经支持 Windows 容器，我终于可以运行 容器化 的 SQL Server， 然而在 Windows 上运行 Docker 还是需要安装一个轻量级 Linux 虚拟机。
原因就是 Docker 运行容器的时候，容器之间需要 共享 宿主OS，所以没有 Linux 虚拟机，根本跑不了 Linux 容器。
那么在 Windows 上运行 Windows容器 是不是就不用安装 Linux？答案是并没有。原因是 docker 在运行时需要运行守护进程 docker daemon等监控维持容器运行的组件，所以还是需要运行 Linux 虚拟机。
连以兼容 类Unix 著称的 Mac OS，在运行 docker 的时候，都必须安装虚拟化软件 Virtual Box，更遑论 以封闭著称的Windows。
好了，聊太多题外话，现在回归正题。
在实践 spring cloud 和 docker 的微服务框架时，最常见的问题，无非就是用 docker 部署 eureka 集群，经常遇到 注册中心 和 微服务 组件网络不通的问题。
这时候，见多识广的人会提议使用 compose 或 swarm 来部署，这不过是还抱有 Docker 是虚拟机那种错误认识的人的无奈之举。
随着微服务数量的不断增多，单纯的手工部署和功能羸弱的 compose 和 swarm 已经无法胜任越来越复杂的容器编排工作。
这时候，体量稍微大一点的公司都会招聘专业的运维来搞定容器编排的事情，就轮到 kubernetes 闪亮登场了。
许多连 docker 都没整利索的开发人员，一看到 kubernets 就心里发虚，这就又是个什么玩意？
但公司新来的技术总监，又给老总吹嘘：硅谷的互联网巨头都开始使用 DevOps 模式来管理研发，它可以缩短产品的迭代周期，提高公司竞争力等等。
老总听完，说开发整了个 Spring Cloud 之后，天天搞重构，产品研发进度严重滞后，你就别给我添乱了。
技术总监是何等人物？ 只见他眉头一挑，说道：Spring Cloud已经落伍了，改用Istio，就不用重构以前的 PHP 项目，新出的 NodeJS 也支持。
老总被说服了，反正现在被 Spring Cloud 整得不上不下的，就死马当做活马医吧。
于是，公司上下一下子又活跃起来：开口 流水线，闭口 滚动升级。
那么，k8s究竟是何方神圣？下面我就拿 K8S 以及 Istio 的概念和 Spring Cloud对比一下：
| k8s概念 | spring cloud概念 | 功能 |
|---|---|---|
| pod | container | 部署的基本单位 |
| service | eureka | 服务注册与发现 |
| ingress | zuul | 网关路由、反向代理 |
| dns server | feign | 负载均衡 |
| config map | config | 配置管理 |
| istio envoy | hystrix | 熔断降级 |
| istio envoy | seluth & zipkin | 链路追踪 |
| deployment | 灾备扩容 | |
| StatefullSet | 有状态集群 |
以上的比较并不充分体现两者的差异，也不完全准确，仅供参考。
到这里，基本上就是大多数人公司和开发掉进坑里的地方。Istio 虽然好，但如何落地依然是很多人心头的一块大石。
2020 Serverless 后浪
前面提到， 2019年很多公司刚从 Spring Cloud 的坑里爬出来，又遇到 Istio 的这个拦路虎。
然而，时代的滚轮不断向前，不会因为任何一个人或者组织团体而停下
营销大师 马云 提出 中台 就是 云原生 的终极形态，忽悠了一大批互联网企业的高管。一时间，中台 成为互联网行业的 皇帝新衣，问谁都说知道 中台 是什么，但深究起来，却没几个人能准确回答上来。
后面大佬们回过神来，原来 中台 就是 云原生时代 的 应用商店 。不愧是互联网界的忽悠大师！
随之而来，还有 边缘计算，折腾大半年得出一个由 K8S 阉割而来的 K3S，美其名曰 轻量级K8S。
2020开年就是一场突如其来的疫情，转眼间 2020年 已经过了大半，互联网行业能炒作的噱头都炒完了，只剩下 Serverless 这个后浪还能坚持到最后。
Serverless 出来到现在，都跟 中台 概念一样，人人都在谈，但没有人能够准确地说 Serverless 到底是什么，直到后起之秀 NodeJS祭出终极大杀招 WASM，一时间几乎所有语言生态都想分一杯羹。纷纷放出将自家的 WASM转换 工具，亚马逊也宣布旗下开源的 Serverless 运行时 firecracker 支持 WASM。
至此，业界才知道谁才是真正的 后浪 。