卖个艺，给大家来段相声-优快云博客

甲：听说咱们IT界又出了一个新词，叫什么“云原生”？Cloud native?

乙：这都2020年了，还新词？早在2013年人家Pivotal就用这个词开始忽悠了。

甲：那啥是云原生呢？

乙：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API......

甲：打住打住，您能说点儿人话吗？

乙：那是人家CNCF权威的官方定义，你听不懂只能说明你的水平太次。

甲：好好，我水平很次，您倒给解释解释，究竟啥是云原生？

乙：用大白话来说，云原生就是把你的应用程序设计成在云端执行，充分利用云计算的好处。

甲：嗯，我们家的应用在一个机房里运行，用了好几个服务器，一个做负载均衡，三个应用服务器，还有两个数据库服务器，按你的说法，我把他们迁移到云端环境，申请几个虚拟机，那就是云原生了吧？

乙：不不不，你这么做，和在机房里运行差不多，无非是把物理机换成虚拟机而已，你忘了后半句：充分利用云计算平台的优势。

甲：您倒是举个例子啊。

乙：好，假设你们家应用有一天突然火了，现在的服务器应付不过来这么大的流量，你怎么办？

甲：这还不简单，买新服务器，配置服务器，把应用安装上去，运行。

乙：这多费劲啊，得多长时间啊，如果是云原生的应用，它可以自动到扩展出新的运行实例了，如果火热劲儿过去了，可以把这些个运行的实例给撤销掉，这就叫自动伸缩，弹性扩展。

甲：这确实不错啊，还有吗？

乙：天下武功，唯快不破，我问你，你们家应用一天能做多少次发布？

甲：一天发布多少次? 别逗了，我们几个月才发布一次。

乙：如果是云原生的应用，每天可以发布几百次（自然也可回滚几百次），不用停机，轻松支持蓝绿部署。

甲：一天发布几百次，有这必要这么变态吗？

乙：当然，也不是应用所有的代码都发布几百次，一个超大的系统会被拆分成小块儿的服务，这些服务会频繁发布，迅速把新功能推向市场，进行验证。

甲：对我们这个小应用一点儿用也没有。还有别的吗？

乙：云原生的应用具备强大的监控和自动化恢复的能力，可以自动进行健康检查（比如网络延迟如何？磁盘满了吗？），发现故障，自动恢复，重新启动或重新部署相关服务。

甲：我总结一下，无非就是达到快速发布，弹性扩展和高可用性，您吹嘘得这么好，倒是说说怎么才能做到吧！

乙：首先，你得用微服务架构，这样才能独立开发，独立部署，弹性扩展。

甲：我去！难道我不用微服务就没法实现云原生了？

乙：那效果肯定是大打折扣。你一个巨大的单体应用，光启动都得好几分钟，怎么才能做快速部署和发布啊？其次，你得用docker和k8s，再加上DevOps，这样你才能实现应用程序每天发布几百次、并且弹性扩展。

甲：也是，从一个docker镜像，生成一个可以运行的实例，确实简单。

乙：你还得用声明式API和不可变的基础设施。

甲：又不说人话吗？

乙：比如说吧，你的系统需要一个nginx ，你直接告诉云平台：我需要一个nginx，端口80，云平台能根据你的描述来生成一个nginx实例，这就是声明式；如果是命令式，则是这样：从xxxx地方下载nginx安装包，解压到xxx路径，修改xxx文件.....

甲：嘿！声明式是更简单啊，那不可变基础设施是啥？

乙：你发现你的nginx的配置有问题，你想登录进去把它改一下，这是不允许的。因为下一次部署可能就会忘记这个改动。相反，你应该去修改你的声明，完全破换掉现在的nginx实例，重新创建新的。

甲：就是只有新增和删除，没有修改了呗！

乙：对，这样整个系统都处于一个已知的可控状态，无论是发布新功能还是回滚到旧功能，都很方便。对了，差点忘了最重要的东西了，云原生要用Service Mesh （服务网格）。

甲：Service Mesh 我在码农翻身公众号看过，《微服务之赤壁大战》，它的意思是说现在微服务架构需要实现服务发现，负载均衡，服务限流，降级，日志，监控等各种功能，这些功能现在需要程序员调用相关的类库才能实现，用了Service Mesh，这些功能都可以在底层平台中实现了，程序员只关注业务逻辑就好了。