十几年不搞 Java ,重新看起了微服务

这事啊，很有感触，也曾经思考过这些问题，无所谓对错，只不过要讲清楚，又要絮絮叨叨很久了。

感觉现在不上 spring cloud 都不是个 Java 项目 。 /

也不能这么说 小团队随便玩 又不是都是大厂有规模的开发团队
自己玩啥都可以

面向简历编程

"后来工作后转行金融证券. 5 年前恢复搞 IT"
发生了什么?

已经放弃 java，实在太庞杂了。
就跟出门买包烟，非得穿个燕尾服才行

本来国内就没什么所谓的技术氛围，大家都在做业务创新。都是在做 CRUD，技术再不紧随国际步伐，颜面何存呢。可能更进一步就是把国外某框架包装一下改个名字。所以无论什么事情上 TM 一套 spring cloud，彰显技术人的水平，存在感十足。

@dog82 这 Java 不背锅，类似出门买烟这种事本就不该用 Java 来做。Java 的定位是开发企业级业务，不是瑞士军刀。

一个人的项目，几百个人的就有必要了

一些人觉得要是不搞出点“花样”，会显得自己很“无能”。明明就是个刚起步的微型或者小型项目，可能连中型项目都不是，非要照着大型、甚至超大型项目的技术栈来，最会大数据、高并发、异步和分布式什么的就都来了。

@casillasyi 关键十个码农九个半是 java 系的，没得选择啊

微服务跟语言没关系的吧。。

1.首先考虑有没有论坛资质吧
2.才几个人的论坛还不如直接 discuz

v2ex 还是用 python 搭的吗？感觉性能一直不错

java 社区就是有这种过度设计氛围，我早早就转了，非常的无趣

选型不当的锅，甩给语言不合适吧。

做这项目个哥们，明显是想攒点经验，其实中小型项目完全用不着这么复杂的框架

小项目，一个人开发，是没啥必要
不过你都这么多年没搞了，不习惯也非常正常

2020 了，还有人觉得微服务没有必要，你可以觉得你的场景太简单没有必要，但是喷这套架构就有点扯淡了
微服务框架，Python/Golang/C++都有，和 Java 没什么关系，只是你看到 Java 有个大一统框架更多人在用而已
当然现在又有很多新的架构出现，估计你们来看的话会批判的一文不值。

拿这个事情批判 Java 的，基本都可以看出来水平比较次。

1. 不同业务之间无缝互相调用
2. 针对不同调用者鉴权
3. 熔断和限流
4. 全链路日志和追踪

只要跨部门或者跨项目，一定会面临第一个需求，你可以上微服务，也可以简单写死 http 请求。但是服务数量一多，写死是不现实的，规模越大，微服务该有的东西越刚需。

在项目 boot 起来之后，微服务那套东西，有没有明显降低业务开发效率？

过去老一代程序员，写个数据库可能都会嫌麻烦，写文件它不简单吗？最早的高校 BBS，不都是 telnet 协议，帖子都自己写文件里吗？那个年代还有嫌弃 IDE 麻烦的，甚至 git 和 svn 也接受不了。而在你们看来，写 db 是跟呼吸一样自然的事情。

现在接受不了 soa，也可以理解，毕竟你只是老了。而 00 后甚至 10 后眼里，soa 和容器都是很自然的事情。

有没有那么一瞬间，网络上的新词你要搜索一下才知道是什么意思？一个大部分 00 后都知道的人名，你要搜一下才知道是谁。

将来，你也会学不会新的高科技产品，就像现在老年人玩不转智能手机那样。

工业级语言。
提供了铁锹和挖掘机，能力是给你了，种个地非得开个挖掘机去也没人拦得住。
个人也是非常不喜欢现在 Java 过度的面向框架编程。

微服务是一种架构思想，跟语言没有关系，spring cloud 是 java 这种语言实现微服务架构最便捷的一种方式，全家桶一套全包，你哪怕不用这些乱七八糟的框架，直接用 http 调用的方式提供服务，也可以搭建成一套符合微服务架构思想的系统出来（本来 spring cloud 也是基于 http 协议，只不过人家提供了微服务周边的一系列工具，比如注册&发现、熔断&限流等）。

