今天被组长好心提醒了下，不要过度设计，有点疑惑，问一问大家，大家理性发言

[bwensun]

事情是这样的 目前做的一个项目，一个微服务，俩节点，配了一个微服务注册中心配置中心集群 consul 为什么这么做，一方面是为了监控服务状态，虽然是只有一个服务，但也是个微服务，俩节点，另外就是刚学习了 consul ，想实践一波 这个算过度设计了不，欢迎大家讨论

[neptuno]

@Cielsky 业务量起来了自然就会了呀，，，又不是什么难的东西。

[neptuno]

挂了的话，确实是组长先背锅吧。（我不是你组长 hhhh ）

[brust]

另外就是刚学习了 consul ，想实践一波
emmm

[xiaoyang7545]

1 你对 consul 并不熟悉，出了问题又得花大量时间精力解决。
2 项目复杂度在“想实践一波”这样无聊的背景下提高，以后维护的人还要因为这个再提高学习成本。

[zjuster]

最低成本（代码）和最简（最熟）方法解决业务问题，永远不会错。

你想加任何一点额外的东西，都是额外的维护和沟通成本。

技术晋升不是炫技就行的，要在技术视角解决问题的基础上推进技术迭代和行业理解。前提是先做好业务问题。

[aLazarus]

在我公司，对于生产环境用新技术的话，首先需要调研技术、编写技术评审文档开会让项目组所有人评审，以及制作一个和业务场景类似的 demo ，而且要完善技术相关的工具或者调用。

[kangkang]

若无必要，勿增实体。

[zengyuxi]

看到"刚学习了 consul ，想实践一波"，说出这种话的，如果你是学生，我是鼓励的；但你现在的身份，是企业的一员，说出这种话，我觉得你是在耍流氓。

[otakustay]

@hxndg #76 《 Software Engineering at Google 》，450 块钱一本的好书

[wudaye]

才两个服务节点，你就整个 consul ，站在公司项目利益上肯定是没必要，甚至弊大于利，浪费资源，consul 是不是还得部署多节点保证高可用？单纯想监控两个节点有轻量得多的方案。当人站在个人发展的角度看，你这种面向简历开发的思路是无可厚非的

[ccyixia]

mark 一下，以后谁给我整幺蛾子，就发这篇给他看。

没有嘲讽 lz 的意思，人都会有成长的过程。lz 明显踩过的坑不够多，试想一下，万一 consul 出了严重 bug 导致服务中断，你半夜被电话喊起来或者节假日紧急 oncall ，google 半天毫无收获结果发现项目 github 里躺着一个没有 close 的 issue 恰好是你遇到的问题。。。相信我，你那时会很想穿越到现在扇自己两巴掌，后悔没有听组长的话。

[IvanLi127]

@nicebird 那得看多久被发现，上线几个月了才被发现，可没人敢开除的喔🤔

[struggletoday]

@bwensun 想知道 组长到场了没 🐶

[Carver9527]

@otakustay 请问一下，这段决策的出处有吗，想进一步的了解

[Real00]

奥卡姆剃刀定理

[arthas2234]

要使用新的东西，必须组内讨论经过组长的同意才用。
浪费资源就不说了
项目不是你一个人的，也得要考虑组内其他人是否熟悉这个东西，以免你不在的时候出现问题，其他人不能及时解决

[otakustay]

@Carver9527 #94 就《 Software Engineering at Google 》这本书

[qixcoder]

考虑 ROI 吧

[qfdk]

其实解决问题方式很多种，团队合作必需要大家都熟悉才能维护一个系统的稳定，如果这个系统只有你来做，里面 bug 出现了 处理的问题，哪天你走了，这个就成了烂尾项目了，后面如何维护。主要是引入了一个 consul 不知道里面有多少的坑。想到以前引入了一个 Eureka 都折腾了一阵子。自己的分布式项目也搞了好久，才发现里面很多门道。 然后你做完了之后要不然还要写完整的文档。。。

[gerorim]

@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?