怎样才算是一个优秀的微服务

[rehoni]

模块化？解耦？独立库？分布式可扩展？
做了这么多年野路子开发，感觉自己还是不知道怎样的微服务才算是一个优秀的微服务

[CodeCodeStudy]

高内聚，低耦合。将相同功能的放在一起，尽可能减少对外部的依赖。微服务一定要“微”，如果还是启动半天，占用内存很大的话就不叫微服务了。

[yalin]

没有微服务

[mamtou]

稳定

[fish2050]

比如 xx 一体化系统，涉及 xx 业务的工单子系统、设备子系统、营收子系统、物资子系统等等，

每个子系统，都是一个“微服务”，然后前端统一门户，每个子系统单独的界面统一登陆跳转。

[SSang]

微服务就不可能优秀

[SSang]

“微服务已死” 虽然说的有些严重了，但并没有太多夸张的成分。服务架构永远不可能存在公式，你的需求千奇百怪，资源也在不断变化。如果你的问题原本的架构解决不了，那换成微服务，大概率也解决不了。没有任何一个架构是银弹，有的只是符合当下需求。

[homewORK]

全套自动 CICD ，流程规范并已落地

[cookii]

@SSang 人家又没问架构设计，你上来就是微服务已死。

[lyusantu]

独立部署、快速迭代、稳定运行

[SSang]

康威定律说：organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway （一个组织的系统通常被设计成这个组织通信结构的副本）

微服务起源与大型团队多人协作，你先看看你的团队有几个人。如果就两个开发有什么可微的呢？

我相信，b 站，京东，阿里，一定还用着微服务架构，因为这能解决他们的问题，但对于你的团队呢？能解决什么问题？你不知道怎样的微服务才算优秀，那你有没有考虑过你们团队，你们的项目根本不适合使用微服务呢？

[xomix]

微服务 12 守则，能够在保障业务的前提下尽量多的满足守则的服务就是好的微服务。

[xuanbg]

运行稳定、扩容方便、维护简单

[spritecn]

一定要微? 一个服务不说一个团队负责吧,至少得有一个人负责,微到一个表起一个服务,那? 公司有多少人?

[SSang]

微服务设计本身并没有优劣之分，只有适合和不适合。团队有三四个人时，或服务规模扩张时，大单体可以拆成小单体，避免代码的互相腐蚀。再随着规模扩大，小单体可以拆的更小，就变成了微服务。

微服务更多的是反应的团队协作问题，而在架构设计上，微服务理念并不一定是直接体现在服务拆分上的。

事实上，你可以看看主流的架构，无论哪个架构，都在提倡 “高内聚、低耦合”，所以，微服务的 “思想” 并不是一个专利，你仍然可以在单体服务上贯彻微服务理念。“解耦本身就是优秀”

至于你说的独立库，更多的是管理上的东西，你看 K8S ，也在使用巨型仓库，但他们有优秀的上下游管理自动化脚本。所以不是说你独立了仓库就一定是最好的，工程化不是一套公式就能打完的。

而你说的分布式、可扩展，这更多的是服务拓扑，你总不能说大单体就不能分布式，就不具备扩展性，很多设计优秀的大单体，他的扩展性能远超微服务。

[SSang]

@cookii 别急，我还没说完呢。喊 “微服务已死” 的那波人，大多都是小公司，小团队，我想说的是，微服务是不会死的，死的是那些用着微服务的小团队。

[sky3hao9]

微服务的最佳实践需要天时地利人和, 公司项目要大, 技术要懂, 而且前期有设计规划时间, 架构师要牛逼, 领导要支持..
我也算经历过几个大公司, 微服务的实践都很操蛋.

[opengps]

以上指标都是虚的，优秀意味着用的久用的多

[opengps]

实用性永远第一

[Oni0n]

@SSang 认同

[micean]

单体万岁 doge