拆分微服务注意的问题

不少中小规模的技术团队对微服务的概念都不甚了解,对该不该引入微服务也不置可否。还有一些技术团队,没有考虑实际业务场景,只是为了追求技术热点,盲目引入微服务,但又缺乏相应的技术掌控能力,最后影响了业务的稳定性。千万不要为了微服务和使用微服务,因为拆分微服务带来很多复杂性,所以在拆分微服务之前,想明白以下问题该如何解决。

1)服务如何定义  (swagger)

2)服务如何发布定义  (注册中心)

3)服务如何监控     (dashboard)

4)故障如何定位     (链路追踪)

5)服务如何治理    (熔断)

并不是说功能拆分的越细越好,过度的拆分反而会让服务数量膨胀变得难以管理,因此找到符合自己业务现状和团队人员技术水平的拆分粒度才是可取的。我建议的标准是按照每个开发人员负责不超过 3 个大的服务为标准,毕竟每个人的精力是有限的,所以在拆分微服务时,可以按照开发人员的总人数来决定。

转载于:https://my.oschina.net/u/2610056/blog/3041750

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在我们的项目中,我们使用了微服务架构来拆分和组织我们的系统。Microservice架构是一种将应用程序拆分为一组小型、独立的服务的方法,每个服务都可以独立部署、扩展和管理。以下是我们在拆分微服务时采取的一些步骤和原则: 1. 领域驱动设计(DDD):我们首先使用领域驱动设计方法来划分业务领域。每个领域都被看作是一个微服务的潜在候选对象。 2. 服务边界划分:我们通过识别业务功能和领域边界来划分服务。我们将相关的业务功能组合在一起,以确保每个服务都有明确的责任和边界。 3. 单一职责原则:我们遵循单一职责原则,即每个微服务应该只负责一个独立的业务功能。这有助于保持服务的内聚性和可维护性。 4. 松耦合和高内聚:我们将注意力放在确保微服务之间的松耦合和高内聚上。松耦合意味着每个服务都应该能够独立开发、测试、部署和扩展,而不会对其他服务产生过多的依赖。高内聚意味着每个服务应该包含与其业务功能相关的所有代码和数据。 5. 服务通信:我们使用轻量级的通信机制,如RESTful API或消息队列,来实现微服务之间的通信。这种方式可以确保松耦合和可扩展性。 6. 持续集成和部署:我们采用持续集成和自动化部署的方法,以便快速、频繁地发布和更新微服务。这有助于加快开发迭代周期,并降低发布新功能的风险。 总的来说,我们在拆分微服务时遵循了领域驱动设计和一些基本的架构原则,以确保每个微服务都具有清晰的责任和边界,并且能够独立开发、测试和部署。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值