3 次尝试使用 springcloud 技术重构项目失败，暂时得出结论：微服务不行

调试

解耦

项目

结论

86 条回复 • 2019-10-21 19:05:14 +08:00

1

lazyfighter

2019-10-18 15:34:17 +08:00

7

我都傻了

2

aLazarus

2019-10-18 16:17:51 +08:00

看到标题我以为严肃文学发展到了 v2

3

ZSeptember

2019-10-18 16:21:56 +08:00

2

哈哈哈，这几条基本都是你们自己的问题。。关微服务什么事情

4

codzzb

2019-10-18 16:25:29 +08:00

1

@aLazarus 严肃文学已经深入程序员生活的方方面面（一个想法不一定对

5

tuboshuv1

2019-10-18 16:26:11 +08:00

哈哈哈哈哈哈哈哈哈，还是用 Spring boot 吧。你们需求没到这步。

6

exploreXin

2019-10-18 16:26:58 +08:00

1

数次尝试使用 Mac 写代码不出 bug 失败，暂时得出结论：苹果不行。

7

chendy

2019-10-18 16:28:18 +08:00

不该拆，或者不会拆，就不要拆

8

askfilm

2019-10-18 16:29:49 +08:00

6

@echofather 肯定有会一大批人讽刺你技术没到家，不过我觉得你总结的挺好，比较实际

9

Guozi1989

2019-10-18 16:31:27 +08:00

在没有真正理解微服务的时候不要轻易的去尝试硬上。

10

stevenkang

2019-10-18 16:32:20 +08:00 via iPhone

1

微服务分而治之，治理的是人员架构，跟技术关系不大。

微服务维护成本比单体架构高太多，舍不得投入人力资源去搞的话，还是老老实实单体架构。

11

skotori

2019-10-18 16:33:56 +08:00

的确，项目没有臃肿到必须分模块部署的时候，不需要微服务

12

misaka19000

2019-10-18 16:34:52 +08:00

@codzzb #4 你是立党吗？

13

aLazarus

2019-10-18 16:43:56 +08:00

@codzzb #4 你是特师 2300 个精神碎片中的一个么？

14

Yuicon

2019-10-18 16:47:47 +08:00

最近我也在重构确实太麻烦本来是 service 之间的调用改成微服务就要一次性全改好工作量太大所以我选择先把整个单体作为一个微服务提供服务然后从依赖最小的改起比如我第一个准备改 id 生成器

15

GoLand

2019-10-18 16:48:13 +08:00

7

图来了

16

oatw

2019-10-18 17:02:23 +08:00

不知道楼主是自己玩儿还是和团队小伙伴一起玩儿，如果自己玩儿，还是不要微服务了吧～蛋疼夹着走路过。。。

17

securityCoding

2019-10-18 17:19:31 +08:00

每天就几万的量 , 上个毛微服务

18

adamzhuang

2019-10-18 17:28:27 +08:00

4. interface 要作为公共的项目单独维护

这点没理解

19

Amit

2019-10-18 17:33:24 +08:00

没有一定的量不要用微服务。直接改造成微服务太激进了，可以先在原服务基础上改，分模块解耦，然后把能拆的拆出来，不一定要拆的很细，实在不好分开的放到一个服务也没关系，分布式事务能不用就不用。

20

echofather

OP

2019-10-18 17:40:13 +08:00

@adamzhuang 因为各个微服务调用的其实是各个 service 的接口，所以最优的实践是将所有的 service 接口放到一个统一的公共项目中，而不是各自复制各自的不然后期添加修改功能就乱了。所以这一点就很别扭

21

adamzhuang

2019-10-18 17:48:11 +08:00

@echofather 微服务之间交互是走 Dubbo 之类的 RPC 吗？我们这边系统交互用的 spring cloud feign，然后全上 Restful 接口，要用的时候就查文档

22

reus

2019-10-18 17:49:55 +08:00

1

为什么网飞行，你不行？
为什么谷歌行，你不行？
很显然就是你不行啊，不是微服务不行

23

wolfie

2019-10-18 17:50:11 +08:00

1 2 3 6 自己问题
5. 运维难度增高，开发难度降低
7. 大写的问号

