1.2 为什么要拥抱云原生架构
在引入一项新的技术或者架构升级之前,很重要的一项工作就是明确它的目的性和收益计算。从企业层面收益角度来看,升级云原生架构三个明确目的:降低 IT 资源成本(省钱)、提高运维效率(提高人效)以及架构系统标准化。
1.2.1 降低 IT 资源成本
传统的技术架构一般以虚拟机为基础独自向上构建,单独分配硬件资源,这就造成了资源被大量占用且难以共享的问题。以一台 32 Core 128 Gb 的物理机为例,只能安装 15 ~ 20 个虚拟机。但不可忽略的业务现实情况第一是各个业务负载并不均衡,第二是大部分业务都具有波峰低谷情况,这两种情况就导致服务器利用率并不饱和,资源利用率很难达到有效使用水平。
笔者对某部署在虚拟机中的业务进行分析,从表 1-1 看,高峰 CPU 利用率不到 6%,资源浪费严重。
表 1-1 某业务资源利用率概况
业务 | CPU | 内存 | 磁盘 |
---|---|---|---|
应用系统 | 6% | 53% | 20% |
数据库 | 3% | 60% | 34% |
大数据 | 17% | 70% | 64% |
如果将虚拟机中改造为容器化,一台同样配置的物理机至少可以支持 100 + 容器应用运行,使用率提升 7 ~ 8 倍,相当于节省了 60% 的服务器资源 (更多容器化内容请参阅本书第 7 章)。
更进一步对系统进行优化。可以继续推进系统算力错峰复用能力。例如,离线计算型业务通常在凌晨执行,而此时刻,业务处于低谷阶段,如利用弹性计算对这部分冗余资源进行回收,供非实时计算业务使用,充分复用集群算力,将节省更多服务器资源。
以笔者对某一业务资源进行核算结果为例,如果将传统虚拟机架构升级为弹性伸缩的容器架构,且利用率提升到 30%+,理论可减少 50% 以上的财务支出。
1.2.2 提高运维效率
云原生架构另一个较明显收益是提高工程效率,解放生产力。例如,线上服务遇到突发故障时,效率最高的措施是快速构建一个相同服务的副本替代原本故障的服务。
在传统的架构模式下,新构建一个服务需要环境准备、服务编译、重新部署等前置工作,这至少需要半个小时,很多时候业务高峰流量已过,副本还没有搭建完毕。而在云原生架构模式下,借助 Kubernetes 管理能力以及 CI/CD 体系等,新拉起一组同样的服务到生成环境,最快只需要几分钟(相关实践请参阅本书第 10 章)。
1.2.3 系统标准化
技术架构标准化改进包括基础设施标准化、发布部署标准化、服务治理标准化等。
基础设施不可变及 IaC 标准化 在大规模服务的应用场景中,应用不断地更新迭代,基础架构本身也不断地使用、扩展和移除。云原生架构中引入不可变基础设施理念,通过对基础设施 IaC(Infrastructure as Code,基础设施代码化)改造,对应用开发所依靠的环境进行标准化后,就能够启动、拆解和扩展基础设施,以响应不断波动的需求(基础设施不可变改造请参阅本书第 10 章)。
发布部署标准化 云原生架构下,通过各类技术手段规范 CI/CD 流程、代码分支管理、运行环境标准(测试、开发、生产)等,避免了传统架构下代码分支混乱、环境不一致、上线流程复杂等问题 (CI/CD 实践内容请参阅本书第 10 章)。
服务治理标准化 在传统架构模式下,每个业务团队对于服务治理都要投入一定的人力和资源成本。并且一个企业内不同团队的技术栈以及业务中的超时机制、限流机制、熔断策略等标准参差不齐,云原生架构下 ServiceMesh(服务网格)的出现,使得基础架构人员可以对这部工作收拢,各个业务接入 ServiceMesh 产品后服务治理方面就变得轻量且统一 (关于 ServiceMesh 更多内容请参阅本书第 9 章)。