如果像你所说的，小 bbs 论坛，功能简单，公司里的人又少，还非得搞微服务拆分，这真的是给自己找事儿干，反之如果一个网站非常庞大复杂，比如一整个淘宝、一整个爱奇艺、一整个抖音、一整个 B 站，它们内部分了很多很多部门，每个部门管自己的事情，有数据平台、中间件、AI 、账号系统、弹幕系统、影视系统、评论系统等等，而且每个部门甚至使用不同的编程语言，这个时候你该怎么协调呢？还是大一统，将所有的项目放到一起，复用的代码搞成 jar 包通用？你会发现如果这样搞，这个项目维护起来会非常痛苦，对测试、开发的效率影响都是巨大的，更何况放一起还有多个人开发同一块内容导致 git 提交冲突的问题。微服务从来不应该是为了炫技而强行使用的东西，而是面对复杂庞大的系统时不得已之下才去用的东西，不然图啥，打个比方：你一个简单的系统，所有的东西搞成一套，事务会非常靠谱，你非要搞成微服务，这样即便俩服务连的是同一套数据源也会有分布式事务问题，何苦呢？

其实小到开发一套框架或者设计一套普通的业务项目，大到一整个架构体系，所围绕的核心无非是：高内聚、低耦合，只不过面对的对象不一样，你拆分产品需求，做业务划分，这是针对产品提出的需求后由工程师们自发抽象，做出的针对业务的高内聚、低耦合（也就是常说的业务拆分和复用），而你用分层和抽象的方式做代码封装，这是作为工程师在实现业务时对代码的高内聚、低耦合，而项目与项目之间按照具体功能方向的划分，又拆出一个个的项目，交给不同的人负责开发和测试工作，这是对整体架构的高内聚、低耦合。它们最终目的一致，只有面向的对象不一致。

跟 Java，微服务这些都没关系。是你接手的项目或者接触的人辣鸡

下回别接这种活儿了，把这个赚钱的机会留给别人

@mitu9527 摆明了就是攒经验跳槽

微服务从麻烦到真香，中间只差几个工具而已。你需要 CI/CD 、自动化的容器化部署、全链路日志追踪、能够进行统一身份认证和鉴权的网关。最好还要有用户管理、权限管理、消息管理、账户管理、统一支付接口等等。当这些都具备的时候，微服务就能够让你专注于业务了，一两天功夫一个业务就简简单单发布上线，真。

其实作为一位正经历微服务改造的人来说， 如果项目不大，程序员数量较少就不要使用微服务框架了。真的是耗时耗力，而且非常影响开发效率。
我建议若是中小型项目并且技术团队成员比较少的情况下, 比起使用微服务而言 还是需要更合理划分不同模块，明确不同人对于不同模块的职责，这样不仅开发效率快而且性能绝对比微服务高(毕竟没有网络调用消耗)。
对于大型、超大型并且那种涉及不同部分技术团队的时候才需要使用到微服务，所以大家还是不要把 微服务当作救命解药了，还是根据自己项目的情况合理提出建议吧。
真的，若非必要 不要上微服务 /(ㄒoㄒ)/~~

不是 springcloud 的锅 是架构手里只有一把锤子看什么都是钉子而已

都十年的老兵了，思想上也没成长多少嘛。大概是一年的经验重复了十年？

微服务不是银弹

@pultako 嗯，明白。拿出各种“词藻”来忽悠，花别人的钱，给自己攒经验，最后项目死了，自己也“风光”的跳槽了。

害 先压测一波看看现在啥效果

开发人员不行不能怪 java 不行，大部分项目都不需要上微服务，单体多模块就够了。前面搞个 nginx 就好罗。

所有吹过微服务的都忘了有一个强大的运维团队在做支撑。只是把研发的事交给运维了…微服务真香定律？把运维团队干掉去，研发自己折腾一遍试试？

@sampeng 微服务还真不需要专职的运维。我们团队也就十来个人，里面还包括了 4 个测试，并没有运维，但我们玩微服务还是很溜。如果没搞微服务，还真的应付不来 4 个产品的疯狂输出。

@sampeng 没听说过微服务靠运维团队支撑的，最多设立个基础组件部门，里面也都是做微服务中间件的研发

@mreasonyang 只有十来个人的团队咋分出来基础组件部门…都是这些高大上的微服务组件都得运维来玩…

@xuanbg goodluck…

正常是先单体应用方便快速迭代，中期项目复杂度、流量真的上来了或者团队人员有了更细的拆分后才会重构到微服务的，把这个流程反过来搞是不合理的。另外微服务和语言没直接关联，Java 的微服务组件生态完善不是缺点而是优点，不要觉得是 Java 系的东西就是 low 的。

