Java 后端如何发展

[donggua997]

个人情况：
4 年经验 java 后端。现在新公司给我分的组，是（一群 java 后端）做运维开发，devOps 的一切东西，天天 shell 脚本，配置 jenkins ，ci/cd ，安装，部署之类的

不爽的感受：
1.全是杂活，2.这属于从开发转运维开发了，不太对劲吧（正常不是开发->大牛、架构。运维->运开）。3.比另外的 java 后端业务组，事多，更忙

表达感受：
所以昨天跟领导说了，想换回正常 java 后端组。但是他也说了：“java 后端业务组，就是 crud 没啥含金量，在之前组能直接接触技术，而不是业务，能了解中间件原理、devOps 的思想等”。他说因为我说发展方向是架构师，才给我分的运维组，他表示 高级运维工程师==架构师， 难道和我理解的架构师不一样，我认知的架构师是：设计项目的模块，该用什么框架，中间件选型等
我坚持这种工作很烦，如果能选的话，还是做之前的 java 后端吧，最后他同意了，给我换组。

还是迷茫：
做业务开发，很多公司的业务对自己发展也没啥用，技术上就 crud 为主，但是也不能一直做后端 crud ，该怎么往上走走呢，架构师是什么，需要什么能力，其他的就是管理吗，干点什么能提升核心竞争力，才能不至于年纪大被淘汰呢

最后想确定一下选择，
业务开发组：因为是在实验室上班，业务是交叉学科，外面企业根本没有这个业务。

原来的组：（基础环境组）
涉及后端开发，主要就是 devops

这样看来是不是原来的组更好点呀

[tulongtou]

vert.x/spring/tomcat/netty/rocketMQ 这些全是 Java 的，都比 curd 有技术含量

[donggua997]

@tulongtou 但是进不去那么牛的公司的情况下，这哪里有机会自己去写 spring 框架，去写 mq 啊，都是拿来直接用啊

[ufan0]

去了那么牛的公司也很难机会写的，进了公司还得看部门呢，不同部门之间的要求与水平可以说是天壤之别。

去过国内某厂数据库研发玩过几个月，部门 90%以上的人要么空降挖来要么校招生培养，可以说没有社招。

国内这个环境永远不缺人，得清晰得明白自己会技术是为了干什么，为了生存嘛。

多看看书玩玩 demo 就超过绝大部分人了。

话说回来，这一行在国内，有基础技术含量的岗位，从这个人刚毕业就决定了他能不能做了。

[donggua997]

@ufan0 扎心了 知足常乐，混口饭吃

[isno]

现在中间件、业务框架已经非常成熟了， 纯做这些研究比较“虚”，容易被业务线抵触。

架构师需要什么能力？这个要结合公司、业务的需要去定义，业务初期就搞 CI/CD ， 业务中期了搞弹性计算、云原生...

架构师的能力：打好 网络、linux 基础知识就好啦， 现在流行的 Istio 、docker 不都是基于 netfilter 、cgroup 这些基础技术搞的么？

最主要的架构师要分析各类技术瓶颈所在，并带头解决，切勿只说不做，成为”口嗨架构师“。

[FstarKing]

你这比我好多了，我也是 Java 后端，但是我已经快两年没怎么写代码了，天天搞商务搞项目搞产品，天天写方案写可研写材料，我特别羡慕公司只写 CURD 的同事。

[donggua997]

@isno 这样说的话 架构师和 运维开发工程师 确实很像了啊。ci/cd k8s docker

[donggua997]

@FstarKing 之前我还觉得多学学是好事，现在觉得工作还是清闲的好，时薪高，如果想提升自己能有更多的时间。 尽量避免浪费时间精力做重复的事

[FstarKing]

@donggua997 对啊，我们公司那些搞 CURD 的，真的很闲，随时都可以带薪学习

[honamx]

去哪里都是写业务

[listkun]

研发效能吧

[hyperdak288]

devops 有很多能干的呀，比如楼上以为同学提的研发效能

基础架构部平时的工作很像运维，因为大部分 cloud 基础组件都是现成的

如果你感觉杂活多，推荐看一下 google 的《 sre 工作手册》减少琐事来提升自己

我目前的 title 就是架构师，以前在业务系统，现在负责部门研发提效，不负责具体的业务系统了。

最近一个 q 干的事是把整体硬件成本降低了 400w,这个过程有很多手段来优化成本，这些手段又会和技术强相关

[hyperdak288]

贴一段《凤凰架构》里面的话，让你大概能明白各个组的职责和能力区别：

