这是一个创建于 1104 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样的 目前做的一个项目，一个微服务，俩节点，配了一个微服务注册中心配置中心集群 consul 为什么这么做，一方面是为了监控服务状态，虽然是只有一个服务，但也是个微服务，俩节点，另外就是刚学习了 consul ，想实践一波 这个算过度设计了不，欢迎大家讨论
第 1 条附言 · 2021-12-20 17:19:06 +08:00
其实今天的事情已经有结果了，就是去掉额外的注册中心，想跟大家讨论下，同类事情的边界在哪里，现在看来应该是具体的业务场景，不能为了技术尝鲜给项目带来较大风险，遇到这样问题应该是自己思考下到底有没有必要，意见相左还得讨论下
第 2 条附言 · 2021-12-20 17:23:30 +08:00
大家讨论的都挺好，不过呢，真当我组长不逛V站啊，不用回这么快吧，:cry:
 |
1
daiwenzh5 2021-12-20 16:06:06 +08:00
看情况吧，如果服务器资源充足的话，实践一下未尝不可。
|
 |
3
z740713651 2021-12-20 16:11:01 +08:00  11
大佬这叫简历驱动开发
|
|
4
daiwenzh5 2021-12-20 16:12:52 +08:00
@z740713651 真实
|
 |
5
bwensun OP @z740713651 雀食，作为开发不在生产上用过，解决问题，怎么能说会了呢 狗头
|
 |
6
hidemyself 2021-12-20 16:13:36 +08:00
借楼问一下，微服务一般都是里面所有的服务都是自己开发吗
|
 |
7
zoharSoul 2021-12-20 16:14:22 +08:00
刚学习了 consul ，想实践一波
|
 |
8
ospider 2021-12-20 16:14:47 +08:00
组长说的对，你要想试一下，自己搞个环境玩玩儿就行，生产环境哪儿能上自己刚学会的东西啊，万一出问题了谁解决？再者，你这俩节点确实用不上啊……
|
|
9
daiwenzh5 2021-12-20 16:15:51 +08:00
@hidemyself 当然不是，你只需要关注自己业务所在的微服务，其他的可能是其他同事在开发，也可能是公司已经有的产品，或者第三方的
|
 |
10
FantaMole 2021-12-20 16:17:54 +08:00 11
其实挺多时候，让你不要过度设计的另一个想表达的意思就是，你这么搞，项目可能做不完，控制好项目工时，别给我瞎搞
|
|
11
bwensun OP @ospider 嗯 能理解他说的 但是这个 consul 就算出问题也在我也能及时处理呀 正常来说哪有不出问题的嘛 不能为了追求绝对的稳定 放弃任何尝试的机会呀 俩节点雀食用不上 狗头
|
 |
14
Nich0la5 2021-12-20 16:21:40 +08:00 7
10 楼说得对 公司是雇你干活的不是雇你整活的，也不是每个公司都愿意消耗成本让员工学习
|
 |
16
wellsc 2021-12-20 16:25:11 +08:00
注册中心这么关键的东西，两个节点还少了呢
|
 |
18
k9982874 2021-12-20 16:27:01 +08:00
你点个蛋炒饭，厨师给你来个鲍鱼炒饭顺道练练手，再收你 100 不过分吧
|
 |
19
masterclock 2021-12-20 16:27:23 +08:00
生产环境用什么不是应该组长或者更上面的领导决定吗？
|
|
21
bwensun OP @masterclock 是的 这个后面也改回来了 但是引发我的思考 想问问兄弟萌都是怎么处理这样问题的呢
|
|
22
Nich0la5 2021-12-20 16:34:06 +08:00
@bwensun 我 leader 对我就一个要求 别延期， 实践起来就是开发文档之外的事情尽量不要做（不然我还有时间在 v 站吹逼吗），骚操作可以做，但是要放到下一期评审里面评估一下是否有意义。稳定性其实是其次的，如果没被毙掉就可以做，想不毙掉就得证明你这么改动的价值。像这个任务，你自己都说明不了它的必要性，评审怎么能通过呢。
|
 |
23
br_wang 2021-12-20 16:36:08 +08:00 8
组长这么说可能是他觉得「杀鸡用牛刀，后面你要是不维护了我还得替你擦屁股」。所以，如果你不是只是一时兴起，可以把基于这个架构的中期计划跟他聊聊，明确下后面的路线和规划，可能会好一点。
老板怕得不就是「不确定性」么。让他了解你的意图和你有计划就好。别着眼于当前状况的解释。 |
 |
