@levelworm #7 这个岗位就专门做这个事的, 应该是各方甩锅妥协的结果

@levelworm #7 对, 这个岗位真的非常蠢

@harlen #1 对, 一般小公司没这岗位

@levelworm #3 我遇到过大公司要求运维去找业务代码的 bug, 业务还很复杂那种, 经常是业务逻辑上出问题, 让运维去找, 非常不合理

确实 uniapp 好些, 都上了 2 个项目

@Gilfoyle26 #1 其他平台小程序优先级倒是不高, 主要是同时要兼顾微信小程序和 H5

挑战就是 Spring 微服务项目突增复杂度, 现在 k8s 一统江湖, 之前学的 Spring 微服务项目技巧又没啥用了

@zhouyin #20 没有 没在一线城市

能有双休已经是很不错了

@nananqujava #17 当时学 java 的时候被 eclipse 和 xml 配置文件恶心的不行, 想着都吐

我大概 26 27 岁开始学从 C#转 java, 当时觉得 C#工作岗位少薪资低, java 有前途, 现在也准备转方向了

openclash 配置让我觉得难受, 还是用 passwall 吧

@HeyCaptainJack #3 这个直接可用

https://gitee.com/zhijiantianya/ruoyi-vue-pro

有小程序端

家电维修行业就是乱的一比, 之前住的地方, 楼下有一个报刊亭有 2 个维修师傅 , 我有一次水管坏了, 师傅上了背着手看了一圈就报价几百块

@ciki #108 是的 我也觉得这个人 @yinmin 疯狂回复一堆, 但基本概念都没搞懂, 哪怕是实操过一次都不会这么发言

还是不能解决断电断网后服务不可用问题, 之前我思考过类似方案, 可以以家庭主机为主, 云主机为辅, 云主机上冷部署一套和家庭主机一样的环境, 轻量云上跑个服务, 监控和观测家庭主机的服务是否在线, 假如家庭主机服务下线超过一定时间, 自动启动云主机的服务并把流量切换到云主机, 家庭主机恢复后,再切换回来, 并且把云主机的服务都下线节约钱

怎么组织 module 到一个项目里可以参考这个项目, https://gitee.com/zhijiantianya/ruoyi-vue-pro

看得有点血压高, 实际上微服务并不是一个良好的架构,微服务也不是高性能的代表, 微服务纯粹增加开发复杂度,增加调试的复杂度
1,开发模块问题 6 楼已经说的很清楚了
2,扩展伸缩是 devops 的范畴, 单体也能方便的横向扩展
3,扩展的实例信号同步通过 redis 实现
4,队列使用基础设施的 mq, 楼上有人说单体不能用 mq 的情况,真的用过 mq 吗
5,有人说单体崩了就全完了, 但举的例子也只是 mq 积压导致服务不可用, 跟单体或者微服务又没关系
6,很多人说的所谓的崩溃,cpu 占用高,内存占用高,跟单体或者微服务真的没关系, 反而是依靠项目整体生命周期里的 devops 架构,运维, 跟 CICD, 测试, 实时观测, 监控关系更大点

42 楼 项目开发上的代码冲突是 git 管理的范畴,分 module 后一般不会遇到冲突. 单体会降低启动时间, 而且在 module 里可以控制启动哪些模块, 关闭哪些模块, 在调试的时候更方便. 拉分支也是 git 的范畴, 跟单体或者微服务也没关系

最后说下 OP 能遇到从微服务回归单体的项目就偷着乐吧, 不然十来个微服务(用户、订单、后台、网关等）你后面加不完的班, 线上出问题调试恶心死你