云计算最近几年已经火得不可，云原生(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台虚拟机。
现在，我们要把应用从v1升级到v2，绝不能直接把现有的3台虚拟机的应用直接升级，而是由CodeDeploy服务启动3台新的千篇一律的虚拟机，只是摆设的应用是v2。现在，一共有6台虚拟机，此中3台运行v1版本，别的3台运行v2版本，但现在负载平衡控制的网络流量仍然导向v1集群，用户感受不到任何变化。
v2集群摆设成功后，做一些主动化冒烟测试和内网测试，如果有问题，直接销毁，相当于本次摆设失败，但无需回滚。如果没有问题，通过负载平衡把流量从v1集群切到v2，用户可无感知地直接访问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和阿里云的弹性容器均为此类服务。对于中小规模的应用来说，计算资源直接使用容器，再配合云服务商提供的负载平衡，托管的数据库、消息系统、日记系统等组件服务，应该是目前最“云原生”的一种方案。
末了，我们总结一下云原生的特点：
所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成得当云计算的架构，把摆设设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。
云原生是一个大方向，在上云的过程中，逐步改造应用架构和摆设流程，从手动往主动转，逐步增加计算资源的弹性，就能把云原生一步步落地。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
