从云计算到云原生：从概念到落地
云计算最近几年已经火得不行，云原生（Cloud Native）这个概念又来了，如果上云不“原生”，那就等于白上云。究竟什么是云原生？云原生有何优势？怎么从“不原生”一步一步做到云原生？本文将给出切实可行的云原生落地指南。
我们先从云计算说起。在云计算普及之前，一个应用想要发布到互联网，就需要企业自己先买几台服务器，找一个IDC机房，租几个机架，把服务器放进去。接下来就是装Linux系统，部署应用。我们就假定用Java写了Web应用，怎么部署上去呢？先配置Tomcat服务器，在把编译好的war包上传到服务器，有用FTP的，安全意识高一点的会选SCP，然后配置Nginx、MySQL这些服务，最后一通调试，把应用跑起来，就算齐活。
这种物理机配合自搭网络环境、自搭Linux、自配环境的方式，有很多缺点，但最主要的问题有这么几个：
- 扩容和维护难，因为是物理机，需要先采购后跑机房，遇到双十一业务量猛增是来不及扩容的，用行话讲就是计算资源缺乏弹性；
- 安全性太差，熟悉Linux的运维工程师本来就少，精通SELinux的更是凤毛麟角，而且，系统安全性仅仅是一个方面，应用部署的权限、流程造成的安全漏洞更大；
- 部署流程不规范，开发、测试和运维脱节，缺少自动化测试和部署，无法快速迭代业务。
解决方案是上云。上云不能解决所有问题，但部分解决了前两个问题：
- 云服务商提供的是虚拟机，比起物理机，虚拟机的创建、维护、销毁比物理机简单了太多，且随时可以扩容，很大程度上解决了“弹性计算”的问题，至于弹性程度有多大，还得看应用的架构和设计水平；
- 和绝大多数中小企业相比，云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像，配合防火墙规则，系统级别的安全问题大大减少，可以将重点放到应用本身的安全性上。
但是如果仅仅满足上云，把物理机换成虚拟机，把物理网换成虚拟专用网（VPC），是远远不够的。这些是计算资源和网络资源层面的简化。应用方面，如果延续旧的一套开发、测试、部署流程，做不到快速迭代。
要做到快速迭代，敏捷开发，就需要DevOps，即开发运维由一个团队负责，开发阶段，就要把部署、运维的工作考虑进去，而不是发布一个war包或者jar包后扔给运维不管了。
重开发、轻部署，直接后果就是缺少自动化发布流程。想要把部署规范化，就需要整体考虑一系列问题。
还是以Java应用为例，如果是手动部署，那么就上传war包到服务器，覆盖原有的版本，重启Tomcat，再测试。如果发现有严重问题要回滚怎么办？把老版本再传一遍，然后重启Tomcat。
手动部署，每次部署都是一次生死考验，所以最好不要安排在半夜，以免手抖敲错了命令，本来中断10分钟的服务，变成了灾备恢复，中断3天。
稍微靠谱一点的是写脚本部署，但各家写出来的脚本都有各家特色，不通用，不易维护，所以更好的方式是用成熟的部署方案，比如Ansible，把脚本标准化，比如做成蓝绿发布，把服务器分组，比如A、B两组，先把流量切到B组，升级A组服务器，有问题就回滚，没问题了，再把流量切到A组，升级B组服务器，最后，恢复正常流量，整个部署完成。
但是回滚这个事情，远没有那么简单。做过开发的同学都知道，升级新版本，一般要加配置，改配置，如果回滚到旧版本，忘了把配置改回去，那旧版本可能也不能正常工作。
上云，除了物理变虚拟，简化运维外，最重要的特点——弹性计算，一定要充分利用。
理论指导实践，实践完善理论。如果我们分析大多数基于互联网的应用，可以看到，一个应用，通常用到的资源如下：
- 存储资源，通常对应着一个或多个数据库，例如MySQL、Oracle、PostgreSQL等；
- 计算资源，以Java应用为例，就是一个或多个Web应用，跑在Tomcat，或者通过SpringBoot自带嵌入式服务器；
- 网关，通常是Nginx之类的服务器，对外作为统一的服务入口，对内提供反向代理；
- 其他支撑业务的组件，例如，为提升应用性能采用的Redis集群作为缓存，应用内部各组件通信使用的消息系统如Kafka等，以及随着业务不断扩大增加的ES集群、日志分析和处理的集群等。
上云后，云服务商通常都提供托管的数据库，以及大规模存储系统（S3），可解决存储资源问题。通过云服务商提供的负载均衡（Load Balancer），也无需自行部署Nginx等网关，免去了运维的问题。各种标准的业务组件如Redis、Kafka等，均可直接租用云服务商提供的资源。
我们重点讨论计算资源，也就是云上的虚拟机资源。对于应用来说，可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着，如果有本地文件的修改，它就是有状态的。有状态的应用既不利于扩展，也不利于部署。反过来，如果一个应用在运行期数据总是存在数据库或者缓存集群，本地文件无任何修改，它就是无状态的。
无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要，它是指，一台虚拟机通过一个固定的镜像（预先内置好必要的支持环境，如JRE等）启动后，部署一个应用（对应一个war包或者jar包），该虚拟机状态就不再变化了，直接运行到销毁。
有的同学会问：如果给这台虚拟机重新部署一个新的应用版本，它的状态不就发生了变化？
确实如此。为了确保虚拟机的不变性，一旦启动后部署了某个版本，就不允许再重新部署。这样一来，对虚拟机这种计算资源来说，就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的，与之打包的配置文件是确定的，不存在今天是版本1，明天变成版本2，后天回滚到版本1的情况。
计算资源不变，能确保启动一台虚拟机，对应发布的应用版本和配置是确定的且不变的，对于运维、排错非常重要。
那么如何在保持计算资源不变的前提下发布新版本？
我们以AWS的CodeDeploy服务为例，假设一组正在运行的某应用v1集群包含3台虚拟机：
┌─────────────────────────────────────┐
│ VPC │
│ ┌────────────────────────┐│
│ │ Target Group ││
┌──┴──┐ │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
└─────────────────────────────────────┘
现在，我们要把应用从v1升级到v2，绝不能直接把现有的3台虚拟机的应用直接升级，而是由CodeDeploy服务启动3台新的一模一样的虚拟机，只是部署的应用是v2。现在，一共有6台虚拟机，其中3台运行v1版本，另外3台运行v2版本，但此刻负载均衡控制的网络流量仍然导向v1集群，用户感受不到任何变化：
┌─────────────────────────────────────┐
│ VPC │
│ ┌────────────────────────┐│
│ │ Target Group ││
┌──┴──┐ │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
│ ┌────────────────────────┐│
│ │ Target Group ││
│ │┌──────┐┌──────┐┌──────┐││
│ ││EC2:v2││EC2:v2││EC2:v2│││
│ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
└─────────────────────────────────────┘
v2集群部署成功后，做一些自动化冒烟测试和内网测试，如果有问题，直接销毁，相当于本次部署失败，但无需回滚。如果没有问题，通过负载均衡把流量从v1集群切到v2，用户可无感知地直接访问v2版本：
┌─────────────────────────────────────┐
│ VPC │
│ ┌────────────────────────┐│
│ │ Target Group ││
┌──┴──┐ │┌──────┐┌──────┐┌──────┐││
│ ELB │───┐ ││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘ │ │└──────┘└──────┘└──────┘││
│ │ └────────────────────────┘│
│ │ ┌────────────────────────┐│
│ │ │ Target Group ││
│ │ │┌──────┐┌──────┐┌──────┐││
│ └───▶││EC2:v2││EC2:v2││EC2:v2│││
│ │└──────┘└──────┘└──────┘││
│ └────────────────────────┘│
└─────────────────────────────────────┘
稳定一段时间（例如15分钟）后，销毁v1集群。至此，整个升级完成。
上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布，适用于更大规模的应用。
把计算资源不可变应用到部署上，实际上是充分利用了弹性计算这个优势，短时间创建和销毁虚拟机，只有上云才能做到，并且针对云计算，把部署流程变得更加简单可靠，每天发几个版本甚至几十、几百个版本都变得可能，DevOps能落地，有点“云原生”的味道了。
说到AWS的CodeDeploy，最早我使用AWS时，对于它的计费采用Reserved Instance预付模型感到很不理解，租用一台虚拟机，按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗？如果仅仅把上云变成租用虚拟机，那就完全丧失了弹性计算的优势，相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机，而是一种规格的虚拟机。我们还是举例说明，如果我们有1台2v4G规格的虚拟机，并购买了1年的Reserved Instance，那么，我随时可以销毁这台虚拟机，并重新创建一台同样规格的新的虚拟机，Reserved Instance计费会自动匹配到新的虚拟机上，这样才能实现计算资源不变，频繁实施蓝绿部署，真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式，有点真正的云计算的付费味道了，但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。
讲了这么多自动化部署，实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点，设计一整套开发、部署、测试的流程，就是云原生。弹性资源利用得越充分，云原生的“浓度”就越高，就越容易实施小步快跑的快速迭代。
那么虚拟机是不是弹性最好的计算资源呢？从应用的角度看，显然容器是一种比虚拟机更具弹性，更加抽象，也更容易部署的计算资源。
容器和虚拟机相比，它实际上是一种资源隔离的进程，运行在容器中的应用比独占一个虚拟机消耗的资源更少，启动速度更快。此外，容器的镜像包含了完整的运行时环境，部署的时候，无需考虑任何额外的组件，比其他任何部署方式都简单。使用容器，开发部署流程就变成了开发，生成镜像，推送至Docker Hub或云服务商提供的Registry，直接启动容器，整个过程大大简化。
使用容器比使用CodeDeploy部署还要更加简单，因为CodeDeploy需要在虚拟机镜像中预置Agent，由于没有统一的发布标准，还需要配置CodeDeploy，告诉它去哪拉取最新版本，这又涉及到一系列权限配置。而容器作为标准的部署方案，连发布系统都以Registry对各个镜像版本进行了有效管理，所以部署非常简单。
容器作为一种弹性计算资源，也应遵循计算不变性，即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则，因为通过一个镜像启动一个容器，在运行过程中，是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统，因为重启后这些修改将全部丢失。
容器的启动和销毁非常容易，不过，容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等，Kubernetes作为事实上的容器编排标准平台，已经成为各个云服务商的标配。
如果要直接使用K8s，在云环境中首先要有一组虚拟机资源作为底层资源，然后搭建K8s环境，定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务，但直接管理K8s仍然需要非常熟悉K8s的工程师。
还有一种更简单的使用容器的方式，即完全将底层虚拟机和K8s托管给云服务商，企业客户只需关心如何部署容器，底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说，计算资源直接使用容器，再配合云服务商提供的负载均衡，托管的数据库、消息系统、日志系统等组件服务，应该是目前最“云原生”的一种方案。
最后，我们总结一下云原生的特点：
所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。
云原生是一个大方向，在上云的过程中，逐步改造应用架构和部署流程，从手动往自动转，逐步增加计算资源的弹性，就能把云原生一步步落地。