云原生不可变基础设施
发布时间：2022-07-14 10:39:08 所属栏目：云计算 来源：互联网
导读：01什么是不可变基础设施？如何理解？ 熟悉云原生的小伙伴们都知道，云原生目前具有五大代表性的技术，它们分别是：容器、服务网格、微服务、不可变基础设施、声明式API。其中，不可变基础设施相比于其他四种概念难理解一些。 网上对于不可变基础设施的定义有
|
01什么是不可变基础设施？如何理解？ 熟悉云原生的小伙伴们都知道，云原生目前具有五大代表性的技术，它们分别是：容器、服务网格、微服务、不可变基础设施、声明式API。其中，不可变基础设施相比于其他四种概念难理解一些。 网上对于不可变基础设施的定义有很多，此处给大家展示一个比较有代表性的描述： Immutable infrastructure refers to servers(or VMs) that are never modified after deployment. 生活中，不可变基础设施的例子比比皆是，我们以“水”为例来谈一谈不可变基础设施和其对应的可变基础设施： 现实生活中，如果我们生活在农村或者比较落后的山区，水资源的获取对于我们来说是相对比较困难的，在使用水资源时会比较珍惜，会存在这种水资源使用方式：淘米水用好之后可能会用来洗菜、洗菜后的水会用来洗拖把、洗拖把后的水再用来冲马桶，这种水资源的利用被视为可变的基础设施；生活在城市的时候，水是作为一种不可变基础设施来使用的，我们打开水龙头后，用过的水直接进入了下水道，这种水资源的使用是没有进行复用的。 从现实回到代码，其实在代码中我们也是存在很多不可变基础设施和可变基础设施的思考： 图片 图1 开发人员在编码时也会存在不可变基础设施的场景，java、c++等语言都提供一种能力让变量变成不可修改，包括传参的时候，如果进行限制后，对该变量进行修改会出现编译报错，如果要实现不可变数据的修改，需要通过再申明一个变量等方式去支持不可变数据的修改，有开发经验的开发人员知道不可变数据让代码逻辑更加清晰，减少错误，同时让并发变得更加简单。并发编程时如果让一个变量申明为只读类型的，对其进行并发修改时不需要加锁进行控制，这就是不可变性在并发中的思考。 其实“不可变基础设施”这个名词最早出现在2013年，随后，Docker带来的“容器时代”和k8s引领的“云原生时代”让不可变基础设施这个理念越来越流行。常见的服务器、虚拟机、容器都称为基础设施。 02不可变基础设施的优势特点有哪些？怎么改造？ 大家熟知，云计算的出现是降低了环境标准化的成本，但业务的交付成本依然很高。 云原生技术架构展示如下： 图片 图2 不可变基础设施与之对应的是可变基础设施，在传统开发中，软件开发完成后需要部署到服务器上进行测试或者正式部署等，开发或者运维人员需要通过客户端连接到服务器端进行一些安装部署等工作，并且如果考虑多节点服务器部署的话，涉及到对应的配置项（比如环境变量等）需要对每个节点逐个进行配置参数修改，如果后续升级等还需要对每一个节点环境进行修改，比如电商那种更新迭代比较频繁的话，这些环境经历的一些操作很少能完全理清，后续的变更会经常遇到各种诡异的问题，基础设施变得很脆弱、敏感，一些比较小的变动就会引发不可预知的结果，这是一件非常头疼的事情，排查问题需要很丰富的技术积累，同时耗费的时间也会很长。 从开发者角度来看，不可变基础设施在时间和空间的一致性是非常棒的，特别是在排查业务侧问题的时候。对于时间的理解，如果应用部署在某一个服务器上面的时候，运行了一段时间（比如100天），服务器的状态还是一模一样的，这就能在很大程度上保证排查问题的效率；空间上，应用不管部署在研发区还是测试域、部署在linux还是windows，空间上也能做到一致。 可变基础设施常见问题： 服务频繁持续的变更会给服务运行引入很多中间态，从而导致软件熵的增加，不可知风险增加； 故障出现时，很难快速构建出新的服务副本，依赖于部署时的高可用节点； 很难标准化，交付运维过程异常痛苦，虽然可以通过 Ansible、Puppet 等部署工具进行交付，但是也很难保证对底层各种异构的环境支持得很好，还有随时会出现的版本漂移问题。比如你可能经常遇到的，某个软件包几个月之前安装还能够正常运行，现在到一个新环境安装后，竟然无法正常工作了。 不可变基础设施是另外一个思路，部署之后即是只读状态，不可对其进行修改，如果需要更新或修改，则使用新的环境或服务器去替代旧的。不可变基础设施可以避免可变基础设施中遇到的各种常见问题。 不可变基础设施的特点 一致性 一致性是最明显的一个特征，不可变基础设施保持一致，同样的版本，同样的配置，和管理相同机器一样管理很大规模的集群； 简单 所有机器和实例都是一样，只有扩容和销毁两个状态，所有系统只要处理这两个状态就可以； 安全 所有实例扩容之后不会变，扩容之前可以对其进行充分的测试，安全人员可以对代码进行扫描，保证应用实例相关的数据都是经过测试安全的。 ❖ 传统应用如何适配不可变基础设施，需要做哪些改造呢？ 将传统应用的运行环境打造成一个具体的服务器，比如虚拟机镜像、容器镜像，程序即可run起来； 应用run起来之后会存在各种各样的输出，分析应用程序的输出类型，使其能够和服务器无关； ⚠ 注：与服务器无关的含义 将依赖于本地的缓存转移到分布式存储中； 将依赖于本地存储的文件转移到分布式存储中，从而不会受到本地服务器重启丢失之类的影响； 将依赖于本地存储的日志信息转移到标准输出中，由日志采集的side-car收集后统一汇总。 实际工作中，对于不可变设施的完全落地还是比较难的，可以做一些权衡： 如果日志不允许落盘对部分程序改造成本很高，可以使用ELK或EFK等技术做好实时的同步，保证日志可丢失； 如果完全依赖分布式缓存对性能压力过大，那么就建立一套分布式缓存与本地缓存的自动同步机制，保证重启后本地缓存丢失仍然可以修复； 综上所述，只要保证应用在基础设施上产生的数据可以在任意时刻丢失，就可以实现一定程度上应用无状态化，也能保证不可变基础设施落地。不可变基础设施是一种理念，具体落地还是比较依赖于容器或虚拟机的，以及还需要分布式存储等配套设施，不是按照一种技术标准去执行，应该综合分析现状，选择性地朝这个方向优化。不可变基础设施存在优势和劣势，在云原生场景下，优势是大于劣势的，分析如下： 云原生的不可变基础设施以容器镜像为标准，其中不但包含了二进制内容，还包含了程序运行需要的依赖环境、基础库、系统环境等，相对来说比较完整。 能提升应用交付效率，基于不可变基础设施的应用交付，可以由代码或编排模板来设定，这样就可以使用GIt等控制工具来管理应用和维护环境，基础设施环境一致性能保证应用在开发测试环境、预发布环境和线上生产环境运行表现一致，不会频繁出现开发测试时正常、发布后出现故障等情况。 能快速、可靠地水平扩展，基于不可变基础设施的配置模板，可以快速创建与已有基础设施环境一致性的新基础设施环境。 能保证基础设施的快速更新和回滚，基于同一套基础设施模板，若环境被修改，则可以快速进行回滚和恢复，如果需要对所有环境进行更新升级，则只需要更新基础设施模板并创建新环境，将旧环境进行替换。图片 （编辑：上饶站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