24

wangxiaoaer

2019-10-18 17:54:34 +08:00 via Android

@echofather 服务之间用 restful 进行交互的话，为什么还要用接口，你们是直接 RPC 调用其它服务的类和方法？

何必呢，如果是 HTTP 这种交互方式，每个服务想怎么实现都好啊，语言不同都没关系。

25

echofather

OP

2019-10-18 17:56:28 +08:00

@reus 你行吗，你行你上

26

hlwjia

2019-10-18 18:00:54 +08:00 via iPhone

9012 年了不要说什么行不行，说什么合适不合适。

27

echofather

OP

2019-10-18 18:02:52 +08:00

@wolfie 关于第 7 条你自己测试下就知道了，使用那种全局事务的业务压测一下就行，其时间都消耗在网络 io 上了

28

bk201

2019-10-18 18:04:03 +08:00

没一条理由站得住脚，仔细琢磨下你自己的问题点，搜索下。

29

ErrorMan

2019-10-18 18:06:40 +08:00

如果微服务不行的话，为什么面试都要问呢，还是基础问题

30

echofather

OP

2019-10-18 18:08:43 +08:00

@bk201 我不相信网上那些胡几把扯淡，他们居然告诉我事务可以用最终一致（手动检查修改错误数据）解决😭

31

WispZhan

2019-10-18 18:09:43 +08:00 via Android

1

很多小团队连设计和建模都没，上来就撸服务，走都没学好就想着跑。

做微服务要是真不会分服务，建议先从单体（巨石）应用开始，核心业务域确定了之后再根据情况进行微服务拆分。

上手就来微服务设计的一般只有两类人，1. 运维开发 /中间件开发，指脱离业务域运作的； 2. 啥都不知道盲从的，完全不顾及项目成本和风险的

32

caotian

2019-10-18 18:12:19 +08:00

已经在坑里了, 一个 springboot 项目做了一大半, 拆成了十几个微服务, 都走 restful 接口做 rpc, 最坑的是用了 spring cloud stream, 刚上它的时候觉得挺爽, 不用自己管理消息, 然后后续有些服务用了别的语言来写, 比如用 go 写了一些原生 sql 查询的统计报表啥的, 发现 consul 和 spring data gateway 都可以兼容别的语言, 就是这个 spring cloud stream 没说怎么兼容, 也查不到资料, spring cloud 就提供了一个 sidecar 项目来给其它语言兼容做了范例, 奈何这货用不上, 算是一个坑了。
另外拆成这么多服务, 每个服务用 docker 部署, 这个内存消耗真的是巨大哪, 每个 docker 容器, 如果不限制, 启动起来都是六七百 M, 运行一段时间都是上 G 的内存占用, 而 go 实现的报表启动起来的时候也就几 M 内存占用。而且如果上 k8s, rpc 也不好处理, 于是有了个 spring cloud for k8s 的项目, 感觉又弄更复杂了。
整体上看来, 如果项目要运行在 k8s 上, 还是不要用 spring cloud 为好, 个人浅见

33

reus

2019-10-18 18:14:48 +08:00

1

@echofather 我当然行啊，我早就上了，呵呵。

34

xuminzhong

2019-10-18 18:16:27 +08:00

一个项目中，决定使用什么、不使用什么，也是一个难点，这也是体现架构师价值的地方。
害怕技术落后、大厂把微服务作为基础面试，这点的确有跟风的原因。

入行 10 来年，最近半年开始接触 springcloud 微服务，以我不多的经验来看，
微服务在事务这块的处理能力真的非常吃力，特别是加上 kafka 这类消息系统后，几乎无解。

我也赞成楼主的观点，springcloud 微服务不适合大多的情况，而且真就没遇到适合的情况，
楼上说的谷歌、网飞行，就比较扯了，他们面对的业务，国内有几个公司、几个项目会遇到。

35

arraysnow

2019-10-18 18:19:27 +08:00

我们前台每天千万交易量，不用微服务会搞死的。
运营端顶多 10wpv，拆分微服务纯属找别扭。

36

arraysnow

2019-10-18 18:25:17 +08:00

