2022全国新高考I卷作文:《云原生的本手、妙手和俗手》

2022-07-06

44

2022全国新高考I卷高考作文:


云原生

题目要求

根据这个高考作文题,CSDN步尔斯特写了一篇非常有意思的文章,分享给大家:


今天的公交格外拥堵,也许是因为高考吧。


每天回家的路上,总会看一些技术圈的天下大事,刚刚看到一个话题:


Java大军,真的开始把目光从Spring Cloud转向云原生系的k8s + Istio了么?


乍一看,有一丝不解,Java大军?Spring Cloud?Kubernetes?Service Mesh?这四个技术栈放在一起,真的能擦出火花?


此时,一束余辉射在旁边老奶奶那粉嘟嘟的小脸上,我顿悟了,也许提出这个问题的人,本意并不是这样。


他或许是在问“微服务的最佳落地方案?”,亦或是“以Kubernetes为核心的云原生发展趋势?”……


这篇文章就像高考一样,它并不会直接带给你具体的技术知识,但是可能会改变你,成为你的灯塔。


也许你看完没有一丝收获,会骂骂咧咧的走开,但是你不得不承认,当你看到这里的时候,你会有一种想要读完这篇文章的冲动,所以,我尽可能写的简短,不必浪费你太多时间。


不论是云原生还是上述的话题,不得不说到微服务。什么是微服务?把大服务拆成小服务,不就是微服务喽!


微服务肯定是大势所趋了,小而专一,松耦合,语言无关。可问题随之而来,服务治理是个难点:系统复杂性增加、分布式一致性问题、数据一致性问题、服务通信成本增加、服务依赖、性能监控……


本手


所谓本手,便是掌握了事物的发展规律,要顺势而为,要懂规则,且大可不必明理。


以Spring Cloud系列为代表的侵入式微服务解决方案,应该是Java开发者广为熟知的。


云原生


从上图就可以看出Spring Cloud项目是完全可以部署在Kubernetes上的。


侵入式框架是从开发者的角度来衡量的,所以同时会增加开发者的学习成本。


Java web开发从Servlet、SSM、SpringBoot,再到Spring Cloud Netflix和现在的Spring Cloud Alibaba,还有后续的Spring Cloud Kubernetes等,这种变化是与时俱进的。


Spring Cloud 系列和Kubernetes虽然在各自的领域处理的问题不一样,但是他们无疑都是伟大的技术。


云原生时代的这个风口,他们完全可以手牵手乘浪而行。


妙手


何为妙手?妙手便是在正确掌握了规律的基础上充分发挥自己的主观能动性,一鼓作气,再而衰,三而竭,彼竭我盈,故克之。


Service Mesh作为微服务的另一种架构哲学,以Istio作为代表的非侵入式微服务解决方案,目前为止用的企业还蛮多的。


这一类的框架都是基于边车的设计思想(Sidecar),完全松耦合。


云原生


Spring Cloud系列提供了一整套微服务的解决方案,但是Kubernetes都有相对应的替代者,而且是从更高的维度来解决问题,可以说是降维打击。


· 服务注册与发现

· Spring Cloud系列主流的解决方案是Nacos + Spring Cloud Loadbalancer

· Kubernetes提供了Service


· API网关

· Spring Cloud系列主流的解决方案是Spring Cloud Gateway

· Kubernetes提供了Ingress


· 配置中心

· Spring Cloud系列主流的解决方案是Nacos

· Kubernetes提供了ConfigMaps


· 熔断限流

· Spring Cloud系列主流的解决方案是Sentinel

· Kubernetes可以结合ServiceMesh来做


再来看看Istio的亮眼之处:


· 便于流量控制和监测及安全机制

· 与 K8s 完美兼容

· 使用高性能的 Go 语言开发

· 支持多种高级快速的网络协议

· Sidecar 默认 Envoy 并自动注入

· 容错机制完善

· 集成了用于监测的可视化界面

· Jaeger 作为跟踪机制集成

· 具备权限认证功能

· Sidecar 代理具有缓存功能

· 完全免费


由此看来,在云原生的体系中,相对于Kubernetes + Spring Cloud,Kubernetes + Istio的微服务解决方案代表着未来。


俗手


说完了本手和妙手,让我们来说说俗手,俗手乃是忽视了规律,胡乱地发挥主观能动性。


一个月前,我的好朋友狗蛋和我诉苦,说他的领导执意要将微服务架构从Spring Cloud转为Istio,连一个过渡期都没有。


真是绝绝子啊,盲目跟风,难道不考虑一下成本问题?


上述提到的SideCar容器,随着业务越来越复杂,所消耗的资源也越来越大,甚至会超过业务容器。


看过一份数据,对比Spring Cloud,基本每个Pod增加3GB内存,每秒RT增加0.8,CPU增加50%到80%。姑且不说Service Mesh带来的技术复杂度,这数据如果被中小企业的技术总监看了,不得虎躯一震?


非侵入式框架所带来的最大问题就是性能问题,内存、CPU的损耗都是值得深入思考的,盲目的跟随主流,最终只会让自己受苦。


找年轻漂亮的有用么?找到适合自己的才是幸福的真谛。


行云Kubernetes + Istio的微服务解决方案


顺势而为,我想行云正是这么做的。


云原生是大势所趋。当前,以微服务、DevOps、容器、多云业务管理为代表的云原生技术已经广泛成熟应用,成为加速企业数字化业务高效创新、实现企业数字化转型的最佳技术支撑。


行云CloudOS ——“以应用为核心”,提供一站式云原生开发平台,为企业构建敏捷创新的应用研发环境,实现应用研发可视化和敏捷化,实现底层技术平台标准化,让传统应用研发团队零门槛转型为云原生研发团队,支撑传统应用云原生化,加快企业数字化转型。


K8s+Istio解决方案架构图


CloudOS同时也是基于Kubernetes + Istio的微服务解决方案,图形化封装 K8S、Docker 等底层技术,简单易用,降低使用云原生技术门槛。


了解CloudOS (Kubernetes + Istio的微服务解决方案)详情,请点击>

CloudOS在线免费体验>









技术交流
我们建了一个云原生技术交流群,其中有来自Oracle、Citrix、华为、腾讯等国内外云计算专家,立即扫码,拉你进群。目前已有1000+开发者加入我们......
云原生厂商 云原生技术服务商
在云原生时代,行云创新致力于通过赋能开发者,实现企业快速迭代与交付,大幅提升创新效率。
免费试用