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

本篇文章转自微软官网技术文档。设计原则，优缺点等都总结的很好，非常值得阅读收藏，欢迎关注我。

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

在某些方面，微服务是面向服务的体系结构 (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 终止等跨领域操作分流到网关。
• 让网关不必了解域。 网关应处理和路由客户端请求，而无需了解业务规则或域逻辑。 否则，网关会变成一个从属物，从而导致服务之间耦合。
• 服务应具有松散耦合和高功能内聚的特点。 应当将可能会一起更改的函数打包并部署在一起。 如果它们驻留在不同的服务中，这些服务最终会紧密耦合，因为一个服务中的更改将需要更新其他服务。 两个服务之间的通信过于频繁可能是紧密耦合和低内聚的征兆。
• 隔离故障。

转自：https://docs.microsoft.com/zh-cn/azure/architecture/guide/architecture-styles/microservices

文章来源: https://www.toutiao.com/group/6731222500824318477/