所以你的结论还是片面些了，大公司一个随随便便的前台应用，后面就需要不同部门的几百人程序员支撑。不考虑服务治理，确实没办法撑起业务量，这在大厂算是你说的“基础”了

37

mawenjian

2019-10-18 18:29:42 +08:00 via Android

如果不是访问量巨大，或者业务庞杂，硬上微服务意义不算太大。如果考虑以后的可扩展性，只做服务化也足够了，后续再拆也不算困难，步子太大的话容易扯着 D。

38

index90

2019-10-18 18:42:02 +08:00

赞同 #31，听到过有人说，“然后就说明明一个请求搞定的事情，偏偏要转发几次请求”，最后得出结论是微服务没用。
不熟悉业务，不从领域设计出发，就是为了微服务而微服务了。

39

wc951

2019-10-18 19:01:03 +08:00 via Android

上微服务之前先了解领域驱动设计

40

raphael008

2019-10-18 19:04:39 +08:00

我看老外架构都是在 IT 基础架构方面想办法。。。

41

HangoX

2019-10-18 19:11:05 +08:00

楼主一个人玩啥，人家都是好几百人的团队的，然后每个小组负责不同业务，以前那种开发方式压根没法开发，这样才分开来，性能肯定有下降，但是开发效率上来了

42

CODEWEA

2019-10-18 20:36:32 +08:00

微服务服务的是团队，不是性能，微服务是有额外的资源消耗的，非大公司大流量，别瞎搞花里胡哨的，没用。

43

yidinghe

2019-10-18 21:13:44 +08:00 via Android

微服务的人力成本非常高的，解耦的代价就是代码量增加好几倍，业务模型复杂好几倍。

44

lihongjie0209

2019-10-18 21:16:12 +08:00

@reus #22 因为 99%的公司不如谷歌

45

nekoyaki

2019-10-18 21:42:12 +08:00

1

3 次尝试使用导弹打蚊子失败，暂时得出结论：制导兵器不行。

46

hantsy

2019-10-18 21:47:37 +08:00

8

1. 在你不懂领域建模，搞不清自己项目需求的 Bounded Context 的时候，还是老实做好基本的东西，把业务逻辑先清理，这比什么都重要。

2. 微服务不仅是应用程序逻辑上细分，团队组织结构也要随之变化。

3. 微服务实施中 DevOps 是一等公民，如果在 Infrastructure 上不能做到自动化，不写测试，不做 CI、CD，还是算了吧。这个我了解过国内所谓在实施微服务的，基本很少去做，靠人肉运维还是算了吧，你永远不是微服务。

4. 微服务为容器而生，Spring Cloud 最大问题就是把微服务一些运维相关的东西耦合到应用之一，会导致写测试非常不方便。在 Spring Cloud 刚出来的时候，那时只有 Netflix 那一套，一个项目 Dropwizard 迁移过来，做了大量的 POC，最终我们只采用了 Spring Cloud 的日志跟踪，其他全部用容器（ Service Discovery, Load Balance 等）实现。

如果对微服务的一些模式有一定认知，你会发现用什么语言框架去实现都不是问题。当你可以驾驭微服务，完全可以混合使用多种语言，架框去实现。理想情况下，使用微服务可以发挥团队所有人员的天分，开发人员（一个小团队）完全可以用自己的擅长的技术去实现（ micro ） service，把产品做到极致。

你以为用了 Spring Cloud 就是微服务。

47

hantsy

2019-10-18 21:49:58 +08:00

@yidinghe 这个没错，天下没有免费的午餐。马大叔文章也明确建议从单体应用开始，积累领域建模经验，为将来可能的微服务转形准备。

48

Cbdy

2019-10-18 22:01:30 +08:00 via Android

做系统设计要实事求是，理论联系实际。切忌本本主义，教条主义。

49

luozic

2019-10-18 23:58:27 +08:00 via iPhone

结合自己实际情况做技术，再好的东西，暂时用不了就是用不了。并且微服务也不是适合所有公司的“银弹”。

50

zhazi

2019-10-19 00:14:55 +08:00 via Android

1

