一、背景

        1.从物理机到虚拟化再到现在的云原生。推动基础架构革新的主要源头就是业务应用。

        2.为了解决业务系统的弹性扩容、业务连续性、高可用性加速催生了云时代的快速迭代。

        3.虚拟化时代业务系统无非从物理机迁移到虚拟化环境进行部署，享受到了基础架构迭代到云环境的红利、但业务系统本身可能还是以前的单体大应用或者部分业务系统使用了微服务架构，从一台虚拟机到几台虚拟机搭建一个业务系统的群集。

        4.到了2021年开始，特别是互联网公司（阿里、京东等）和金融业（银行）以及头部制造业（新能源汽车、高新技术的等）等对于业务系统有弹性扩容、业务连续性、高可用性基础需求的前提下，对于业务系统的敏捷开发、快速迭代、快速部署、边缘计算场景，希望在对业务系统不管是边缘服务（如产品详情）或者核心服务（支付系统）、进行开发和迭代时保证业务系统的健壮性。

        5.促使基础架构的迭代以及业务系统进行微服务化改造，才能满足需求。

        6.当业务系统进行微服务化之后，问题来了。理想中的微服务一个业务系统几个或者十个微服务，但实际上是成千上万个，非常具体。那么此时基础架构为虚拟化是满足不了需求的，因为虚拟化后的OS的开销以及性能的开销是没办法避免的,同时代码基础设施的一致性，业务系统版本迭代和回滚等业务场景，能满足需求的基础架构目前只有容器底座，也就是云原生的标准-k8s.

        7.当基础架构迭代到k8s后，微服务化后的容器业务系统可以避免OS的开销以及性能的开销，同时保障代码基础设施的一致性，此时还需要解决一系列问题：

                1.业务系统的CI/CD流水线---解决需求快速迭代和快速部署。

                2.业务系统的服务治理以及可视化。---解决需求上千上万个服务运维和管理。

                3.微服务化后的业务系统的服务网格改造。----解决需求业务系统使用代码的微服务框架等（如java的Spring Cloud）网络基础设施代码冗余等问题。

                4.在开源当代的时代下，如何选择有技术支持的商业云原生产品，来提供可靠和优秀的技术支持完成上面的任务。

二、从人的层面

        1、工程师在虚拟化时代，具备数据中心的（物理、虚拟化产品）网络、计算、存储等知识和技术储备。

        2、在云原生时代这些iaas层面的知识储备显然是不足够的。

        3、那么从人的层面需要储备什么技能呢？
                1、熟悉容器技术栈----基础架构底层这是必须的，详细点讲就是从docekrfile编写到如何设计编排一个业务系统到k8s上进行部署，都需要了解这是基础。

                2、对于中间件的了解---因为k8s是一个Pass平台，作为基础架构的人员必须要了解你业务系统涉及到的中间件、如nginx、redis、Mysql等基础中间件---这是基础。

                3、CI/CD流水线工具----使用了k8s，那么CI/CD是必备的技能，你可以选择GitOps技术栈，也可以选择其他基于Jenkins技术栈，但一定要会写 流水线。

                4、代码层面-----如果你是一名优秀的顶级云原生架构师，那么对于你业务系统的开发语言框架，java-Spring Cloud，Go等涉及到的微服务框架是需要掌握的，不然你没办法对于开发人员再进行服务网格改造时提供强力而有建设性的支持。

                5、那么上面4点总结起来，新时代的云原生工程师其实就是技术全栈工程师，从上层业务代码到底层基础架构，都需要有涉猎，孰轻孰重是看工程师自身的技能敏感度，基础k8s人员熟练1、2点，优秀的1、2、3点，顶级的1、2、3、4点。

三、对于商业产品的选择层面

        1、首先选择的产品一定是在国内有技术支持的。

                1、基础架构-国外Rancher、红帽、国内DaoCloud、QinCloud等。

                2、CI---Gitlab-仅此一家

                3、CD-----各有所长，可以选择开源的Jenkins或者Fleet.(Fleet由中国Rancher提供技术支持)。

                4、对于业务系统改造---不管是容器化最佳实践改造、微服务改造、服务网格改造，目前最厉害的是红帽。

        2、上面这些产品如何选择优劣？

                1、在虚拟化时代，虚拟化产品的厂商如Vsphere、华为的Fusion Vsphere、H3C的Cas等套件，都是硬件厂商和虚拟化产品厂商进行适配，虚拟化时代这里关注的是物理主机和虚拟化产品的兼容和适配性，此时国外的服务器产品如dell等和国外的Vmware系列产品的兼容和适配度是最高的，国内的是华为自家的虚拟化和自家的服务器适配是最好的其他同理，此时产品选择选型还是用物理服务器为基线。

                2、在云原生时代、因为容器通过NameSpace隔离技术，所有容器共享一个操作系统内核、并且所有网络功能都基于iptables或者ipvs等技术栈来实现、在产品选择上，一定是自家是做操作系统的\那么他的容器底座是最强的且安全的。

                        1.如Rancher被 SUSE收购，------SUSE Linux

                        2.RedHat 的Open Shift.        ------Red Hat Linux

                        3.国内的Open Oula                ------ 目前没有看到他的k8s发行版。

                3.在云原生时代可以这么说，谁家有Linux发行版，谁的k8s发行版就是牛逼的。

四、总结

        1.在企业选择是否要下注迭代基础架构时，请重点关注自身业务系统是否为自研开发，还是采购商业产品。

        2.如果是自研开发，可以让开发人员尝试使用的容器进行开发，享受容器的红利，他会爱上这个开发模式。如果本身就是容器化开发的自研产品，那么此时可以按照1、微服务改造 2、服务网格改造的顺序充分利用好云原生红利，享受云原生动力带来的加速--企业数字化转型。

        3.如果是采购商业产品，那么采购的商业产品是否已经是容器化后的产物，如果是容器化后的产品、让你提供虚拟化来进行部署。此时大量的容器化后的产品在你的虚拟化平台上，你的业务系统的性能天生就损失一个OS和虚拟化层的开销浪费资源、同时极其可能出现一个虚拟化平台，多个k8s集群的情况，此时是很危险的，因为k8s本身是有状态的，关闭和启动都存在顺序，如果顺序不对，k8s的etcd数据库无法完成同步，则k8s集群的pod声明式yml一定有问题。此时传统云平台的运维人员将无法下手，因为他对虚拟机的生命周期管理已经从简单的虚拟机层面被迫放大到了对于业务系统基础架构生命周期的操作。

        4.如果采购商业产品，是容器化后的产品，那么建议尝试采购7台服务器，搭建一个3Master-4-Worker节点，Ingress console 部署在worker nodes上的k8s集群.业务系统生命周期一般为3年，在3年的这个节点上将业务系统新版本直接部署在容器集群上，并且要求之后采购的产品如果是容器化，必须交付到k8s集群上，此时在逐步交付到过程中，让业务逐步迁移到新建设的容器集群上.

        5.以上3、4点需要利用好商业的云原生公司的技术能力，根据自家企业的业务系统和规模建立云原生产品交付流程和标准，最终呈现云原生的产品长在云原生平台上，单体应用部署在虚拟化环境上，不可迁移到云的有状态服务（数据库）部署在物理机上，大家利用好各自平台的红利，为企业提供最可靠和优质的服务。

        5.以上是我的一些思考和分享。