这是一个创建于 78 天前的主题，其中的信息可能已经有所发展或是发生改变。
模块化？解耦？独立库？分布式可扩展？
做了这么多年野路子开发，感觉自己还是不知道怎样的微服务才算是一个优秀的微服务
做了这么多年野路子开发，感觉自己还是不知道怎样的微服务才算是一个优秀的微服务
 | 1 CodeCodeStudy 78 天前 高内聚，低耦合。将相同功能的放在一起，尽可能减少对外部的依赖。微服务一定要“微”，如果还是启动半天，占用内存很大的话就不叫微服务了。 |
 | 2 yalin 78 天前 没有微服务 |
 | 3 mamtou 78 天前 via Android 稳定 |
 | 4 fish2050 78 天前 比如 xx 一体化系统，涉及 xx 业务的工单子系统、设备子系统、营收子系统、物资子系统等等， 每个子系统，都是一个“微服务”，然后前端统一门户，每个子系统单独的界面统一登陆跳转。 |
 | 5 SSang 78 天前 微服务就不可能优秀 |
| 6 SSang 78 天前 “微服务已死” 虽然说的有些严重了，但并没有太多夸张的成分。服务架构永远不可能存在公式，你的需求千奇百怪，资源也在不断变化。如果你的问题原本的架构解决不了，那换成微服务，大概率也解决不了。没有任何一个架构是银弹，有的只是符合当下需求。 |
 | 7 homewORK 78 天前 全套自动 CICD ，流程规范并已落地 |
 | 9 lyusantu 78 天前 独立部署、快速迭代、稳定运行 |
| 10 SSang 78 天前 康威定律说：organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. M. Conway （一个组织的系统通常被设计成这个组织通信结构的副本） 微服务起源与大型团队多人协作，你先看看你的团队有几个人。如果就两个开发有什么可微的呢？ 我相信，b 站，京东，阿里，一定还用着微服务架构，因为这能解决他们的问题，但对于你的团队呢？能解决什么问题？你不知道怎样的微服务才算优秀，那你有没有考虑过你们团队，你们的项目根本不适合使用微服务呢？ |
 | 11 xomix 78 天前 微服务 12 守则，能够在保障业务的前提下尽量多的满足守则的服务就是好的微服务。 |
 | 12 xuanbg 78 天前 运行稳定、扩容方便、维护简单 |
 | 13 spritecn 78 天前 一定要微? 一个服务不说一个团队负责吧,至少得有一个人负责,微到一个表起一个服务,那? 公司有多少人? |
| 14 SSang 78 天前  1 微服务设计本身并没有优劣之分，只有适合和不适合。团队有三四个人时，或服务规模扩张时，大单体可以拆成小单体，避免代码的互相腐蚀。再随着规模扩大，小单体可以拆的更小，就变成了微服务。 微服务更多的是反应的团队协作问题，而在架构设计上，微服务理念并不一定是直接体现在服务拆分上的。 事实上，你可以看看主流的架构，无论哪个架构，都在提倡 “高内聚、低耦合”，所以，微服务的 “思想” 并不是一个专利，你仍然可以在单体服务上贯彻微服务理念。“解耦本身就是优秀” 至于你说的独立库，更多的是管理上的东西，你看 K8S ，也在使用巨型仓库，但他们有优秀的上下游管理自动化脚本。所以不是说你独立了仓库就一定是最好的，工程化不是一套公式就能打完的。 而你说的分布式、可扩展，这更多的是服务拓扑，你总不能说大单体就不能分布式，就不具备扩展性，很多设计优秀的大单体，他的扩展性能远超微服务。 |
 | 16 sky3hao9 78 天前 微服务的最佳实践需要天时地利人和, 公司项目要大, 技术要懂, 而且前期有设计规划时间, 架构师要牛逼, 领导要支持.. 我也算经历过几个大公司, 微服务的实践都很操蛋. |
 | 17 opengps 78 天前 以上指标都是虚的，优秀意味着用的久用的多 |
| 18 opengps 78 天前 实用性永远第一 |
 | 20 micean 78 天前 单体万岁 doge |
 | 21 frank42a 78 天前 不一定微服务，做集群就可以了 |
 | 22 nealHuang 78 天前 one-pizza team 规模都达不到的团队，感觉还是少碰微服务微妙，做集群横向扩展就好 |
 | 23 jeristiano 78 天前 @yalin 是的，尽量不用微服务，就连微服务的首创者被问到什么才是最好的微服务，如何践行 DDD ，他的回答意味深长： 要看程序员的经验。 |
 | 24 monkeyWie 78 天前 微服务不如 monorepo ，特别是在小公司 |
 | 25 kdd0063 78 天前 microservice 本质不是技术问题，而是管理问题。这一点都还没想明白的话建议别上 |
 | 26 fffq 78 天前 技术架构 约等于 公司架构 |
 | 29 testcgd 78 天前 via Android 1 什么是好的微服务不太理解，我觉得不好的微服务有几个特点吧 1 、服务数量多过维护人数的 2 、加逻辑要改 n 个服务的 3 、新人不知道某个逻辑在那个服务的 |
 | 30 Roan 78 天前 鲁棒性，错误恢复 |
 | 31 sighforever 78 天前 @SSang 真不一定，小团队经常要把一堆开源软件改吧改吧和部署上，这时候每个开源软件就是个微服务，甚至多个微服务。 |
 | 32 027creed 78 天前 杂交怪，苹果树上长香蕉，能用就行呗！ |
| 34 yalin 78 天前 还得是 v 友水平高，谈微服务能谈到康威定律。感觉现在国内用微服务的人，都不一定知道谈康威定律了 |
 | 35 yb2313 78 天前 说到微就想到 min,说到服务就想到 service, 想到 soft, 就想到 Microsoft, 邪恶的微软 |
36 james122333 78 天前 via Android 答案是没有 所谓的微服务只是把现有流行的东西串起来使用而已 组件肯定不轻 然后用 http... 分布式系统是种大范畴 微服务被包含在里面而已 解决方案并不漂亮 只是跨平台 |
 | 37 aarontian 77 天前 首先我觉得野路子是好词，因为我也是野路子，有技术热情才会走野路子。 微服务是更适合互联网大厂的架构，对基建成熟度、业务体量、团队规模都有要求，都不满足或者只满足一点的，没必要硬上。服务微到一定程度一定是灾难，因为不可能在拆得很细的情况下还能保证高内聚低耦合。之前在某大厂合并过一堆微服务，二合一三合一七八合一一堆，这还是我一个人干的活，相信类似的事很多人都干过，算是擦屁股了。合并后维护成本低的不是一点。事实证明四五个人在一个 repo 中协同开发，一点都不比分离开困难（当然 repo 跟服务也不是一回事）。 29L 老哥已经描述了我们当时踩过的坑了。另外第二点“加逻辑要改多个服务”，也可以再加个“改实体”。 具体怎么拆我感觉凭业务理解和直觉的多一点，但一个笼统的想法是，在你没有想好是不是有必要拆、没有想明白拆的原因/边界的时候，那就别拆。 |
 | 38 nrtEBH 77 天前 取决于业务架构 这年头也很多大厂用巨型单体架构 不是说哪种方案是最好的 只有最适合的 it always depends on your business |
Select Language