24
sujin190 2021-12-20 16:36:41 +08:00
java 这一套的话，反正更新重启一下十分钟过去了也不止，所以两个节点也想用注册中心也可以理解，否则真没啥必要，否则节点数比较少服务也少也搞似乎是个坑，大炮打蚊子可不但没提高生成效率反而坑死人的了
|
 |
25
zliea 2021-12-20 16:38:49 +08:00
就一个微服务？我是组长，我也不想让你搞； 10 个微服务再搞吧。
|
 |
26
Ackvincent 2021-12-20 16:39:05 +08:00
能用就行了，好歹给后边人留点空间。
|
 |
27
charlie21 2021-12-20 16:39:06 +08:00 via iPhone
别延期是可以的
|
|
29
bwensun OP @Nich0la5 嗯 基本想法一致 说明必要性这块可有的说（我以前在警校写报告拿满分--黎明）另外我觉得新的东西出来自然有它对于传统的东西的优势，我们不应该向前看嘛 很多时候只是习惯于某某而不是真的有足够大的理由停留在之前的样子 我不是说我现在说的项目 就是说在我们工作中
|
 |
30
Mogugugugu 2021-12-20 16:41:06 +08:00
你离职了，谁来接手？
|
|
31
bwensun OP @ztechstack 哭
|
 |
32
jtwor 2021-12-20 16:42:38 +08:00
反手加个网关上个鉴权中心全上 grpc 弄个 elk 日志中心搭套容器编排自动部署 狗头)
其实这些一堆中间件学习难度一般，基本搭一次就大概懂了，如果工地的业务不大没必要上微服务，基本都会否决使用的，学习和维护都是需要成本的，不是所有公司都愿意投入。还是自己项目练练，后面跳大点公司把，如果是开源的最好看看源码，学习是学习，搬砖是搬砖。 |
 |
33
joyhub2140 2021-12-20 16:43:09 +08:00
跟着团队走。。。商业项目不是试错场地，除非有人负责。。。
|
|
34
bwensun OP @Mogugugugu 那这不得看人嘛 说走提包就走呀
|
 |
36
nbndco 2021-12-20 16:45:40 +08:00 37
非常严重的过度设计。
有人说这种东西需要组长决定，或者公司不是来让你学习的，反而不应该是考量因素。大家天天问怎么提升薪水，你天天就乖乖听组长分配的任务堆 CRUD ，其他不闻不问不学习，真的能加薪吗？ 真正关键的是，你要解决什么问题，以及如何解决问题。 就你描述的情况本身，一个服务两个节点，看起来也不像是会有很大的增长的样子，那么就不存在 service mesh 的应用场景。也就是说，你没有解决任何问题，只是单纯的引入了一个新的（大）问题——设置管理维护 consul ，组长只是提醒你不要过度设计，也是有问题的，要是我就直接让你全撤了。你要意识到，你的实践一定是实践如何用 consul 解决问题，不是使用 consul ，你要用 consul 你自己搭个 k8s 就好了。 所以这样做就没有意义么，也不是。这就取决于你要解决什么问题。 你说你现在做的是一个微服务，那就意味着公司里有很多其他的微服务。你说你在使用 consul ，那就意味着公司现在并没有任何的 service mesh 方案，考虑到 consul 和 k8s 绑定之紧，我甚至可以猜测整个公司的服务部署都是完全独立各组自行管理的。这显然是一个错误的方案，缺乏正确微服务架构的特性。那么，要不要提升，要不要改，要不要用 consul ，我觉得是很值得考虑的。 有人肯定又要说这种事情推不动，大家都只想堆 CRUD 。那我也没啥可说的，这个时候我只能反省为何我会加入这种公司了。 |
 |
37
Bigglesworth 2021-12-20 16:46:19 +08:00
还好，也不是完全没用
|
 |
38
pigspy 2021-12-20 16:46:33 +08:00
我们这边，微服务调用链啥，整体部署结构，都要经过评审，不允许自己随便弄
这样也方便出问题甩锅 |
 |
39
RudyS 2021-12-20 16:46:48 +08:00
任何事都应尽量简单，但不宜过于简单。---爱因斯坦
|
 |
40
otakustay 2021-12-20 16:46:55 +08:00 21
摘录一下 Google 选择引入一个依赖时的决策条款，用于对任何技术做还是不做的评估都有用：
- 是不是有测试，并且使用者可以自己跑起来测试 - 测试是不是通过的 - 谁开发的这个库 - 承诺怎么样的兼容性 - 作者有没有详细地说清楚这个库期望用在什么场景下 - 这项目有多流行 - 我们大概会有多长时间要依赖这个包 - 在历史上这个包搞出来破坏性变更的频率是怎么样的 - 我自己来实现这个依赖的功能的话有多复杂 - 让这个依赖保持版本跟进是不是必要的 - 以后谁来更新依赖的版本 - 这个依赖的版本更新难不难 |
|
41
zliea 2021-12-20 16:47:24 +08:00
偷偷的说一下，前边有 nginx 的话，可以开启 nginx 的 upsteam 健康检查与 check_status 。
|
 |
