专业网站建设哪家权威,医院网站建设投标书,网站开发有哪些流程图,广西梧州为什么不能去一、背景 1.从物理机到虚拟化再到现在的云原生。推动基础架构革新的主要源头就是业务应用。 2.为了解决业务系统的弹性扩容、业务连续性、高可用性加速催生了云时代的快速迭代。 3.虚拟化时代业务系统无非从物理机迁移到虚拟化环境进行部署#xff0c;享受到了基础架构迭代到云…一、背景 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 CloudGo等涉及到的微服务框架是需要掌握的不然你没办法对于开发人员再进行服务网格改造时提供强力而有建设性的支持。 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.以上是我的一些思考和分享。