11、微服务架构实现全解析

微服务架构实现全解析

微服务实现概述

微服务的实现涵盖多个关键方面，包括系统架构设计、整合与通信、单个微服务架构设计、测试、运维与持续交付，以及对组织的影响等。

微服务系统架构

微服务系统架构聚焦于各微服务之间的交互，主要包含领域架构和技术架构。
- 领域架构 ：它决定了系统内哪些微服务应实现哪些领域，将整个领域划分为不同区域，每个区域由一个微服务及一个团队实现。设计领域架构是引入微服务的主要挑战之一，合理的设计能使对领域的更改仅由一个团队修改一个微服务来完成，减少团队间的协调与沟通。
- 战略设计与领域驱动设计 ：基于战略设计分配微服务，将其分布到代表不同功能的上下文中。但常见的基于领域模型实体开发微服务架构的方法存在问题，如将客户、物品和交付分别用不同微服务实现，在修改流程时会导致多个微服务的更改。为避免这种情况，可将某些数据保留在相关流程的微服务中。
- 示例：Otto 商店 ：Otto 商店的架构包含面向数据的服务（如用户、订单和产品）和面向功能的区域（如跟踪、搜索导航和个性化），这是微服务系统应追求的领域设计类型。
- 管理依赖关系 ：管理微服务之间的依赖关系对系统架构至关重要。以下是两个重要规则：
- 松耦合 ：微服务之间的耦合应松散，即每个微服务对其他微服务的依赖应较少，这样修改时仅影响单个微服务。
- 高内聚 ：微服务内部的组成部分应紧密协作，确保所有部分真正属于一个整体。
- 意外的基于领域的依赖关系 ：某些基于领域的依赖关系可能不合理，如电商系统中产品搜索团队与计费微服务有接口。当依赖关系从领域角度无意义时，需检查微服务的功能实现是否正确，必要时移除或调整依赖。
- 循环依赖 ：循环依赖会给架构带来问题。例如，订单流程微服务调用计费微服务，计费微服务又从订单流程微服务获取数据。这种情况下，两个微服务的更改相互影响，无法独立修改，还可能需要协调部署。
- 技术架构 ：微服务的技术架构包含一些典型挑战，多数情况下有中央配置和协调，负载均衡器在微服务的各个实例间分配负载。安全架构要保证每个微服务能自由实现自身授权，同时确保用户只需登录一次。此外，微服务应返回自身信息作为文档和元数据。

微服务的整合与通信

微服务之间的整合与通信有三种可能级别：
1. Web 级别整合 ：每个微服务提供部分 Web UI。
2. 逻辑级别通信 ：通过 REST 或消息传递进行通信。
3. 数据复制 ：可实现数据在微服务间的复制。

微服务通过这些技术拥有内部接口，整个系统可以有一个对外接口。不同接口的更改会带来不同挑战，因此还需处理接口的版本控制及其影响。

单个微服务架构

单个微服务有不同的架构设计方法：
- CQRS（命令查询职责分离） ：将读写访问分为两个独立服务，实现更小的服务和两部分的独立扩展。
- 事件溯源 ：通过事件流管理微服务的状态，可从中推导出当前状态。
- 六边形架构 ：微服务有一个核心，可通过不同适配器访问，并通过适配器与其他微服务或基础设施通信。

每个微服务可遵循独立的架构，但都要处理如弹性和稳定性等技术挑战。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(CQRS):::process --> B(读写分离):::process
    C(事件溯源):::process --> D(事件流管理状态):::process
    E(六边形架构):::process --> F(核心通过适配器交互):::process

微服务的测试

微服务的测试需要考虑其特殊挑战。测试的必要性在于确保系统的正确性和稳定性，同时微服务作为小的部署单元，降低了部署风险，优化部署也有助于进一步降低风险。

在测试整个系统时，由于每次只能通过一个微服务进行测试，如果测试耗时较长，会严重限制部署次数。例如，若测试持续一小时，一个工作日最多只能进行八次部署，对于 50 个微服务的系统来说远远不够，因此需要尽可能限制此类测试。

当微服务替换遗留系统时，需要对微服务、遗留系统及其交互进行测试。微服务的测试与其他软件系统的测试在某些方面有很大差异。

消费者驱动的契约测试是微服务测试的重要组成部分，它测试微服务对接口的期望，可确保微服务之间的正确交互，而无需在集成测试中一起测试。具体操作是一个微服务在测试中定义其对接口的要求，供被使用的微服务执行。

此外，微服务在监控和日志记录方面需遵循一定标准，这些标准也可通过测试进行检查。

微服务的运维与持续交付

引入微服务时，基础设施是关键挑战。以下是运维与持续交付的几个重要方面及相应的技术和方法：
1. 统一的日志记录和监控 ：所有微服务需统一实现日志记录和监控，否则会增加管理成本。可采用集中式日志管理系统收集和分析日志，使用监控工具实时监控微服务的性能和状态。
2. 统一的部署 ：实现统一的部署方式，确保微服务的部署过程一致且高效。可以使用容器化技术（如 Docker）将微服务打包，使用编排工具（如 Kubernetes）进行部署和管理。
3. 统一的启停控制 ：微服务应能通过简单的控制实现统一的启动和停止。可以使用自动化脚本或管理平台来实现这一功能。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(统一日志记录和监控):::process --> B(集中式日志管理系统):::process
    A --> C(监控工具):::process
    D(统一部署):::process --> E(Docker 容器化):::process
    D --> F(Kubernetes 编排):::process
    G(统一启停控制):::process --> H(自动化脚本):::process
    G --> I(管理平台):::process

微服务对组织的影响

微服务使任务更易于分配给独立团队，实现不同功能的并行开发。团队需根据任务分配对微服务进行相应更改。然而，新功能可能涉及多个微服务，这就需要团队之间进行大量协调，可能会延迟新功能的实现。因此，团队之间也可以对其他团队的微服务进行更改。

微服务将架构分为微观架构和宏观架构。在微观架构方面，团队可自行决策；而宏观架构则需为所有微服务进行定义和协调。在运维、架构和测试等领域，可将具体方面分配给微观或宏观架构。

DevOps 作为一种组织形式与微服务非常契合，因为运维和开发之间的紧密合作对于基础设施密集型的微服务尤为重要。

独立团队需要从领域中推导各自的独立需求，这也体现了微服务在这些方面的影响。此外，代码复用也是一个组织问题，团队需要协调共享组件的不同需求，受开源项目启发的模型可能会有所帮助。

同时，也需要思考在不进行组织变革的情况下是否能够引入微服务，毕竟独立团队是引入微服务的重要原因之一。

综上所述，微服务的实现涉及多个层面，从架构设计到测试、运维和组织影响，每个环节都相互关联且至关重要。在实际应用中，需要综合考虑各方面因素，以充分发挥微服务的优势。