42
lbp0200 2021-12-20 16:50:14 +08:00 1
你的利益是 搞 consul ，刷简历
你组长的利益是 工期延迟的风险，回头给你擦屁股的风险，他确什么都得不到 另外，你自己也说了，只是“就是刚学习了 consul ，想实践一波”，组长说过度设计，只是很委婉的说法，用不到的技术暂时先收起来 |
 |
43
shyrock 2021-12-20 16:50:25 +08:00
你这岂止是过度，简直就是过度。
虽然我也鼓励部门的技术人员多学习和实践新技术，但这是在部门资源可控的范围之内。 如果你在自己负责的资源之内，自己能承担责任，想上新技术，搞一些试验和学习，毫无问题。 你现在的问题是，自己想学习，责任由组长担。。。说得过去吗？ |
 |
45
lingo 2021-12-20 16:55:00 +08:00
你只是在拿公司的生产环境做自己的学习工具。。。
这么设计对这个项目有啥好处么。没有的话只是为了你的学习而提高复杂度，这不是过度设计是啥。 |
 |
46
loading 2021-12-20 16:56:20 +08:00
无缘无故提高项目复杂度，你组长没错。
实践项目可以自己玩，没必要带到生产环节。 |
 |
47
Jooooooooo 2021-12-20 16:56:44 +08:00
过度设计增加理解成本, 增加系统复杂度, 增加工期. 如果看不见足够好处, 确实少做.
你这么干已经是负面印象了, 如果看重绩效 /涨薪, 最好调整一下 |
|
48
bwensun OP @nbndco 说的很有道理，技术确定应该由场景来决定，我们这边类似于项目交付，并非是针对产品，emm ，只是今天发生这件事情，我想到了别人也应该遇到过，想看看大家是怎么想的
|
|
49
bwensun OP |
 |
50
Biwood 2021-12-20 16:57:35 +08:00
这种显然是需要提前跟 leader 说一声，如果是对技术细节不怎么过问的 leader ， 可能就不管你，随你折腾，但懂技术的 leader 肯定不会轻易让你把生产项目当做试验场的，至少他需要有知情权，不然出了问题他是要承担责任的。
说真的，除非是你们团队本身就有对新技术积极拥抱的文化，否则还是自己私下玩玩算了。 |
 |
51
Rorysky 2021-12-20 16:58:50 +08:00
过度设计的本质，你是拿着成品的组件去堆服务，而不是从整体架构上定制实现。
|
|
52
bwensun OP 其实今天的事情已经有结果了，就是去掉额外的注册中心，想跟大家讨论下，这件事情的边界在哪里，现在看来应该是具体的业务场景，不能为了技术尝鲜给项目带来较大风险，遇到这样问题应该是自己思考下到底有没有必要，意见相左还得讨论下
|
 |
54
sjzjams 2021-12-20 17:03:43 +08:00
只是会用那就用吧，遇到问题我再告诉大家
|
 |
55
A555 2021-12-20 17:06:08 +08:00
一个服务,两个节点上注册中心干嘛用 😅
|
 |
56
fregie 2021-12-20 17:06:37 +08:00
不用会造成问题吗？在未来可见范围内会有问题吗？如果答案是否定的，就算是过度设计了。
|
 |
58
nicebird 2021-12-20 17:09:08 +08:00 1
拿公司项目做实验呢，多试几次估计会被开。
|
 |
59
goofylp 2021-12-20 17:12:29 +08:00
@bwensun 增加复杂度就是增加成本，站在团队的角度肯定是要尽量避免过度设计。另外用个 consul 很难说会给你简历有多少加分，只是个工具。至少我看简历写“熟练使用 XXX”只会减分，我会更看中实际业务上你用技术解决了哪些实际问题，再小的项目都能找到值得设计的点。其实你能综合分析一下，然后说最后没有使用 consul ，那绝对是更吸引面试官的 case 。
|
|
60
A555 2021-12-20 17:20:48 +08:00
@bwensun #57 或者你可以给领导画大饼,以后公司的服务都迁移到微服务架构,接入 consul
总之不能为了用而用,要有规划 |
 |