@sampeng 人少分不出基础组件部门就直接用开源方案呗。。你可以了解下各大厂的人员分工情况

你说的这些, 包括你自己的问题, 我感觉最后都是人的问题.

别问，问就是 Java，
别问，问就是 Spring Cloud，
别问，问就是微服务，
什么？都 2020 年了你还在用老掉牙的 Spring MVC ？
我学弟做学生管理系统的期末作业都用上 Spring Cloud 了，
你那都老掉牙了，不思进取，混开发经验的混子！

你问我微服务有什么好处？自己上网搜啊，一搜一大把！
“跨语言、不同业务之间互相调用、熔断限流、灵活部署......”

别跟我提什么业务体量，我们公司三个人微服务照样玩的溜！
自己技术菜就是自己技术菜，作为技术人，连新的技术 /框架 /架构都不去跟进，还好意思干这行？

我编不下去了。。。。（滑稽

这是人的问题，不是特定技术的问题
包括你自己的问题

42L +1

过度设计与语言无关

@guolaopi #41 Spring Cloud 也还是 Spring MVC

@wysnylc
那该换成啥，不做 java 不知道，SSM ？（滑稽

所以想搞微服务有啥经典的书可以看？

@sampeng 微服务没有“专职运维”这个概念，无论你去哪个大厂，都不会有“专职“，只有 Devops 和 SRE 。

@keaideren 《 Microservices Patterns:With Examples in Java 》，这本书真不错

@RyanArthur 谢了，看这书是不是还得把 Java 学学

@keaideren 其实不用。它只是用 Java 举的例子。
微服务的思想没有那么晦涩，Java 的例子换成你使用的语言，比如 Golang，对应 Golang 生态内实现某一个思想的轮子是哪些。

@RyanArthur 现在是 V2EX 人均大厂了？ SRE 和 devops 不是发展出来的一个职位？十几研发的小公司整个 SRE 或者 devop 团队？

就算有公司这部门。微服务带来的开发效率低下是肉眼可见的。真的微服务解放了程序员？那就不要再抱怨业务逻辑简单，天天 CRUD 。微服务让研发真的成了工具人。你以为你懂了微服务，其实任何人都可以替代你…想想是不是很可怕

@casillasyi #9
然后一堆瑞士军刀都被改造成了 JAVA 的样子

20 年前开始用 j2ee 做项目，刚开始是 JSP/servlet，后来加上 EJB，再后来用上 struts1.x，再加上模板，出了 spring 和 hibernate 之后，刚开始感觉是一种简化和进化，后来 spring 越搞越大，必须 DI/IoC，不用 Spring 全套就不行，整个框架比当初的 j2ee 还大了，我干脆用 play 代替 Spring，再到后来连 java 也不用了，nodejs 、python 用起来更顺手。实际从事项目开发的时候，个人感觉，开发团队在 100 个人以下的时候应该用不上微服务，这样几乎排除了 9 成以上的项目，所以很多用微服务的项目大概率是开发人员在积累微服务的项目经验。

首先 50 个人以下的团队没必要用微服务
其次 不要以以后可能要 scale 的想法去提前上微服务

过早优化和过度设计就是万恶之源

微服务 是历史选择，自然竞争的结果。JAVA 也是。

不要问为什么，想一想 Java 为什么能从百家争鸣 到现在独领风骚。如果觉得不是，那么请从 0 开始，自己写框架，开发一个 springboot 这样级别的项目。你觉得需要多久？

就像现在的收集太无趣了，20 年前 每个手机都不一样，现在每个手机都基本一样，这是为什么？因为目前的条件看，这就是最好的。

都在强调不是 Java 的问题，是人的问题。
可是这个明明就是 Java 人的普遍问题，社区流行这个，大厂大企业话语权过重，市面上流行的就是这个，你想向上走这套必须都得过一过。过度设计的情况必然会出现，没办法的事。

