微服务的基础知识

微服务与整体式（Microservices vs Monolishs）

• 分离的上下文：微服务是围绕特定的业务功能设计的，允许更集中和模块化的开发。相比之下，单体应用将整个内容捆绑到单个仓库下。

• 技术灵活性：每个微服务都可以选择最适合其用途的技术栈，这与单体式应用不同，单体式应用通常局限于单个技术栈，

• 风险管理：部署微服务的风险可能较低，因为对一项微服务的更改不会影响到其他的服务。但是整体式应用的一个小更改可能会影响到整体系统。

• 团队组织：微服务可以使团队围绕单个服务进行组织，从而促进所有权和问责制。整体式应用通常需要查看复杂的的代码仓库，这使得分离职责变得困难。

• 初始复杂性：由于需要明确的边界和基础设施来实现服务间通信，因此微服务开始也许会很复杂，另一方面，整体式应用可能更容易启动，丹随着它们的增长可能会变得笨拙。

何时使用微服务架构

• 扩展团队：当多个团队需要同时处理系统的不同部分时

• 明确定义的上下文：当业务区域或上下文被明确划分时

• 成熟的交付流程：具有已建立CI/CD的管道和测试框架的组织

• 技术成熟度：具有管理分布式系统复杂性的专业知识的团队

• 选择可扩展性：当只有系统的部分需要扩展时

• 技术多样性：当系统的各个地方需要不同的技术来实现最佳的性能时

何时使用整体式架构

• 概念验证（POC）：快速迭代和验证，无需多个服务的开销

• 新项目：当域不完全了解并且预期内会发生快速变化时

• 简化治理：更易于管理和实现技术和实践的一致性

• 易于招聘和培训：使用统一的代码库可以让开发人员更快的上手项目

• 共享库：更轻松的在单个代码库中共享和维护公共库

从整体式架构迁移到微服务架构

• 分离式上下文（DDD）：使用域驱动设计来识别和分离上下文

• 避免过大力度：确保服务足够大，可以独立管理，但不要太精细

• 依赖项管理：避免创建服务之间紧密耦合的分布式单体应用

• 数据库迁移：规划数据库如何迁移并确保数据的一致性和完整性

• 使用事件：使用事件驱动架构来实现更好的解藕

• 数据复制：必要时不要回避复制数据

• 最终一致性：接收最终一致性而不是立即一致性

• 成熟的CI/CD：确保强大的CI/CD、测试和环境管理

• 从小处入手：使用Strangler模式从不太重要的域开始，逐步替换整体式架构的某些部分

微服务的特征

• 通过服务进行组件化：每个服务都是一个负责特定功能的组件

• 业务一致：服务围绕业务功能进行组织，并由跨职能团队进行管理

• 产品心态：将每一项服务都视为一个产品，注重之后的迭代和持续改进

• 智能端点，哑管道（Smart Endpoints, Dumb Pipes）：服务通过简单的直接消息进行通信，无需中介

• 去中心化治理：团队选择最好的技术并建立明确的通信制度

• 分散式数据管理：允许多个数据库，并仔细管理数据重复

• 基础设施自动化：自动化基础设施以处理分布式服务的复杂性

• 为故障而设计：构建能够优雅处理故障的弹性系统

• 进化设计：设计服务可进行独立的更换和升级

结论

原文链接

Are Microservices the Right Choice for You?

Microservices have emerged as a transformative architectural style. As I delve deeper into software...

https://dev.to/v1eira/are-microservices-the-right-choice-for-you-3l6j