61
darkengine 2021-12-20 17:21:16 +08:00
虽然出了问题你来解决和维护，但是从组长的领导的角度来看，就是你们组长弄出了问题。
|
 |
62
ppllss 2021-12-20 17:21:55 +08:00
从设计方面，的确过度了，但是从未来架构方面和技术可行性方面这是加分的，懂得尝试，有一点，觉得还是不要拿公司项目做实验，自己私底下去实践，然后整理成一个可行性方案，对公司内部项目的架构升级等。组长愿意就让你做，不愿意，你自己也实践了，能力也提升了
|
 |
63
ganbuliao 2021-12-20 17:43:12 +08:00
一般分项目啊，有的项目就是不能整活。有的独立的小项目，时间充足的时候就各种整活了
|
 |
64
lap510200 2021-12-20 17:59:55 +08:00
搞就完事了 大不了删库跑路
|
 |
65
kujio 2021-12-20 18:03:53 +08:00
时间+稳定优先:效率优先
|
 |
66
jackzhengjbs 2021-12-20 18:11:12 +08:00 via Android
上次那个在注释里面留彩蛋的是不是你？🐶头
|
 |
67
akira 2021-12-20 19:39:30 +08:00
项目怎么做 怎么实施 这些在上服务器前都要讨论确认的吧。。
这个都不是过度不过度设计的问题了，比这严重多了。。 |
 |
68
wyhooo 2021-12-20 19:57:04 +08:00
你跟组长关系不够铁 → →
|
 |
69
meeop 2021-12-20 20:08:04 +08:00
不影响需求实现前提下,尽量搞,面向简历开发,不要怕
除非是你的方案有明显问题影响服务可靠性 |
 |
70
37Y37 2021-12-20 21:21:13 +08:00 via Android
运维，看到这个要骂娘了
|
 |
71
az467 2021-12-20 22:16:54 +08:00
边界就是没经过讨论审查，没出现在文档里的东西一个也不要出现。
何止是过度设计，简直是独走下克上了。 |
 |
72
raptor 2021-12-20 22:22:44 +08:00
面向简历开发的最大问题就是：好处是你自己学习到了，坏处都是公司和后来人的。
我上次接了一个前同事丢下的烂摊子，比你这过度多了，真是想问候他亲属。 |
 |
73
kaedea 2021-12-20 22:23:21 +08:00 via Android
很多 leader 觉得过度设计那是因为改代码的时候不用他们来改。
|
 |
74
hallDrawnel 2021-12-20 22:48:43 +08:00
两个服务的话，那直接用 k8s 的 service 就可以了。引入额外的东西复杂度一下子就变高了。如非必要，勿增实体。
|
 |
75
wangritian 2021-12-20 23:33:36 +08:00
你可以在测试环境玩
|
 |
77
levelworm 2021-12-21 03:39:51 +08:00
@bwensun 其实这就是员工和公司的矛盾之一。我对这些技术不熟，但是就帖子里回复的那些内容，我觉得项目上自己不熟悉的东西的确欠妥。可以和领导提一下用这个，但是如果他反对，那就只好撤出来了，毕竟他最关心的一个是实现一个是可靠性。
如果觉得公司不支持你学新东西，我觉得可以考虑自己学然后跳。当然很多东西，就像你说的，就是不在生产环境试过，怎么能够叫做熟练了呢？这就看你和公司之间的互动了，可以和领导商量下，试试看有没有小的项目可以让你练手。 |
 |
78
ETiV 2021-12-21 05:26:04 +08:00
不知道你执行到哪里了才被组长发现的，
但照理都是先设计（讨论方案），再实现（编写代码）。 「好心提醒」这个词有些……所以是在实现阶段才发现你用了 consul ，然后被毙掉的？ |
 |
79
zw1one 2021-12-21 09:19:06 +08:00
公司只想让你当工具人，用最快的时间搞完 CRUD ，对于公司来说搞其他都是浪费时间。毕竟大部分公司的业务根本用不到这些技术。
|
 |
80
SmiteChow 2021-12-21 09:29:44 +08:00
做任何事都是奥卡姆剃刀原则
|
 |
82
neptuno 2021-12-21 09:31:56 +08:00
挂了的话，确实是组长先背锅吧。（我不是你组长 hhhh ）
|
 |
83
brust 2021-12-21 09:39:58 +08:00
另外就是刚学习了 consul ，想实践一波
emmm |
 |
84
xiaoyang7545 2021-12-21 09:59:08 +08:00
1 你对 consul 并不熟悉，出了问题又得花大量时间精力解决。
2 项目复杂度在“想实践一波”这样无聊的背景下提高，以后维护的人还要因为这个再提高学习成本。 |
 |