多读书，先学 oop，熟练后然后就自己能整理出来领域上下文了。
用自然语言描述清楚你的业务，然后区分出业务名词。
思考业务名词是不是应该建模。
不要去考虑什么微服务。
每个业务名词都清晰了，对象也就丰满了。
用贫血模型永远都是 service 里的大泥球。

51

reus

2019-10-19 00:24:54 +08:00

@lihongjie0209 为什么不做那 1%呢？不想上进又何必工作。

52

vjnjc

2019-10-19 00:31:36 +08:00

不知道你们团队多少人，之前我们 5 个人的情况也调研过，发现提升不大。

53

shanlan

2019-10-19 01:01:38 +08:00

看大家这么一说，我觉得我们公司的微服务可能玩不起来了。

54

xuanbg

2019-10-19 09:06:41 +08:00

1

不客气地说，大部分程序员连方法 /类都分不好，只会写长长的、纠缠在一起的面条代码。不管什么业务，都是三层一把梭，哪有什么模块划分。连划分模块的能力都没有，你能指望他搞好微服务？

55

v2orz

2019-10-19 09:11:52 +08:00

小公司小业务量就别用呗，当你业务大了之后你自然就知道需要用了

56

wd1196554643

2019-10-19 09:12:42 +08:00

小公司没必要，没有复杂的业务没必要上微服务，单体的应用可以解决没必要搞复杂

57

lihongjie0209

2019-10-19 09:42:39 +08:00

@reus #51
首先，客户和业务没这需求，作为开发你怎么办
其次，在最理想的情况下，你决定成为那 1%的开发者，你跳槽到谷歌之类的大公司，然后呢，所有人都有着理想情况吗？

只要这个世界还在运行，那么就会注定有 99%的一般需求的项目和 1%的极端需求的项目，开发者也是这样。不能说你是 1%的那波人就认为 99%的人不努力。

58

jwenjian

2019-10-19 10:04:36 +08:00

1

nginx 后面挂几个单体 springboot 应用实在撑不住了再一点一点拆。

59

reus

2019-10-19 10:12:36 +08:00

@lihongjie0209 那就是人的问题，不是“微服务”的问题。

60

cyheng

2019-10-19 10:20:30 +08:00

1

楼主深知钓鱼的是技巧，我估计它如果老老实实问他的问题估计没有几个人回答

61

YzSama

2019-10-19 10:22:56 +08:00

@caotian #32 是的，我认同

如果微服务没有好的基础设施，还是不要碰的好。我们公司是上了 k8s，但是也不会想去上 SpringCloud。

SpringBoot 足够了。虽然，拆分了。但是开发的效率是提升了几倍。

我们没上容器化之前，运维人肉搬运代码上线的。运维天天被各个项目上线，烦的抽离不出来。基本一天都安排不过来。自动化之后，基本没人找了。专心搞服务器。😂

62

lihongjie0209

2019-10-19 10:26:15 +08:00

@reus #59 技术问题不能落地比人的问题更大

63

uyhyygyug1234

2019-10-19 10:30:43 +08:00

你们喷楼主干哈，楼主自己不是总结的挺好，认识到了业务模型不适合。这个社区提供经验教训不挺好。

64

reus

2019-10-19 10:42:53 +08:00

@lihongjie0209 屙屎不出赖地硬。

65

newtype0092

2019-10-19 10:46:53 +08:00

@uyhyygyug1234 一个东西尝试了 3 次认识到了业务模型不适合，那不是瞎尝试么。。。
楼主说主要是怕技术落后，这算个什么鬼理由？
我理解的重构用该是提前调研分析优缺点，想好要解决的现有问题，和可能引入的新问题，评估利大于弊才动手。
看见别家用什么二话不说上手就是照着干，那纯粹就是闲的想加班了。。。

66

echofather

OP

2019-10-19 10:56:10 +08:00

@newtype0092 不会新技术，没有项目经验，等你 35 了，你觉得他们大厂公司不会淘汰你吗

67

yiyi11

2019-10-19 10:56:25 +08:00 via Android

有一张图，就是单机服务是一坨大 shi，然后拆成微服务是一堆小 shi。微服务只有配合容器技术，深度实践 devops 才值得，否则只是徒增成本。而且微服务不是全部，只是解决特定领域的问题的子集。

