用户您好!请先登录!

微软关于微服务体系结构的理解

微软关于微服务体系结构的理解

微服务体系结构由一系列小型的自治服务组成。 每个服务都是自包含服务,并且应实现单个业务功能。

微软关于微服务体系结构的理解

在某些方面,微服务是面向服务的体系结构 (SOA) 的自然演变,但微服务与 SOA 之间也存在一些差异。 下面是微服务的一些典型特征:

  • 在微服务体系结构中,服务具有规模小、独立和松散耦合的特点。
  • 每个服务都是一个单独的基本代码,可由小型开发团队管理。
  • 服务可独立部署。 团队可以更新现有服务,而无需重新生成和重新部署整个应用程序。
  • 服务负责暂留自己的数据或外部状态。 这一点与传统模型不同,后者由单独的数据层处理数据暂留。
  • 服务通过定义完善的 API 相互通信。 每个服务的内部实现细节均对其他服务隐藏。
  • 服务无需共享相同的技术堆栈、库或框架。

除了服务本身,典型微服务体系结构中还会出现其他组件:

管理。 管理组件负责将服务放置在节点上、标识故障、跨节点重新平衡服务等等。

服务发现。 维护一个包含服务及其所在节点的列表。 支持使用服务查找功能查找服务的终结点。

API 网关。 API 网关是客户端的入口点。 客户端不直接调用服务, 而是调用 API 网关,网关再将调用转发到后端上的相应服务。 API 网关可以聚合来自多个服务的响应,并返回聚合的响应。

使用 API 网关的优点如下:

  • 它分离了客户端与服务。 无需更新所有客户端,便可对服务进行版本控制或重构。
  • 服务可以使用对 Web 不友好的消息传递协议,比如 AMQP。
  • API 网关可执行身份验证、日志记录、SSL 终止和负载均衡等其他跨领域功能。

何时使用此架构

请对以下情况考虑使用此体系结构样式:

  • 需要较高发布速度的大型应用程序。
  • 需要高度可缩放的复杂应用程序。
  • 具有大量域或多个子域的应用程序。
  • 由小型开发团队组成的组织。

优点

  • 独立部署。 无需重新部署整个应用程序便可更新服务,出现问题时可回滚或前滚更新。 Bug 修复和功能发布更易管理,风险更低。
  • 独立开发。 单个开发团队便可生成、测试和部署服务, 从而推动持续创新,加快发布节奏。
  • 小型专属团队。 团队可专注于一个服务。 缩小每个服务的范围后,基本代码变得更好理解,新的团队成员也能更快上手。
  • 错误隔离。 某个服务中断不会影响整个应用程序。 但是,这并不意味着用户可以无偿复原。 用户仍需遵循复原最佳做法和设计模式。 请参阅设计可靠的 Azure 应用程序。
  • 混合技术堆栈。 团队可选取最适合其服务的技术。
  • 精细缩放。 服务可独立缩放。 与此同时,每个 VM 的较高服务密度也意味着 VM 资源得到充分利用。 使用放置约束,可将服务与 VM 配置文件(高 CPU、高内存等等)匹配。

挑战

  • 复杂性。 与同等的单一式应用程序相比,微服务应用程序具有更多移动部件。 每个服务更简单,但整个系统作为整体来说更复杂。
  • 开发和测试。 针对服务依赖关系的开发需要采用不同的方法。 现有工具不一定能处理这些服务依赖关系。 跨服务边界进行重构可能很困难。 测试服务依赖关系也有一定难度,尤其是在应用程序快速发展之时。
  • 缺乏监管。 用于生成微服务的分散式方法具有一定优势,但也可能导致许多问题。 用户在生成过程中可能采用了许多不同的语言和框架,从而使应用程序变得难以维护。 这种情况下可以实施一些项目范围内的标准,不过分限制团队的灵活性。 这尤其适用于日志记录等跨领域功能。
  • 网络拥塞和延迟。 使用大量小型的精细服务可能会增加服务间的通信量。 此外,如果服务依赖关系链变得太长(服务 A 调用 B,B 调用 C…),额外延迟可能会成为一个问题。 用户需要精心设计 API。 应避免过于繁琐的 API,考虑使用序列化格式,并找到可以使用异步通信模式的地方。
  • 数据完整性。 每个微服务负责其自己的数据持久性。 因此,数据一致性可能是个挑战。 如果可能,请采用最终一致性。
  • 管理。 成功使用微服务需要有成熟的 DevOps 区域性。 跨服务的关联日志记录可能很难。 通常情况下,日志记录必须为单个用户操作关联多个服务调用。
  • 版本控制。 对某个服务的更新不应中断依赖于它的其他服务。 多个服务可在任意给定时间更新,因此,若不精心设计,可能会遇到向后或向前兼容性问题。
  • 技能组合。 微服务是一种高度分布式系统。 请仔细评估团队是否具有成功使用微服务所需的技能和经验。

最佳做法

  • 围绕业务域对服务建模。
  • 分散所有资源。 单个团队负责设计和生成服务。 避免共享代码或数据架构。
  • 拥有数据的服务应当有专用的数据存储。 为每个服务和数据类型使用最合适的存储。
  • 服务通过设计完善的 API 进行通信。 避免泄露实现细节。 API 应对域建模,而不是对服务的内部实现建模。
  • 避免服务之间耦合。 耦合的原因包括共享的数据库架构和严格的通信协议。
  • 将身份验证和 SSL 终止等跨领域操作分流到网关。
  • 让网关不必了解域。 网关应处理和路由客户端请求,而无需了解业务规则或域逻辑。 否则,网关会变成一个从属物,从而导致服务之间耦合。
  • 服务应具有松散耦合和高功能内聚的特点。 应当将可能会一起更改的函数打包并部署在一起。 如果它们驻留在不同的服务中,这些服务最终会紧密耦合,因为一个服务中的更改将需要更新其他服务。 两个服务之间的通信过于频繁可能是紧密耦合和低内聚的征兆。
  • 隔离故障。
X-Eyes Admin
X-Eyes Admin

要发表评论,您必须先登录