85
zjuster 2021-12-21 10:11:44 +08:00
最低成本（代码）和最简（最熟）方法解决业务问题，永远不会错。
你想加任何一点额外的东西，都是额外的维护和沟通成本。 技术晋升不是炫技就行的，要在技术视角解决问题的基础上推进技术迭代和行业理解。前提是先做好业务问题。 |
 |
86
aLazarus 2021-12-21 10:25:10 +08:00 1
在我公司，对于生产环境用新技术的话，首先需要调研技术、编写技术评审文档开会让项目组所有人评审，以及制作一个和业务场景类似的 demo ，而且要完善技术相关的工具或者调用。
|
 |
87
kangkang 2021-12-21 10:39:27 +08:00
若无必要，勿增实体。
|
 |
88
zengyuxi 2021-12-21 11:09:57 +08:00
看到"刚学习了 consul ，想实践一波"，说出这种话的，如果你是学生，我是鼓励的；但你现在的身份，是企业的一员，说出这种话，我觉得你是在耍流氓。
|
 |
90
wudaye 2021-12-21 11:44:14 +08:00
才两个服务节点，你就整个 consul ，站在公司项目利益上肯定是没必要，甚至弊大于利，浪费资源，consul 是不是还得部署多节点保证高可用？单纯想监控两个节点有轻量得多的方案。当人站在个人发展的角度看，你这种面向简历开发的思路是无可厚非的
|
 |
91
ccyixia 2021-12-21 11:50:28 +08:00 1
mark 一下，以后谁给我整幺蛾子，就发这篇给他看。
没有嘲讽 lz 的意思，人都会有成长的过程。lz 明显踩过的坑不够多，试想一下，万一 consul 出了严重 bug 导致服务中断，你半夜被电话喊起来或者节假日紧急 oncall ，google 半天毫无收获结果发现项目 github 里躺着一个没有 close 的 issue 恰好是你遇到的问题。。。相信我，你那时会很想穿越到现在扇自己两巴掌，后悔没有听组长的话。 |
 |
93
struggletoday 2021-12-21 14:07:07 +08:00
@bwensun 想知道 组长到场了没 🐶
|
 |
94
Carver9527 2021-12-21 14:12:49 +08:00
@otakustay 请问一下，这段决策的出处有吗，想进一步的了解
|
 |
95
Real00 2021-12-21 14:16:06 +08:00
奥卡姆剃刀定理
|
 |
96
arthas2234 2021-12-21 14:52:06 +08:00
要使用新的东西，必须组内讨论经过组长的同意才用。
浪费资源就不说了 项目不是你一个人的，也得要考虑组内其他人是否熟悉这个东西，以免你不在的时候出现问题，其他人不能及时解决 |
|
97
otakustay 2021-12-21 15:55:53 +08:00
@Carver9527 #94 就《 Software Engineering at Google 》这本书
|
 |
98
qixcoder 2021-12-21 16:12:38 +08:00
考虑 ROI 吧
|
 |
99
qfdk 2021-12-21 16:12:58 +08:00
其实解决问题方式很多种，团队合作必需要大家都熟悉才能维护一个系统的稳定，如果这个系统只有你来做，里面 bug 出现了 处理的问题，哪天你走了，这个就成了烂尾项目了，后面如何维护。主要是引入了一个 consul 不知道里面有多少的坑。想到以前引入了一个 Eureka 都折腾了一阵子。自己的分布式项目也搞了好久，才发现里面很多门道。 然后你做完了之后要不然还要写完整的文档。。。
|
 |
100
gerorim 2021-12-22 11:10:28 +08:00
@Carver9527 #93
O'Reilly 官网地址： https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/ 原书第 436 页，第 21 章依赖管理 When engineers at Google try to import dependencies, we encourage them to ask this (incomplete) list of questions first: • Does the project have tests that you can run? • Do those tests pass? • Who is providing that dependency? Even among “No warranty implied” OSS projects, there is a significant range of experience and skill set—it’s a very differ‐ ent thing to depend on compatibility from the C++ standard library or Java’s Guava library than it is to select a random project from GitHub or npm. Reputation isn’t everything, but it is worth investigating. • What sort of compatibility is the project aspiring to? • Does the project detail what sort of usage is expected to be supported? • How popular is the project? • How long will we be depending on this project? • How often does the project make breaking changes? Add to this a short selection of internally focused questions: • How complicated would it be to implement that functionality within Google? • What incentives will we have to keep this dependency up to date? • Who will perform an upgrade? • How difficult do we expect it to be to perform an upgrade? |
Select Language