举个具体例子，用 Kubernetes 部署一套 Spring Cloud 版的 Fenix's Bookstore ，你需要分别部署一个到多个的配置中心、注册中心、服务网关、安全认证、用户服务、商品服务、交易服务，对每个微服务都配置好相应的 Kubernetes 工作负载与服务访问，为每一个微服务的 Deployment 、ConfigMap 、StatefulSet 、HPA 、Service 、ServiceAccount 、Ingress 等资源都编写好元数据配置。这个过程最难的地方不仅在于繁琐，还在于要写出合适的元数据描述文件，既需要懂的开发（网关中服务调用关系、使用容器的镜像版本、运行依赖的环境变量这些参数等等，只有开发最清楚），又需要懂运维（要部署多少个服务，配置何种扩容缩容策略、数据库的密钥文件地址等等，只有运维最清楚），有时候还需要懂平台（需要什么的调度策略，如何管理集群资源，通常只有平台组、中间件组或者核心系统组的同学才会关心），一般企业根本找不到合适的角色来为它管理、部署和维护应用。


这里面涉及了 开发、运维、核心系统 /中间组 三种角色

[hyperdak288]

https://cloud.google.com/architecture/devops 从这里面能找到很多 devops 能干的事

[superliy]

@FstarKing 兄弟 我羡慕你

[tulongtou]

@donggua997 GitHub 修 bug ，提 pr 啊

[donggua997]

@tulongtou 好建议

[zzzzzzZ]

