这是一个创建于 1836 天前的主题，其中的信息可能已经有所发展或是发生改变。
说一下现状：
1.原系统 Java 开发，供内部人员使用，工单模块使用最频繁，并发最多 400，涉及大量导入导出，多表联表统计；偶有支付订单，基本无实时要求。
2.开发 4 人，无技术大佬，开发运维一条龙服务...
3.需求更改频繁，今天一个导出，明天修改流程等等小修改
4.单体项目，部署麻烦。
最近公司高层变动（原领导提桶跑路），新来的领导（非技术）想优化业务（涉及多部门）流程，新的产品经理（有过技术经验）一直提要重构成微服务，拆分用户中心、支付中心、订单中心；分布式、缓存、高并发等等。粗略算了下全公司用户最多 1000，支付单:工单=1:1 也就 1000 多单。
请问这样真的有必要微服务吗？
1.原系统 Java 开发，供内部人员使用，工单模块使用最频繁，并发最多 400，涉及大量导入导出，多表联表统计；偶有支付订单，基本无实时要求。
2.开发 4 人，无技术大佬，开发运维一条龙服务...
3.需求更改频繁，今天一个导出，明天修改流程等等小修改
4.单体项目，部署麻烦。
最近公司高层变动（原领导提桶跑路），新来的领导（非技术）想优化业务（涉及多部门）流程，新的产品经理（有过技术经验）一直提要重构成微服务，拆分用户中心、支付中心、订单中心；分布式、缓存、高并发等等。粗略算了下全公司用户最多 1000，支付单:工单=1:1 也就 1000 多单。
请问这样真的有必要微服务吗？
 | 1 nvkou 2020-10-01 00:32:29 +08:00 via Android 如果业务成增长态势的话判断也没错，战未来嘛。 |
 | 2 tsingke 2020-10-01 00:35:59 +08:00 via iPhone  17 公司发工资让你学技术 何乐不为呢？跟上主流技术本身对公司可能不是刚需 但是对技术人来说是刚需。所以爽快的干吧。 |
 | 3 cqxxxxxxx 2020-10-01 00:38:32 +08:00 via Android 同意 2l |
 | 6 sheeta 2020-10-01 02:16:33 +08:00 1 不要为了微服务而微服务... |
 | 7 Kirsk 2020-10-01 02:29:36 +08:00 via Android 你叫他来搭分布式系统 看他还比比不 高并发？号召员工一起点吗 |
 | 8 fengchang 2020-10-01 03:25:03 +08:00 3 康威定律："设计系统的架构受制于产生这些设计的组织的沟通结构。" 四个人的团队不需要搞微服务。 |
 | 9 felixcode 2020-10-01 03:49:22 +08:00 via Android 跑两个容器，跑一下压测，就能把微服务和百万并发写到领导年终总结里去了 |
 | 10 xuanbg 2020-10-01 03:59:21 +08:00 微服务有必要。对付这种需求变更频繁，业务组成复杂的情况，微服务就是最好的解决方案了。但搞微服务，你们要先搞定 devops，要对 ddd 有所理解，然后才能成。 至于高并发，你当他是买一送一的就行了。事实上微服务本身就是个分布式系统。搞定高并发，就是多部署几个实例的事。钱能直接解决的问题也就不是问题了。。。 |
| 11 xuanbg 2020-10-01 04:08:28 +08:00 @fengchang 我一个人开发也搞微服务。只需要写业务模块的代码就搞定整个项目，完全不需要关心那些和业务无关的功能，包括但不限于：用户、组织机构、权限、账务、支付、字典、报表模板、短信、邮件、消息通知、失败重试等等…… 微服务属于那种一次投入终身受益的事。既然已经投入过了，我何苦不接受这个好处非得每个项目自己搞一套呢？用一套现成的他不香吗？ |
 | 13 zjsxwc 2020-10-01 05:55:24 +08:00 via Android 先定义什么是重构。 老是有人把重写当重构来说，产品经理等外行这么说也就罢了，程序员也这么说就不应该了，建议看 Martin 的书。 |
 | 3 哈哈，面向简历做项目呗 |
 | 15 wd 2020-10-01 06:08:29 +08:00 via iPhone 微服务的意思是 每个服务至少需要三个人维护 你们总共四个 拆了之后也还是这么几个人搞 那肯定只会更累 |
 | 16 way2explore2 2020-10-01 06:27:31 +08:00 |
 | 17 fanmouji OP @tsingke 这个确实很好，还能丰富简历。但是人手不足，每个人都太累了，前领导就是因为薪资问题提桶跑路的 |
| 18 fanmouji OP @Kirsk 搭不出来的，就像领导去听完某些讲座，回来就说“我们是不是也可以搞一个？”，大概就是别人有的，我也想有... |
 | 20 shenchao 2020-10-01 08:08:16 +08:00 via Android 1 重构下挺好，总结经验好机会。对技术部门也好，代码清晰部署方便，高可用性也可以上来。领导也好，组建正规化技术团队，团队可以稍微大点。 对公司也好。周边一千多人需要用系统工作。公司规模也不会太小，4 个人的开发运维团队明显服务不了这么大的公司。IT 系统还有很大优化空间。 |
 | 21 Leigg 2020-10-01 08:13:07 +08:00 via Android 如果用 go 的话，推荐一个仓库 https://github.com/chaseSpace/go-kit-examples |
 | 22 chenqh 2020-10-01 09:38:15 +08:00 不如先搞一个自动化部署，哈哈 |
 | 23 reus 2020-10-01 09:49:00 +08:00 via Android 当练手，熟悉了就跳槽 |
 | 24 zengming00 2020-10-01 10:00:11 +08:00 单体项目哪来的部署麻烦，微服务才是真的麻烦，而且不是一般的麻烦 |
 | 25 TypeError 2020-10-01 10:01:34 +08:00 via Android 面向工资 /简历编程 |
 | 26 ReinerShir 2020-10-01 10:37:04 +08:00 过来人告诉你，就算为了面向面试而使用微服务也没用，面试官会问你，海量大数据处理经验吗？有高并发处理经验吗？有亿级数据架构设计经验吗？ 没有？那不好意思，事实上有几个企业能用上大数据高并发。 |
