技术栈一把梭，真的好吗

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1547 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

工单

导出

表联表

多单

51 条回复 • 2020-10-05 18:07:40 +08:00

nvkou

2020-10-01 00:32:29 +08:00 via Android

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

tsingke

2020-10-01 00:35:59 +08:00 via iPhone

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

cqxxxxxxx

2020-10-01 00:38:32 +08:00 via Android

同意 2l

des

2020-10-01 01:24:42 +08:00

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

MintZX

2020-10-01 01:45:53 +08:00

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

sheeta

2020-10-01 02:16:33 +08:00

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

Kirsk

2020-10-01 02:29:36 +08:00 via Android

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

fengchang

2020-10-01 03:25:03 +08:00

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

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

felixcode

2020-10-01 03:49:22 +08:00 via Android

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

xuanbg

2020-10-01 03:59:21 +08:00

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

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

xuanbg

2020-10-01 04:08:28 +08:00

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

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

fengchang

2020-10-01 05:01:16 +08:00

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

zjsxwc

2020-10-01 05:55:24 +08:00 via Android

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

maddot

2020-10-01 06:07:38 +08:00 via Android

哈哈，面向简历做项目呗

2020-10-01 06:08:29 +08:00 via iPhone

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

way2explore2

2020-10-01 06:27:31 +08:00

@zjsxwc

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

容易被人滥用的是

refactor - replatform - rehost

fanmouji

2020-10-01 07:15:20 +08:00 via iPhone

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

fanmouji

2020-10-01 07:23:44 +08:00 via iPhone

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

fanmouji

2020-10-01 07:35:44 +08:00 via iPhone

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

shenchao

2020-10-01 08:08:16 +08:00 via Android

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

Leigg

2020-10-01 08:13:07 +08:00 via Android

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

chenqh

2020-10-01 09:38:15 +08:00

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

reus

2020-10-01 09:49:00 +08:00 via Android

当练手，熟悉了就跳槽

zengming00

2020-10-01 10:00:11 +08:00

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

TypeError

2020-10-01 10:01:34 +08:00 via Android

面向工资 /简历编程

ReinerShir

2020-10-01 10:37:04 +08:00

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

fanmouji

2020-10-01 10:54:40 +08:00 via iPhone

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

Mitt

2020-10-01 11:06:14 +08:00 via iPhone

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

wangritian

2020-10-01 12:28:37 +08:00

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

hahasong

2020-10-01 13:17:43 +08:00

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

eudore

2020-10-01 13:40:07 +08:00

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

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

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

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

piecehealth

2020-10-01 14:25:26 +08:00

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

fanmouji

2020-10-01 14:57:10 +08:00 via iPhone

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

fanmouji

2020-10-01 15:01:02 +08:00 via iPhone

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