68

kiddult

2019-10-19 11:42:21 +08:00 via Android

@xuminzhong 涉及 2c 的话，轻易不要用事务，2b 看个人，不过还是觉得事后补偿比事务好，为那点安全性增加的复杂度和性能消耗不成比例

69

JerryCha

2019-10-19 12:04:02 +08:00

扔掉 SpringBoot，你的 DEBUG 会更轻松。

70

xkzhangsan

2019-10-19 12:31:52 +08:00

建议看一下重新定义 Spring Cloud 实战，里面讲解比较详细，包括分布式事务处理。

71

xkzhangsan

2019-10-19 12:33:17 +08:00

老项目业务比较复杂的话，重构要慎重，慢慢迭代进行。

72

oneisall8955

2019-10-19 12:49:35 +08:00 via Android

@JerryCha 哈？为啥这么说

73

sujin190

2019-10-19 13:51:49 +08:00 via Android

能得出这个结论的大部分估计都是不是技术方案不行，是你不行，抽象架构化能力不足的话，微服务这种东西做出来只会比单体服务更为糟糕

74

W1angMh

2019-10-19 13:56:59 +08:00

1

我们团队最近也在做架构升级，银行类项目，单体应用拆成分布式微服务，这个过程的确会让人非常头痛，一周要开无数次会来讨论究竟怎么拆。我们原来的应用体量非常大，业务逻辑非常复杂，现在拆成微服务之后，感觉清晰明朗许多，优点还是挺明显的。我的结论就是技术没有什么行与不行这一说法，只能说合适不合适你当前的业务需求

75

lihongjie0209

2019-10-19 14:04:40 +08:00

@yiyi11 #67 https://imgur.com/Rmur93a 这个吧，我看 youtube 的一个演讲的时候截图的，就是说这种情况

76

lihongjie0209

2019-10-19 14:07:32 +08:00

@reus #64 对于楼主的结论来说确实是这样的，对于我来说，只是微服务在这种场景下不合适

77

lidfather

2019-10-19 14:37:11 +08:00

微服务已经过时，现在是中台架构，了解一下

78

dongeast52123

2019-10-19 15:08:04 +08:00

实施微服务有一个必要条件：有钱。有钱了才能有一套强力的运维开发体系支撑，硬件，软件，开发人员。
但是真正搞得起这些的，公司不多，许多中小型互联网公司开始折腾“微服务”，纯属自己给自己挖坑。先去把业务模型划分清楚吧。

79

lynskylate

2019-10-19 15:13:35 +08:00 via Android

@xuminzhong ....大厂根本不会用 spring cloud，默认的组件根本满足不了性能需求，都是自建基础设施的。
spring cloud 的目标本身就是没有能力和金钱组建基础设施的小公司

80

Arnie97

2019-10-19 18:14:32 +08:00 via Android

如果各服务都部署在同一台机器上，增加了通信开销，那自然是浪费资源，没有单体应用效率高。分布式的意义在于方便水平扩容…

81

JerryCha

2019-10-19 20:13:35 +08:00

@oneisall8955 看 15 楼

82

mreasonyang

2019-10-20 09:17:56 +08:00 via iPhone

我觉得要不要拆微服务有个简单但通常都很有效的判断标准，那就是你们的老服务为了保证服务容量是不是占用了大量机器导致每次发布都要花费一个小时以上，如果是的话那就应该拆分了

83

mreasonyang

2019-10-20 09:21:00 +08:00 via iPhone

另外微服务其实服务间调用真的不适合搞成 HTTP RESTful，如果发现网络 IO 是瓶颈，还是尽早改二进制 RPC 吧

84

jwangkun

2019-10-21 08:41:56 +08:00

只能说你们公司现在业务达不到需要微服务的条件，不要做井底之蛙，随便作出结论

85

SkyLine7

2019-10-21 10:17:25 +08:00

我们这用 springboot 足够了,本来每天访问量就不多

86

lazyfighter

2019-10-21 19:05:14 +08:00

@stevenkang 微服务涉设计中有专门一章来说明这个东西，推荐 @echofather 读一读