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

[bwensun]

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

[bwensun]

@masterclock 是的 这个后面也改回来了 但是引发我的思考 想问问兄弟萌都是怎么处理这样问题的呢

[Nich0la5]

@bwensun 我 leader 对我就一个要求 别延期， 实践起来就是开发文档之外的事情尽量不要做（不然我还有时间在 v 站吹逼吗），骚操作可以做，但是要放到下一期评审里面评估一下是否有意义。稳定性其实是其次的，如果没被毙掉就可以做，想不毙掉就得证明你这么改动的价值。像这个任务，你自己都说明不了它的必要性，评审怎么能通过呢。

[br_wang]

组长这么说可能是他觉得「杀鸡用牛刀，后面你要是不维护了我还得替你擦屁股」。所以，如果你不是只是一时兴起，可以把基于这个架构的中期计划跟他聊聊，明确下后面的路线和规划，可能会好一点。

老板怕得不就是「不确定性」么。让他了解你的意图和你有计划就好。别着眼于当前状况的解释。

[sujin190]

java 这一套的话，反正更新重启一下十分钟过去了也不止，所以两个节点也想用注册中心也可以理解，否则真没啥必要，否则节点数比较少服务也少也搞似乎是个坑，大炮打蚊子可不但没提高生成效率反而坑死人的了

[zliea]

就一个微服务？我是组长，我也不想让你搞； 10 个微服务再搞吧。

[Ackvincent]

能用就行了，好歹给后边人留点空间。

[charlie21]

别延期是可以的

[Cielsky]

@ospider 永远不上那永远学不会啊，这不是死循环了

[bwensun]

@Nich0la5 嗯 基本想法一致 说明必要性这块可有的说（我以前在警校写报告拿满分--黎明）另外我觉得新的东西出来自然有它对于传统的东西的优势，我们不应该向前看嘛 很多时候只是习惯于某某而不是真的有足够大的理由停留在之前的样子 我不是说我现在说的项目 就是说在我们工作中

[Mogugugugu]

你离职了，谁来接手？

[bwensun]

@ztechstack 哭

[jtwor]

反手加个网关上个鉴权中心全上 grpc 弄个 elk 日志中心搭套容器编排自动部署 狗头)

其实这些一堆中间件学习难度一般，基本搭一次就大概懂了，如果工地的业务不大没必要上微服务，基本都会否决使用的，学习和维护都是需要成本的，不是所有公司都愿意投入。还是自己项目练练，后面跳大点公司把，如果是开源的最好看看源码，学习是学习，搬砖是搬砖。

[joyhub2140]

跟着团队走。。。商业项目不是试错场地，除非有人负责。。。

[bwensun]

@Mogugugugu 那这不得看人嘛 说走提包就走呀

[bwensun]

@br_wang 嗯嗯

[nbndco]

非常严重的过度设计。



有人说这种东西需要组长决定，或者公司不是来让你学习的，反而不应该是考量因素。大家天天问怎么提升薪水，你天天就乖乖听组长分配的任务堆 CRUD ，其他不闻不问不学习，真的能加薪吗？

真正关键的是，你要解决什么问题，以及如何解决问题。

就你描述的情况本身，一个服务两个节点，看起来也不像是会有很大的增长的样子，那么就不存在 service mesh 的应用场景。也就是说，你没有解决任何问题，只是单纯的引入了一个新的（大）问题——设置管理维护 consul ，组长只是提醒你不要过度设计，也是有问题的，要是我就直接让你全撤了。你要意识到，你的实践一定是实践如何用 consul 解决问题，不是使用 consul ，你要用 consul 你自己搭个 k8s 就好了。

所以这样做就没有意义么，也不是。这就取决于你要解决什么问题。

你说你现在做的是一个微服务，那就意味着公司里有很多其他的微服务。你说你在使用 consul ，那就意味着公司现在并没有任何的 service mesh 方案，考虑到 consul 和 k8s 绑定之紧，我甚至可以猜测整个公司的服务部署都是完全独立各组自行管理的。这显然是一个错误的方案，缺乏正确微服务架构的特性。那么，要不要提升，要不要改，要不要用 consul ，我觉得是很值得考虑的。

有人肯定又要说这种事情推不动，大家都只想堆 CRUD 。那我也没啥可说的，这个时候我只能反省为何我会加入这种公司了。

[Bigglesworth]

还好，也不是完全没用

[pigspy]

我们这边，微服务调用链啥，整体部署结构，都要经过评审，不允许自己随便弄
这样也方便出问题甩锅

[RudyS]

任何事都应尽量简单，但不宜过于简单。---爱因斯坦

[otakustay]

摘录一下 Google 选择引入一个依赖时的决策条款，用于对任何技术做还是不做的评估都有用：

- 是不是有测试，并且使用者可以自己跑起来测试
- 测试是不是通过的
- 谁开发的这个库
- 承诺怎么样的兼容性
- 作者有没有详细地说清楚这个库期望用在什么场景下
- 这项目有多流行
- 我们大概会有多长时间要依赖这个包
- 在历史上这个包搞出来破坏性变更的频率是怎么样的
- 我自己来实现这个依赖的功能的话有多复杂
- 让这个依赖保持版本跟进是不是必要的
- 以后谁来更新依赖的版本
- 这个依赖的版本更新难不难