技术栈一把梭，真的好吗

[fanmouji]

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

[nvkou]

如果业务成增长态势的话判断也没错，战未来嘛。

[tsingke]

公司发工资让你学技术 何乐不为呢？跟上主流技术本身对公司可能不是刚需 但是对技术人来说是刚需。所以爽快的干吧。

[cqxxxxxxx]

同意 2l

[des]

@tsingke “开发 4 人，无技术大佬，开发运维一条龙服务”

[MintZX]

@tsingke 这就是典型的杀鸡用牛刀，就算你做出来了这么点儿流量，你也不知道你做的对不对啊。

[sheeta]

不要为了微服务而微服务...

[Kirsk]

你叫他来搭分布式系统 看他还比比不 高并发？号召员工一起点吗

[fengchang]

康威定律："设计系统的架构受制于产生这些设计的组织的沟通结构。"

四个人的团队不需要搞微服务。

[felixcode]

跑两个容器，跑一下压测，就能把微服务和百万并发写到领导年终总结里去了

[xuanbg]

微服务有必要。对付这种需求变更频繁，业务组成复杂的情况，微服务就是最好的解决方案了。但搞微服务，你们要先搞定 devops，要对 ddd 有所理解，然后才能成。

至于高并发，你当他是买一送一的就行了。事实上微服务本身就是个分布式系统。搞定高并发，就是多部署几个实例的事。钱能直接解决的问题也就不是问题了。。。

[xuanbg]

@fengchang 我一个人开发也搞微服务。只需要写业务模块的代码就搞定整个项目，完全不需要关心那些和业务无关的功能，包括但不限于：用户、组织机构、权限、账务、支付、字典、报表模板、短信、邮件、消息通知、失败重试等等……

微服务属于那种一次投入终身受益的事。既然已经投入过了，我何苦不接受这个好处非得每个项目自己搞一套呢？用一套现成的他不香吗？

[fengchang]

@xuanbg 看清楚 lz 的需求，他只有一套系统，你在一个系统里写两套用户模块？

[zjsxwc]

先定义什么是重构。
老是有人把重写当重构来说，产品经理等外行这么说也就罢了，程序员也这么说就不应该了，建议看 Martin 的书。

[maddot]

哈哈，面向简历做项目呗

[wd]

微服务的意思是 每个服务至少需要三个人维护 你们总共四个 拆了之后也还是这么几个人搞 那肯定只会更累

[way2explore2]

@zjsxwc

我觉着重写一个函数是一个小小的重构。

容易被人滥用的是

refactor - replatform - rehost

[fanmouji]

@tsingke 这个确实很好，还能丰富简历。但是人手不足，每个人都太累了，前领导就是因为薪资问题提桶跑路的

[fanmouji]

@Kirsk 搭不出来的，就像领导去听完某些讲座，回来就说“我们是不是也可以搞一个？”，大概就是别人有的，我也想有...

[fanmouji]

@xuanbg 微服务确实很好，但是人少没专人专职，太累了，催得又紧...

[shenchao]

重构下挺好，总结经验好机会。对技术部门也好，代码清晰部署方便，高可用性也可以上来。领导也好，组建正规化技术团队，团队可以稍微大点。
对公司也好。周边一千多人需要用系统工作。公司规模也不会太小，4 个人的开发运维团队明显服务不了这么大的公司。IT 系统还有很大优化空间。