微服务架构设计实践

本文探讨了微服务架构的设计原则,包括职责单一原则、业务范围界定,以及微服务消息设计,如同步与异步消息。同时,文章还讨论了微服务集成方式,如API网关和消息代理,并强调了数据去中心化、治理去中心化的重要性。此外,介绍了服务注册与发现、安全策略(OAuth2、OpenID)、事务处理和容错设计,以及微服务在企业集成和API管理中的角色。
摘要由CSDN通过智能技术生成

微服务架构的核心思想是,一个应用是由多个小的、相互独立的、微服务组成,这些服务运行在自己的进程中,开发和发布都没有依赖,因此构建微服务绝不是在单体架构中把服务拆分开这么简单。

一、微服务设计:规模、范围、业务功能

你可能从零开始用微服务来构建应用,也可能重构现有系统,确定微服务的规模,范围和功能都特别重要。让我们讨论一些有关微服务设计的关键问题和对它的误解:

  • “微”很容易被误解:很多开发者会倾向于把服务往尽量小的颗粒度去做
  • 在SOA方式下,服务都还是以单体架构在运行,用于支持不同的功能。如果依旧采用SAO类似的服务,仅仅是名义上叫做微服务,并不能带来任何微服务的优势。

那我们在微服务中应该怎样设计呢。以下是微服务的设计指南:

  • 职责单一原则(Single Responsibility Principle):把某一个微服务的功能聚焦在特定业务或者有限的范围内会有助于敏捷开发和服务的发布。
  • 设计阶段就需要把业务范围进行界定。
  • 需要关心微服务的业务范围,而不是服务的数量和规模尽量小。数量和规模需要依照业务功能而定。
  • 于SOA不同,某个微服务的功能、操作和消息协议尽量简单。
  • 项目初期把服务的范围制定相对宽泛,随着深入,进一步重构服务,细分微
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

wespten

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值