技术栈一把梭，真的好吗

[fanmouji]

说一下现状：
1.原系统 Java 开发，供内部人员使用，工单模块使用最频繁，并发最多 400，涉及大量导入导出，多表联表统计；偶有支付订单，基本无实时要求。
2.开发 4 人，无技术大佬，开发运维一条龙服务...
3.需求更改频繁，今天一个导出，明天修改流程等等小修改
4.单体项目，部署麻烦。
最近公司高层变动（原领导提桶跑路），新来的领导（非技术）想优化业务（涉及多部门）流程，新的产品经理（有过技术经验）一直提要重构成微服务，拆分用户中心、支付中心、订单中心；分布式、缓存、高并发等等。粗略算了下全公司用户最多 1000，支付单:工单=1:1 也就 1000 多单。
请问这样真的有必要微服务吗？

[Leigg]

如果用 go 的话，推荐一个仓库
https://github.com/chaseSpace/go-kit-examples

[chenqh]

不如先搞一个自动化部署，哈哈

[reus]

当练手，熟悉了就跳槽

[zengming00]

单体项目哪来的部署麻烦，微服务才是真的麻烦，而且不是一般的麻烦

[TypeError]

面向工资 /简历编程

[ReinerShir]

过来人告诉你，就算为了面向面试而使用微服务也没用，面试官会问你，海量大数据处理经验吗？有高并发处理经验吗？有亿级数据架构设计经验吗？ 没有？那不好意思，事实上有几个企业能用上大数据高并发。

[fanmouji]

@chenqh 确实是部署麻烦，在弄自动化部署了...
@ReinerShir 问倒了😂

[Mitt]

虽然现在这个情况可能用不到，但是学了对自己有好处，积累经验，以后用到的时候就很容易上手再搞突破了

[wangritian]

微服务人少不要折腾，但自动化运维任何规模的项目都有用

[hahasong]

微服务已经过时了，现在流行宏服务，中台系统。你可以提议做个中台出来

[eudore]

赞同 6 楼 “不要为了微服务而微服务”

从项目的角度来说，可以正常使用就好，不要为了炫技而使用新技术，你们变化的是领导不是项目场景，是否需要微服务看项目和公司的发展状态，一些再牛逼的东西里面主线程也是一个 for 死循环。

从个人角度来说，那个 pm 很可能是外行(不会写代码),也许微服务了解不深，以前工作是使用的微服务，为了 kpi 之类来搞的，深点的内部竞争的我想不到了(太笨)；公司要是花钱让你玩微服务就弄吧，那一样的钱玩点新东西也不错，也许微服务了还要加人呢，自己还能当个小领导（ 15 楼说每个项目至少 3 人是正确的，最低 2 人维护一个服务，单人维护出现请假离职就凉凉了，你们 4 人玩不来，公司需要打钱加人）。

另外我觉得你们缺乏发布流程，正常应该在固定时间点进行项目发布更新，如果这个功能每赶上这个发布点就下次了。

[piecehealth]

1. 微服务首先解决的是团队 scalability 的问题，4 人团队完全没有此问题。而且单体应用也可以业务解耦，谷歌一下 modular monolith 。
2. 单体应用也有很多自动化部署方案。如果单体应用自动化部署都搞不定，上微服务等于自杀。
3. 开局就微服务还好说，如果把一个已经挺复杂的系统迁移到微服务又是一个复杂度巨大的事情，要是准备干两年跑路可以试试；打算长期干下去就不要给自己挖坑了。

[fanmouji]

@eudore 他前东家是微服务，内部竞争倒是没有，只不过我们一直提的人手不够上面还卡着，真上这个还是累死自己...

[fanmouji]

@piecehealth 是很复杂的系统迁移，其实现在都是各自分模块开发的，公共部分一年都没 3 次修改，各自独立也没啥问题，主要是人不够，还经常加班，心态炸了...

[bleepbloop]

技术选型也听产品经理的，这解释不通吧

[fanmouji]

@bleepbloop 还别说，之前我们一直当他透明的，这次不一样了，万一怂恿上面这样的好处 balabala，还真有可能🌚

[losephsky]

我觉得趁此机会学一把还不赖啊，至少出去找下家简历也很光彩

[EPr2hh6LADQWqRVH]

没运维监控搞微服务不是给自己添乱吗

[liuzhiyong]

个人观点：经过实践检验的代码，尽量少改动。

[asuraa]

我们公司开发 12 个人 运维就我一个人.
三个项目同事搞
我维护 gitlab 和所有项目
于是我上了 k8s 现在闲的天天喝茶