我觉着要是 ToB 或者确定量不会激增的业务单服务 php 一把梭挺好的，又快又简单。
工程结构和技术框架升级是为了解决问题的，不是为了升级而升级。
看楼主描述就是一个“论坛”，我们也不知道有多少日活，访问量怎么样，以及团队规模怎么样，大家是会 Go 的多还是 Php 多还是 Java 多，楼主说没有太复杂的业务逻辑，基本上都是 CRUD，但微服务解决的问题不是满足复杂业务逻辑，单服务的 PHP/Python 照样可以满足复杂的业务逻辑，而是在可用性、稳定性上微服务有更强的 Buff，如果业务增量低、团队人数少、日活不咋滴，那有一说一，确实是面向简历编程，又臭又烂了
哈哈哈 还是比较理解楼主的

@sun1993

“人家提供了微服务周边的一系列工具，比如注册&发现、熔断&限流等”，这些网上不是说是微服务的基础的么？这些是微服务的扩展？微服务最基本的是什么？

@NoString 只是一个小 APP, 能发帖, 类似百度贴吧 app 那样, 比贴吧还要简答. 朋友的项目, 让我帮忙维护的.

是的, 目前用的就是 Laravel, 基本上能做到"快乐开发", 把精力放在 "如何解决问题"上

10 万规模以下，没有必要上这些东西，徒增复杂性。

额，我学 SpringCloud 纯粹就是学个组件怎么用，然后写在简历上，上家公司 120 万的用户量也就是两台服务器做了集群，没有分布式也没有微服务，业务功能也有四十多个，我觉得微服务就是给千万级的用户量用的，如果有人在公司把一个管理系统拆分成几个服务部署，我会反思我为什么会和他成为同事……

其实很多行业都有这个问题。

一旦行业领头企业开始偏向某个方向，就会有一堆“跟风者”。
跟风者不考虑合理性，只是因为行业领头人这么选了。
然后紧接着就是“行业头部”整个都偏向这个方向，因为你不偏向你就不是行业头部了，你就 out 了。

然后就是“行业头部”固步自封，认为方向和自己不一致的都是异教徒。
随着“跟风者”的体量越来越大，越来越多的人也就被逼着必须“跟风”。

直到行业领头企业转向，开启下一波循环。

@dog82 出门买烟穿燕尾服，不应该是自己的架构能力，技术选型不到位的问题吗？

LZ 的问题还是看实际业务场景，比如日活超 1000W 的论坛，使用 Spring Cloud 技术体系没什么问题吧，并且还会比这个要更复杂一些。
但是如果只是几千日活，Python+Flask 就能玩了。
所以不要脱离实际业务场景谈架构。

@sampeng 有点前后矛盾，如果使得开发效率降低，那多半是拆分不合理，比如原来一条 sql 就能完成的，现在搞成了分布式事务，徒增复杂性；
如果合理，开发难度降低，使得开发人员可以任意替换，但这种情况下，开发效率显然会更高。

脱离场景直接下结论都是扯王八犊子

我觉得现在有些“架构师”、“技术总监”被微服务荼毒了，动不动就要微服务，项目还没落地，业务也没经过市场验证，直接就上 Spring Cloud 那一套，动不动就要好几台服务器，老板问为什么要这么多，美其名“考虑到后面数据量上来”。

@Vegetable 只能说 Java 的群体很大，哪天 go，php，rust，Clojure 也有这么大的群体，你同样会说对应的人有普遍问题。

@tctc4869 服务注册&发现、熔断&限流、分布式链路追踪等，是独立的技术，微服务是架构思想，之所以提到微服务就跟着这些概念，是因为这些技术可以更好的管理微服务架构系统，而 spring cloud 就全套提供了这些东西。
其实不用 spring cloud 也可以，我们公司的注册&发现系统是自研的，服务拆分用的 grpc，链路追踪系统用的 jaeger，熔断器用的 Resilience4j，微服务是架构思想，实现它的方式有很多种。

真的是分久必合 合久必分，微服务火了一段时间，现在又开始说增加运维负担又开始揉一起去了，你赶了个晚集

微服务是架构思想，和 Java 没什么关系，不依赖于具体语言的实现。能说出“微服务”很 Java 这种话，根本就不了解微服务。如果业务场景不需要做解耦和控制，就没有用微服务的必要。你可以说技术选型有问题，也可以说微服务太盛行导致大家都想攒攒经验，但这不是微服务和 Java 本身的问题

Java 就是这么厉害，有这么丰富的生态上限，其他语言有吗？别管我用不用得上，就问你有没有？

只有最适合的架构,没有最好的架构,crud 项目强行上微服务只会让项目变得臃肿

不上微服务 ppt 咋写