架构师的独白:微服务架构是这样的...

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 项目和人类一样,总是会死亡的,有时候会突然死亡,有时候回自然死亡;在自然死亡这一边,有的人去世的很早,有的人则寿命很长,长寿的人,通常都是生活更规律的;项目也一样,框架更好的项目活的更久,框架不好的项目,上线同时就死亡了。

框架


项目和人类一样,总是会死亡的,有时候会突然死亡,有时候回自然死亡;在自然死亡这一边,有的人去世的很早,有的人则寿命很长,长寿的人,通常都是生活更规律的;项目也一样,框架更好的项目活的更久,框架不好的项目,上线同时就死亡了。

框架是一种规律,他并不是保证项目成功的基础,他只是让项目存续更久,存续更健康的依赖,他可以让病人在重病时,依靠药物还能简单自理,而不用躺着病床上输液。


微服务框架

微服务本质上是用于拆分业务的,因为业务被拆分成了多个服务,所以,为了保证被拆分的服务的健康,使用请求分流,服务生降低,熔断等技术来维持服务的高可用;因为服务被拆分了,服务日志也跟着被拆分了,所以为了保证异常排查的效率,需要进行日志收集。

框架是架构师的工具,微服务框架也同理,它总归是要服务于项目的,所以。我们在搭建微服务框架的项目时,不用太纠结微服务的概念。比如,你的微服务项目没有做熔断,有人过来说它不是微服务,其实你是不用在意的;作为架构师,你要知道,你是服务于项目的,如果你衡量的人员,进度等一系列客观因素后,判断熔断和升降级可以不做,那就可以不做,保证进度才是第一要务,要相信自己写的框架,即便没有熔断和升降级也可以健康运转好一段时间。但是,如果你做的是微服务开源框架,这些功能就是必须的了,架构师可以不用,但框架不能没有。

64.png

架构师

很多人认为学会微服务了,就可以当架构师了;其实不然,当架构师并不一定要会微服务,同理会微服务也不见得可以当架构师。

其实,微服务的概念并不难,相信很多高级软件工程师只要百度几天,然后消化一个月,基本上都能理解的七七八八。那么,这些高级软件工程师就这样步入架构师了吗?理论上不是,在没有特别详尽的掌握细节之前,我认为都没有架构师的水平,但这并不代表他们做不了架构师的岗位。

程序员有个特点,他们对自己没完全掌握的东西,有着天生的不自信,所以他们在自己未学会架构之前,是不敢应聘架构师的。但有一种高级程序员是不一样的,他们本身就不是特别专研技术,并不致力于提升开发效率,他们相对更擅长沟通和写文档,我把他们称为【没有腿的程序员】。他们对技术没有天然的畏惧,所以他们学习了概念就敢应聘,理解的概念就有了自信。当然了,他们是无法落地的微服务或其他框架的,因为他们没有腿。不过他们善于向老板夸大项目难度,然后招聘很多很多的人员,并且善于用人,他们会把熔断,升降级,日志管理,网关、服务查询等功能分别让普通的程序员来开发,然后出现问题就把问题定义为团队管理问题,然后开始搞devop或其他概念来管理团队。当然,结果通常是需求和代码都乱的像一锅浆糊,这也是祖传代码出现的最基础的原因,因为项目的起手式就乱了,后面自然就是越画越黑。



我有一种与众不同的认知

在招聘网站上,我们经常会看到招聘高级程序员或架构师要求会微服务,但同一城市不同公司给出的工资可能差一倍。仔细阅读招聘需求,我们会发现,其实他们的要求都一样,那为什么工资差距这么大呢?

我是这样理解的,有些公司招聘的就是普通程序员,他们只是未来、可能会用到微服务;有些公司已经在做微服务了,而且大概率已经做的满头包了,所以他们需要招聘一个有经验的高手。

在应聘这样的岗位时,【没有腿的程序员】是领先我们一个身位的,这是为什么你技术已经不错了,却总是应聘架构师失败的原因,因为公司面试过很多人,有一堆【没有腿的程序员】都表现优异,所以公司无论怎么筛选,都不会选择你做架构师。

所以,想做架构师,先包装自己,腿是可以慢慢长出来的,【没有腿的程序员】在架构师的岗位上干一干,如果真把腿长出来了,那他们可就不止领先我们一个身位了;不过通常他们是很难二次发育的。


微服务必死

我们应该都听过做微服务必死,中台必死吧;这是因为微服务项目的失败率非常高。通常人们把它归结于饼大嘴小,累死的;但,其实他们死亡更多的原因是因为使用了不正确的领导;因为微服务虽然很消耗团队,会让小团队疲惫翻倍,但并不是无法做项目的,微服务项目失败率如此之高,跟微服务本身没有必然关系。其实,这样的领导,搞微服务是死,他搞前后端分离也一样能把项目搞死。



结语

框架是死的,人是活的,把项目失败的原因归结于开发模式的,都是学艺不精而已

本文作者:net架构师,全栈.Net软件工程师

声明:本文为 脚本之家专栏作者 投稿,未经允许请勿转载。

相关文章
|
9月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
5月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
338 12
|
9月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
736 70
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
9月前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
2539 36
微服务架构解析:跨越传统架构的技术革命
|
8月前
|
人工智能 安全 Java
微服务引擎 MSE:打造通用的企业级微服务架构
微服务引擎MSE致力于打造通用的企业级微服务架构,涵盖四大核心内容:微服务技术趋势与挑战、MSE应对方案、拥抱开源及最佳实践。MSE通过流量入口、内部流量管理、服务治理等模块,提供高可用、跨语言支持和性能优化。此外,MSE坚持开放,推动云原生与AI融合,助力企业实现无缝迁移和高效运维。
313 1
|
7月前
|
传感器 监控 安全
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
344 0
|
9月前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
244 8
|
10月前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
168 1
|
9月前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
173 0