@wuling 其实现在很多所谓的微服务, 如果深究都不能算微服务. 最多算分布式架构. 微服务得是拆的非常细的才叫微服务.

@junkk 说明你们的业务不正交.

意思就是每一块业务都是有明确清晰的业务边界的. 不互相影响.
但是这在一些品类的系统中显然是天方夜谭. 业务之间的互相影响如蜘蛛网一般复杂.

这东西就是个投入产出比的问题.
招一个会微服务架构的开发需要多少钱? 我们这儿成都, 招聘一个熟悉微服务架构而且真正有经验的 java 开发工程师, 基本上两万起步. 一般要 2.5W 左右. 其他语言的也差不多. 而没有微服务技能要求的只要 1.5W 左右. 更何况有时候很多自称熟悉微服务架构的都是纸面上的熟悉. 一问啥都知道, 一开始上手做事啥啥都不知道. 上线之后出问题的概率很大的.

另一方面, 大多数项目, 除了天猫商城 京东商城 这种体量规模的产品之外, 大部分项目都不需要考虑什么高并发高可用的问题. 国内大部分互联网公司做的那些玩意都是一套系统平均一天只有几万个 UV 的东西, 弄个好一点儿的服务器啥都解决了.

但是如果用上微服务架构, 那么意味着整个开发团队的人数将会急剧膨胀, 要知道微服务起码要小一百号人才玩儿的转的. 这么庞大的开发团队, 每个人的工资都还不低, 那这个人力成本有没有考虑过? 如果公司本身业务规模就在膨胀的状态, 客户越来越多, 那公司姑且还能愿意花这份冤大头钱去给一帮开发拿自己的业务练手.

但是从新冠疫情开始到现在是个什么情况? 经济持续恶化. 很多公司的业务都已经面临无以为继的状态. 公司为什么还要维持这种庞大的编制? 做慈善么? 而且既然业务的规模都已经没有这么大了, 微服务架构所带来的那些优势自然也就没意义了. 既然用户数量已经变少了, 高并发也就无从谈起. 那为什么不改用成本相对更低, 但是也能达到同样效果的单体架构呢?

而且微服务除了人力成本, 还有各种其他成本. 消息队列(Rabbit, Kafka), MES, 可观测 (Prometheus, Grafana ) 等各种中间件成本都不低.

所以可见的未来, 经济持续下行的情况下, 微服务一定是只集中在少数头部互联网企业的东西, 中小型企业用的一定会越来越少. 前几年有机会入职大厂上车微服务的开发大概是赚到了. 后面一方面大厂门槛越来越高, 另一方面即便是大厂, 用微服务的可能性也在越来越小. 小厂更不会用. 后面的人想学微服务, 恐怕已经没机会了.

这才哪儿到哪... 看看这个. 来, 找找这张截图里有多少种不同风格的 GUI 设计?

https://i.imgur.com/ig33XT8.png

我 .NET 的, 他们讲不限制语言我就把简历投过去了. 结果过了几天给我反馈是公司暂时没有 .NET 的项目. 不招 .NET....

大专行不
会 .NET , 接受转语言行不

多正常. 有好多 CShaper 都是 C/C++ 转过来的, 代码风格里带有强烈的 C/C++ 痕迹. 这都不是最离谱的
最离谱的是我曾经在某公司的代码里看到

``namespace com.xxx.xxx.SomeNameSpace.Xxxx``

这种写法..

见到真是一口老血都喷出来了.

Android 版本呢

@smallbeac008 不一定. 看老板的能力跟人脉了.

成都, 20km. 不堵车的话单程 60 分钟左右. 堵车一个半小时起步.
但是公交车的话 (快速公交) 能好很多. 好多时候, 堵车的情况下私家车动弹不得但是公交车却能顺利的往前走. 到了后面有公交车专用道的地方就更快了.

讲真如果家住市区的前提下, 开车真不如公共交通.

讲真现在外企也得掂量掂量了. 尤其是总部在美国或者主要客户在美国的企业.

现在中国跟美国已经是彻底的敌对关系了, 跟欧洲各国的关系也不好. 这些在华有分支机构跟团队的企业, 说不好什么时候就会因为本国政府或客户要求政治站队而选择裁撤中国的分支机构. 尤其是那些在华没有业务, 但是研发/客服岗位在中国大陆的企业...

@smallbeac008 人家也没说业务需求不是产品经理负责的啊... 人家疑似是除了设计, 整个施工从 css 到数据库都是你的. 但是没说设计也归你管. 这种公司, 大概率就是 老板 = 人事+行政+财务+产品+运营+销售+QA, 开发 = 前端+后端+运维+项目经理+架构师+DevOps. 能不能活下去纯看老板的人脉.

笑死. 10~15... 现在能把 DevOps 搞明白, 能从 css 写到 db 的程序员只能拿 10k 了是吧... 果然西南柬埔寨.

星穹铁道. 不肝, 不吃操作, 剧情好玩角色可爱.

36, 分逼没存, 有点儿钱全还房贷了

而且 @sakishum #23 楼说的对. 以前一直都没啥事, 最近突然找理由开始扣工资绩效的企业 (例如考勤). 基本都是公司资金链非常紧张了. 建议尽早离职, 这种企业用不了多久就会出现拖欠工资的情况了. 到时候你离职又怕拿不到工资, 不离职又一直拖着, 很麻烦的.

视情况.
按国内 99.99% 企业的操性, 这绝不是不合理的. 开发出来的功能没有测试用例, 就靠开发者做完了之后手点, 测试覆盖率能有 60% 都算好的. 这么做无疑是让测试团队凌驾于开发团队头上. 那么开发团队人人自危, 测试团队拿着手里的权限做点什么可就说不好了. 这么搞几天开发团队人心就散了.

但是有些企业, 产品功能模块是有严格的测试用例的. 所以一般提交到测试环境的代码, 基本都是没什么 BUG 的. 有 BUG 要么是单元测试没认真写, 要么是明知 Test Case 有 Failure 还强行提交. 这个扣绩效没啥问题.