技术栈一把梭，真的好吗

• 資深大佬 : 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 系统还有很大优化空间。

• 資深大佬 : 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

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

• 資深大佬 : avastms

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

• 資深大佬 : liuzhiyong

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

• 資深大佬 : luodaoyi

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

• 資深大佬 : kangsheng9527

  趁年轻 ，练练！
  任何时候把自己公司当成宇宙第一强企业来做，都是好事。

• 資深大佬 : lewis89

  公司发钱让你们追技术主流，这么好的事情，你都拒绝？ are you kidding me ?

• 資深大佬 : cmqwan

  1000 人，并发有 400 呢

• 資深大佬 : bambo

  好吧，只是不知道你们用的是不是 maven，如果是，我那个工具，帮你们分分钟解决。
  https://www.v2ex.com/t/712080#reply7

• 資深大佬 : notejava

  杀鸡用牛刀？

• 資深大佬 : shroxd

  公司领导需要重构项目才能升职， 程序员需要重构项目才能学习新技术。所以说这算是个双赢，何乐而不为呢？

• 資深大佬 : kajweb

  @luodaoyi 好了，公司知道你闲了

• 資深大佬 : 594duck

  @fengchang 不搞怎么可以，不搞就不能折腾不能展示自己的才华

• 資深大佬 : itmyhome126

  你确定有并发 400 ？

• 資深大佬 : matatabi

  并发 400 挺多，微服务走起

• 資深大佬 : luodaoyi

  @kajweb 哈哈哈 公司都知道