《云原生的本手、妙手和俗手》——2024全国新高考I卷作文_步尔斯特(1)

APP源码解析

于 2024-04-30 23:49:56 发布

阅读量447

点赞数 29

分类专栏：程序员文章标签：云原生高考

本文链接：https://blog.csdn.net/m0_61331367/article/details/138360026

版权

257 篇文章 0 订阅

订阅专栏

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

本手

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

以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的亮眼之处

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

俗手

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

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

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

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

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

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

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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

关注