不少中小规模的技术团队对微服务的概念都不甚了解，对该不该引入微服务也不置可否。还有一些技术团队，没有考虑实际业务场景，只是为了追求技术热点，盲目引入微服务，但又缺乏相应的技术掌控能力，最后影响了业务的稳定性。千万不要为了微服务和使用微服务，因为拆分微服务带来很多复杂性，所以在拆分微服务之前，想明白以下问题该如何解决。
1）服务如何定义 （swagger）
2）服务如何发布定义 （注册中心）
3）服务如何监控 （dashboard）
4）故障如何定位 （链路追踪）
5）服务如何治理 （熔断）
并不是说功能拆分的越细越好，过度的拆分反而会让服务数量膨胀变得难以管理，因此找到符合自己业务现状和团队人员技术水平的拆分粒度才是可取的。我建议的标准是按照每个开发人员负责不超过 3 个大的服务为标准，毕竟每个人的精力是有限的，所以在拆分微服务时，可以按照开发人员的总人数来决定。
扫一扫
171万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