你领导没坑你，是你格局太低。架构师也是有方向的，更多可以看[https://blog.51cto.com/u_15214399/2820204]

你领导是希望培养你成为 infra 架构师，也就是基础架构。核心技能包含了你看不起的 devOps ，云原生等等。如果不好理解，可以理解你刷的“架构师”和“框架”八股题里面 80%都是 infra 架构师的技能，包括#13 楼提到的那些工作。
流控、RPC 、存储（任何形式）、代理、镜像制品、调度编排、负载、降级与熔断、服务网格、O11Y 、线程等等等等

随便提一些你耳熟能详的东西，都必须得明白原理、会搭会用：
K8S 、GPE 、Istio 、Helm 、Gitlab 、Skywalking 、Seata 、Sentinel 、Nacos/Apollo 、Jenkins 、Harbor 、Nginx 、EFK/ELK 、Maven 、MinIO 、Mongo 、Redis 、MyCat/Sharding 、Arthas 等等。

你领导那句话“能了解中间件原理、devOps 的思想等”你是一点没听进去。csdn 抄答案搭个集群刷点八股题你就懂了？

“该用什么框架，中间件选型”
Nacos 和 Apollo 怎么选怎么搭怎么用？ Zuul 还是 Gateway ？ Hystrix 还是 Envoy ？ Mycat 还是 Sharding ？ Kafka 还是 Pulsar ？ Clickhouse 还是 TDengine ？ Shiro 还是 Security 还是 SA-TOKEN ？ Nacos 还是 Eureka ？上 Nacos 要不要顺道 Sentinel+Gateway ？ SLB 方案？ S3 怎么做？ EFK 来一套？ GPE 上不上？上 OTEL 还是封装 openTracing 协议？什么指标需要预警需要优化？这个服务弹性伸缩怎么配为什么？你这五台机器想跑多少的用户怎么优化？ Apache 顶级项目你知道几个？做一套风控用哪些？做个 IoT 中台用哪些？

你懂个屁的选型，你只知道百度 /csdn 别人用啥你用啥。

安装部署完你不改参数？不了解怎么实现高可用？不配一些东西来做高并发？不追踪指标？不去了解服务的全生命周期？不解决服务故障优化别人代码？
哪怕坚持做 devOps 也能做 TSA ，多理解一点业务也能做 SA ，最有技术的 Infra 都不愿意去搞，眼高手低？

[LemonCoo1]

非常同意楼上老哥的回答，我就不想写 CRUD 了 ，巴不得去搞搞 devops ，结合业务上的流控、异常、监控、告警之类的系统

[HugoChao]

可能有人技术很强，但公司里最牛的一定是懂业务的人
加油，devOps 没什么不好的

[yimiaoxiehou]

同岗位，一边不爽各种运维工作，一边庆幸不用天天 curd

[fiypig]

以后你跳槽到技术负责人，是不是啥都能干，扛得起大旗了是吧

[anviod]

@zzzzzzZ 基础知识掌握的越多,对架构方案越有信心, 储备多了方案可以瞬间组合出一套,很多百度 /谷歌出来的都很有坑,也很片面. 成体系的还是得自己实操才能串联起来.
其实人各有志, 允许人进步,也允许人保持现状, 努力工作就行! 不偷懒不摸鱼就是好青年了!

[dddd1919]

个人理解架构师是能根据业务特点做出合适的可实施架构选型
devops 应该是架构师的必要条件，但也没必要一心都扑到这上面，多了解基础技术并结合解决实际问题
高级运维工程师 == 架构师，不敢苟同

[a62527776a]

别被画大饼了 喜欢干啥就干啥 你自己去面试一下 看看想要做的岗位考察的方向 和自己在做的事情有没有重合

[zhaogaz]

你的思路不太对劲；你领导的思路也不太对劲。。。

做 devops 有 devops 的提升方式；做业务有业务的提升方式。

我举个例子，比方说你做 devops ，深入做下去你会发现很多提升空间，怎么去做维护，怎么去做快速回滚，什么方式升级更安全，怎么做才能辅助其他团队，包括测试各种内容的引入。工具虽然一直在变，但是经验都是一样的。。。

做业务开发我也举个例子，可以尝试成为领域专家，比方说 SSO 领域，大概就要用到这些东西，对标公司就那么几个，业务场景也是随着业务深入的，这是领域部分；还有一个方向是设计部分，设计建模，这才是架构师干的，模块、框架、中间件都不重要。

你的领导大概问题在于，没有说明白工种的好坏，明显是全职 devops 人不够，想把你分过去，但是也没成，估计下一步要拉其他人过去救火了。

你们团队这么分工其实也挺奇怪的，

[zzzzzzZ]

上面那些选型你不能马上想出它们的区别和特性，就不配给人做什么选型。
[https://landscape.cncf.io/guide]这里的基本概念你不明白就不配和人聊什么云原生。
[https://landscape.cncf.io/card-mode?grouping=no&sort=stars]这里的项目你不掌握二三十个你就不会出什么技术方案。
如果你认为上个全家桶+消息队列+缓存这就配做“解决方案架构师”，建议左转[https://github.com/jeecgboot/jeecg-boot]随便弄一套脚手架去 CRUD 。

明白原理之后才刚刚开始

你去调研某个新玩意是不是也得亲自搭一套，然后比较。
选型好之后是不是你得先搭一套，最好再云原生一套好管理+节省资源。这里一堆 devOps 的活运维不会懂的。
基本的企业降本增效得做，公司用多少服务器跑多少服务架构师不知道?上不上 O11Y ？这里又是一堆 devOps 活。
生产事故你怎么恢复？灾备、负载、流控这里还是 devOps 。

你终于都搭好了，安排云原生工程师去做管理，安排 devOps 工程师去指标监控性能优化。infra 架构师
顺道做点代码质量管理静态扫描 CI/CD ？ infra 架构师
是不是先去优化一下数据库，要不要跟服务器打交道？ TSA
改进 kafka 优化一下缓存污染，要不要去机器上看？ TSA
搞活动上负载和流控，怎么做 SLB ，怎么管理机器？解决方案架构师
做个 IoT 中台先调研一波，时序数据库怎么搭怎么配？解决方案架构师

上面的这些优化只是非常少的一部分内容，devOps 和云原生也只是常识，如果你觉得只会 coding 就配做解决方案架构师，那是技术经理。哪个高级开发不懂业务？解决方案就是业务？

再上点硬菜？这里面别人演讲的内容你看得懂几个？[https://giac.msup.com.cn/2022sh/schedule]
[云原生架构][智能运维][低代码][大前端][devOps][业务架构] 这些嘉宾起码一大半都会 devOps 和云原生

[byte10]

上面提到的一些 devops 我都搞过， 对于大多数工具，架构师肯定都要了解和学会使用的。架构师最好还是对基础要掌握，网络，多线程，jvm ，linux 等，然后再就是代码的上的编程思想，再到业务系统的架构，其次就是业务领域的经验了。

个人觉得开窍很重要，参考鬼灭的通透世界。开窍之后就可以看到很多技术上的本质，这样你就不会技术上的疑惑。比如上面说的：《现在流行的 Istio 、docker 不都是基于 netfilter 、cgroup 这些基础技术搞的么？》，又比如一些基础的东西：BASE64 是编码还是加密？ AES 加密后数据会变大吗？不少人不理解基础的东西。

这里的开窍并不完全是说学习方法，而是一种知识的积累+学习方法。比如画画，你画了 1000 次依然不会很大的进步，而是某一次画画突然你开窍了，然后画画的技术就立马上升几个层次。当你达到了 1w 次之后，又可能在某一次画画，或者看别人的画中得到的觉悟，又提升几个层次。

技术开窍之后，很多东西就是直接手到擒来，对知识的理解轻而易举。做任何事都空有成竹，哪怕这个技术不是很熟悉，甚至没接触过。

[donggua997]

@zhaogaz 那如果业务开发组的业务对大多数公司没用或者没有，是不是肯定还是在我之前组更好呀，起码能学到 devops