随着国内一些超级云服务商频繁出现故障,比如XX施工挖断光纤、XX变更导致全局无法订购退订、XX在促销日出现问题......应用上云了,就高枕无忧了吗?并不是。
云原生应用的构建不仅仅需要有云的存在,还要选择好云产品,做好云支撑情况下的架构设计,三者缺一不可,而在广义上来讲,云原生应用则是通过云原生技术构建出的程序叫做云原生应用。这类应用底层基础架构耦合更轻,更易于迁移,更加敏捷。 这是一个应用为中心的时代了。
本文侧重于第三点,即如何构建云IaaS和PaaS平台支撑下的云原生应用自身架构的设计,核心思想有三个。
1、思想1:强调关注点分离
应用和基础资源的解耦
云原生计算加速了应用和基础资源的解耦,充分释放云的弹性;
通过关注点分离,让开发者关注业务价值,而复杂性下沉到基础设施;
对于企业的开发者以及业务团队来说都是一种极大地利好。
是对开发者和业务开发团队的强有力赋能:
(1)对于开发者来说:
通过容器技术,更加容易获取环境和资源,应用更容易部署和应用管理;
应用开发团队之间的技术壁垒消失了,方便与灵活调配人力资源。
(2)对于业务团队来说:
基于云的敏捷交付模式,业务需求更快响应与实现,从需求到变现的时间被缩短;
云原生提供的弹性扩展支持,实现产品可平滑度过突发流量峰值。
思想2:强调应用可观测性
跟踪:了解应用系统的内部运转、依赖关系
指标:设定合理的指标体系,掌握各个层面上所需要了解的讯息(业务指标订单下降:boss关注;应用指标响应时间:开发者关注;错误率指标:运维关注)
日志:一方面通过日志来实现跟踪,另一方面通过日志服务于运营团队,因为推广活动的日日就是一种间接价值;
应用可观测性解决的问题:
(1)调用关系可视化—可见:掌握全貌,心中不慌;
(2)及时发现问题,预警问题—可知:有了错误,有了变化,我可以即使知道,便于开展应对;
(3)判断问题根本原因—可解:知道问题发生,还知道为什么发生,便于根治问题;
(4)利用数据的特异性变化调整业务—可为:通过及时掌握指标参数的变化,可以通过弹性调度平台去实现及时的业务扩容。
思想3:强调面向失败的设计
正像我前面所说,应用上了云了是不是就意味着不出问题了呢?
其实原本可能遇到的问题,到了云上依旧存在,提倡云原生应用提倡开发者善于利用云上的相应能力帮助应用减少失败。
云平台提供了开箱即用的能力,专注应用层面整合即可,如下几点当然需要和云配合起来。
(1)预防失败 - 自我保护
(2)失败不可预知 - 监控体系
(3)容忍失败 – 冗余设计
(4)快速解决失败 - 自动化运维
思想4:强调应用轻量化
实现全面轻量化:
(1)应用运行态的轻量化:微服务将举行服务拆解为多个灵活的小服务;
(2)程序包轻量化:非功能需求逐渐通过云实现,API/sdk替换上万行代码;同时函数计算等技术出现, 进一步释放应用,应用的本质变成了“函数代码段”,那么需求到达上线生效的周期大大缩短了,要不断提升精细化发布;
(3)包传输与部署的轻量化:容器镜像替代传统安装包;举例需要传输多个安装包包括编译文件、配置文件、自动化脚本/探针、web服务器(一个tomcat也挺大的),管理如此复杂的东西成本挺高的,也容易出错,现在不需要了,有了dockerfile了,在目的端直接一个docker build就解决了,很容易。对于跨机器的部署也有移植性,不需要每台服务器做不同的改动。
(4) 微服务框架轻量化:Quarkus、Helidon等微服务,启动速度更快,占内存更小。其中Quarkus的启动时间更短,ms级别
引申介绍下:
与Quarkus同级的技术体系:
Spring Reactive → 背靠 Pivotal → 归属 VMware → 归属戴尔
Quarkus 和 Vert.x → 背靠 Eclipse 基金会 → 主要由 Red Hat 支持
Helidon → 背靠 Oracle
Micronaut → 背靠 Object Computing(Grails、OpenDDS)
Lagom → 背靠 Lightbend(Akka)
native-image
(1)超快启动时间、超低内存占用 (2)无缝集成docker容器化平台 (3)统一命令式与反应式编程模型 (4)50多个库的支持
如今云计算的发展热点以经验进到边缘计算、云原生和算力网络时代了,应用的自身架构设计也应该不断创新和演进。
以上纯属个人意见,仅供参考。
————————————————
版权声明:本文为CSDN博主「Cloud云卷云舒」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:
https://blog.csdn.net/bishenghua/article/details/134822804