5、微服务架构构建与云原生应用实践

微服务架构构建与云原生应用实践

1. 微服务建模中的反模式

在微服务开发中，通过共享代码来创建紧密依赖是一种反模式。在面向对象编程（OOP）里，我们常遵循“不要重复自己”（DRY）原则。在非微服务架构中，创建可在其他项目或组件中复用的外观或类是个好模式，但在微服务架构中就成了反模式。

例如，在在线拍卖系统（OAS）中，有用于创建拍卖、列出活跃拍卖和根据最高出价者授予拍卖的拍卖服务，还有用于对拍卖进行出价的出价服务。若想在出价服务中使用拍卖管理服务的现有功能来读取活跃拍卖列表，当两个服务的底层技术相同时，可能会在出价服务中添加对拍卖服务项目的引用并使用其功能。然而，这种做法会使拍卖服务和出价服务之间产生紧密依赖，一旦拍卖服务有更新，出价服务也需要重新编译。

在微服务中，所有通信应通过直接通信（如 HTTP/HTTPS）或事件驱动的消息系统进行。保持服务间的紧密依赖是反模式，应尽量避免。

2. 云原生应用概述

云原生应用围绕托管在云中的各种云技术或服务构建。微服务应用是松散耦合且细粒度的服务，托管在单独的端点上，通过轻量级协议进行通信。与云就绪应用不同，云原生应用能在所有公共、私有和混合云环境中提供一致的体验。

云原生应用有四个主要原则：
- DevOps ：是一系列实践，能让人员、流程和技术协同工作，为客户提供价值，帮助不同角色有效协作，高效响应客户需求。
- 持续交付 ：是一种软件工程方法，能使软件随时可发布到生产环境。通过在开发团队提交更改后自动化应用的构建过程、运行多次测试并发布工件以部署到暂存或生产环境来实现。