| 27 fanmouji OP |
 | 28 Mitt 2020-10-01 11:06:14 +08:00 via iPhone 1 虽然现在这个情况可能用不到，但是学了对自己有好处，积累经验，以后用到的时候就很容易上手再搞突破了 |
 | 29 wangritian 2020-10-01 12:28:37 +08:00 微服务人少不要折腾，但自动化运维任何规模的项目都有用 |
 | 30 hahasong 2020-10-01 13:17:43 +08:00 微服务已经过时了，现在流行宏服务，中台系统。你可以提议做个中台出来 |
 | 31 eudore 2020-10-01 13:40:07 +08:00 1 赞同 6 楼 “不要为了微服务而微服务” 从项目的角度来说，可以正常使用就好，不要为了炫技而使用新技术，你们变化的是领导不是项目场景，是否需要微服务看项目和公司的发展状态，一些再牛逼的东西里面主线程也是一个 for 死循环。 从个人角度来说，那个 pm 很可能是外行(不会写代码),也许微服务了解不深，以前工作是使用的微服务，为了 kpi 之类来搞的，深点的内部竞争的我想不到了(太笨)；公司要是花钱让你玩微服务就弄吧，那一样的钱玩点新东西也不错，也许微服务了还要加人呢，自己还能当个小领导（ 15 楼说每个项目至少 3 人是正确的，最低 2 人维护一个服务，单人维护出现请假离职就凉凉了，你们 4 人玩不来，公司需要打钱加人）。 另外我觉得你们缺乏发布流程，正常应该在固定时间点进行项目发布更新，如果这个功能每赶上这个发布点就下次了。 |
 | 32 piecehealth 2020-10-01 14:25:26 +08:00 1. 微服务首先解决的是团队 scalability 的问题，4 人团队完全没有此问题。而且单体应用也可以业务解耦，谷歌一下 modular monolith 。 2. 单体应用也有很多自动化部署方案。如果单体应用自动化部署都搞不定，上微服务等于自杀。 3. 开局就微服务还好说，如果把一个已经挺复杂的系统迁移到微服务又是一个复杂度巨大的事情，要是准备干两年跑路可以试试；打算长期干下去就不要给自己挖坑了。 |
| 33 fanmouji OP @eudore 他前东家是微服务，内部竞争倒是没有，只不过我们一直提的人手不够上面还卡着，真上这个还是累死自己... |
| 34 fanmouji OP @piecehealth 是很复杂的系统迁移，其实现在都是各自分模块开发的，公共部分一年都没 3 次修改，各自独立也没啥问题，主要是人不够，还经常加班，心态炸了... |
 | 35 bleepbloop 2020-10-01 15:42:25 +08:00 技术选型也听产品经理的，这解释不通吧 |
| 36 fanmouji OP @bleepbloop 还别说，之前我们一直当他透明的，这次不一样了，万一怂恿上面这样的好处 balabala，还真有可能 |
 | 37 losephsky 2020-10-01 17:41:35 +08:00 我觉得趁此机会学一把还不赖啊，至少出去找下家简历也很光彩 |
 | 38 EPr2hh6LADQWqRVH 2020-10-01 18:40:37 +08:00 via Android 没运维监控搞微服务不是给自己添乱吗 |
 | 39 liuzhiyong 2020-10-01 21:13:47 +08:00 个人观点：经过实践检验的代码，尽量少改动。 |
 | 40 asuraa 2020-10-01 21:16:53 +08:00 1 我们公司开发 12 个人 运维就我一个人. 三个项目同事搞 我维护 gitlab 和所有项目 于是我上了 k8s 现在闲的天天喝茶 |
 | 41 kangsheng9527 2020-10-01 22:49:28 +08:00 趁年轻 ，练练！ 任何时候把自己公司当成宇宙第一强企业来做，都是好事。 |
 | 42 lewis89 2020-10-02 05:58:12 +08:00 公司发钱让你们追技术主流，这么好的事情，你都拒绝？ are you kidding me ? |
 | 43 cmqwan 2020-10-02 06:42:24 +08:00 via iPhone 1000 人，并发有 400 呢 |
 | 44 bambo 2020-10-02 07:52:06 +08:00 好吧，只是不知道你们用的是不是 maven，如果是，我那个工具，帮你们分分钟解决。 t/712080#reply7 |
 | 45 notejava 2020-10-02 10:34:17 +08:00 杀鸡用牛刀？ |
 | 46 shroxd 2020-10-02 14:14:28 +08:00 公司领导需要重构项目才能升职， 程序员需要重构项目才能学习新技术。所以说这算是个双赢，何乐而不为呢？ |
 | 49 itmyhome126 2020-10-03 08:50:30 +08:00 你确定有并发 400 ？ |
 | 50 matatabi 2020-10-03 15:50:13 +08:00 via iPhone 并发 400 挺多，微服务走起 |
Select Language