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