Spring Cloud Alibaba Best-practice Example with containerized deployment | 容器化部署最佳实践 设计

[TrevorLink]

Chinese version

在 #2565 中，社区初步提出了 Spring Cloud Alibaba 容器化部署最佳实践的背景和需求

针对此 example 的相关的设计点如下

基本业务大纲

在本 demo 示例中，我们提供了两种业务场景

1）用户下单购买货物的场景，下单后

• 先请求库存模块，扣减库存
• 扣减账户余额
• 生成订单信息返回响应

2）用户为商品进行点赞(模拟MQ的生产者消费者应用场景)返回商品点赞后的详细信息（点赞数等）

模块划分

为了便于理解和展示，demo 可以划分为以下的六个模块

• integrated-order 负责创建订单
• integrated-storage 负责扣减库存数量
• integrated-account 负责扣减用户账户余额
• integrated-praise-provider 负责给向MQ投递进行点赞的消息
• integrated-praise-consumer 负责从MQ拉取消息进行消费，向对应商品点赞
• integrated-gateway 所有微服务模块的网关

数据库模型图

参照阿里巴巴编码规约，针对业务设计的 demo 数据库表如下

各个组件应用场景

Spring Cloud Gateway

微服务模块的网关

整合 Sentinel，通过指定断言路由和限流配置规则进行限流

通过监听 Nacos 配置的改变，实现服务网关路由配置动态刷新，每次路由信息变更，无需修改配置文件而后重启服务

Nacos

各个微服务的配置中心，服务注册中心

• 配置中心
  • 共享配置：MySQL 数据源相关信息配置
  • 扩展配置：各个模块独立配置
• 注册信息
  • 所有的微服务模块都注册到 Nacos 中进行服务注册与发现

Seata

用于库存模块，账户模块，订单模块的分布式事务处理

只要库存不足/账户余额不足，回滚事务

Sentinel

用于点赞模块的服务熔断限流

同时整合 Nacos 配置中心，实现熔断限流规则动态配置

RocketMQ

用于进行点赞服务流量的削峰填谷

通过将大流量的点赞请求从生产者发送到 MQ ，消费者模块从 MQ 中拉取进行一定频率的消费，不是简单的直接服务熔断限流降级，实现 RocketMQ 针对大流量的削峰填谷能力

模块接口功能

前端客户端页面

• Seata 分布式事务相关
  • 请求网关进行下单
• Sentinel 限流相关
  • 模拟低流量下单(10)，返回生成的订单信息
  • 模拟高流量下单(100)，进行服务熔断返回响应
  • 模拟低流量点赞(10)，返回点赞成功的商品详细信息（点赞数+10）
  • 模拟高流量点赞(100)，进行服务熔断返回响应
• RocketMQ 削峰填谷相关
  • 模拟高流量点赞，通过将消息投递到 RocketMQ，消费者模块进行一定频率的消费，实现流量削峰

order 订单模块

调用库存模块扣减库存，扣减账户余额，生成订单信息插入订单数据

只要库存不足/账户余额不足，回滚事务

• Seata 相关接口
  • 库存充足，余额充足，流程正常进行，创建订单完毕返回生成的订单信息，库存，余额等信息
  • 库存充足，余额不足，事务回滚，返回生成的订单信息，库存(回滚后的)，余额等信息

storage 存储模块

扣减库存数量

account 账户模块

扣减账户余额

praise-provider 点赞生产模块

向 MQ 投递消息

praise-consumer 点赞消费模块

从 MQ 拉取消息进行消费

消费消息增加指定商品的点赞数

服务部署

针对微服务和中间件的部署，采取云原生方式进行部署，分别提供本机的 Docker-compose 以及 Kubernetes 进行容器化部署

针对每一个微服务编写对应的 DockerFile

欢迎社区针对容器化部署最佳实践的方案进行探讨，如果有更好的设计也欢迎提出。

任务列表

• 本地版本 Example feat: integrated example local version initialized #2711
• • 基本业务逻辑与Review
• • 数据库与Nacos配置脚本一键推送
• • 改进用户体验返回良好提示
• • 优化使用文档格式
• • 将business模块替换为前端客户端页面
• Docker-compose 版本快速启动
• Kubernetes Helm Chart
• • Helm Chart 基本 Demo 编写
• • 基于Kubernetes环境拉起测试验证

English version

In #2565, the community initially presents the background and requirements for the Spring Cloud Alibaba containerized deployment best practices

The relevant design points for this example are

Basic Business Outline

In this demo example, we provide two business scenarios

1. The scenario where a user places an order to buy goods, after placing the order

• first request the inventory module to deduct the inventory
• Deduct the account balance
• Generate order information to return the response

2. The user likes the goods (simulating the producer-consumer application scenario of MQ) and returns the details (number of likes, etc.) after the goods are liked

Module division

To facilitate understanding and presentation, the demo can be divided into the following six modules

• integrated-order is responsible for creating orders
• integrated-storage is responsible for deducting inventory quantities
• integrated-account for deducting the user's account balance
• integrated-praise-provider is responsible for sending messages to the MQ for likes
• integrated-praise-consumer is responsible for pulling messages from the MQ to consume and give likes to the corresponding products
• integrated-gateway The gateway to all microservice modules

Database model diagram

Referring to the Alibaba coding convention, the database table of the demo designed for business is as follows

Application scenarios for each component

Spring Cloud Gateway

Gateway for microservice modules

Integration with Sentinel to restrict flow by specifying assertion routes and flow restriction configuration rules

Dynamic refresh of the service gateway routing configuration by listening for changes in the Nacos configuration, eliminating the need to modify the configuration file and restart the service each time the routing information changes

Nacos

Configuration center for each microservice, service registry

• Configuration Center
  • Shared configuration: MySQL data source related information configuration
  • Extended configuration: independent configuration of each module
• Registration information
  • All microservice modules are registered to Nacos for service registration and discovery

Seata

Distributed transaction processing for Inventory, Account, and Order modules**

Roll back transactions whenever inventory is low/account balance is low

Sentinel

Service fusion limiting for the likes module

Also integrates with Nacos Configuration Center for dynamic configuration of fusion limit rules

RocketMQ

Used for peaks and valleys reduction of the like service traffic

RocketMQ is capable of peak and valley reduction for high traffic by sending high volume like requests from the producer to the MQ, and then the consumer module pulls from the MQ and consumes them with a certain frequency, instead of simply downgrading the service fuse limit.

Module interface functionality

Front-end client pages

• Seata Distributed Transaction Related
  • Request gateway for order placement
• Sentinel flow-limiting related
  • Simulate low traffic order (10), return generated order information
  • Simulate high traffic order (100) and return the response for service fusion
  • Simulate low-traffic likes (10), and return the details of successfully liked products (number of likes +10)
  • Simulate a high traffic order (100) and return a service fusion response
• RocketMQ peak-shaving related
  • Simulate high traffic likes by delivering messages to RocketMQ and consumer module to consume with certain frequency to achieve peak shaving

Order module

Call inventory module to deduct inventory, deduct account balance, generate order information and insert order data

Roll back the transaction whenever the inventory is low/account balance is low

• Seata related interfaces
  • If inventory is sufficient, balance is sufficient, process is normal, order creation is completed, order information generated, inventory, balance, etc. is returned
  • If inventory is sufficient and balance is not sufficient, the transaction is rolled back and the generated order information, inventory (after rollback), balance, etc. are returned

Storage module

Deduct inventory quantity

Account module

Deducts the account balance

Praise-provider praise production module

Deliver a message to the MQ

Praise-consumer module

Pull messages from MQ for consumption

The consumption message increases the number of likes for the specified product

Service Deployment

Deploy microservices and middleware in a cloud-native way, providing native Docker-compose and Kubernetes for containerized deployment respectively

Write the corresponding DockerFile for each microservice

The community is welcome to discuss the best practices for containerized deployment, and if you have a better design, please feel free to suggest it.

Task list

• Native Version Example feat: integrated example local version initialized #2711
• • Basic Business Code initialize and review
• • Push database and Nacos configuration scripts with one click
• • Improve user experience to return good tips
• • Optimize documentation format for use
• • Replace business module with front-end client page demo
• Docker-compose version quick start
• Kubernetes Helm Chart
• • Helm Chart Basic Demo Writing
• • Kubernetes environment based pull up test validation

[OrdinarySF]

请问如何解决nacos服务发现 默认获取的IP是容器内部IP的问题？

[steverao]

请问如何解决nacos服务发现 默认获取的IP是容器内部IP的问题？

容器内部IP指的是？一般容易场景部署都是默认注册Pod IP地址，如果想注册固定的IP地址通过：spring.cloud.nacos.discovery.ip进行设置。

[OrdinarySF]

请问如何解决nacos服务发现 默认获取的IP是容器内部IP的问题？

容器内部IP指的是？一般容易场景部署都是默认注册Pod IP地址，如果想注册固定的IP地址通过：spring.cloud.nacos.discovery.ip进行设置。

比如我有两个微服务模块Order与User ，一个微服务网关Gateway，三个微服务分别用docker在三台服务器部署，此时nacos会默认将其内网IP注册到nacos注册中心中。此时Gateway从nacos获取的ip也是内网ip，其转发的ip也是该内网地址，此时gateway将无法正常请求这两个微服务模块。
通过spring.cloud.nacos.discovery.ip是一种解决办法，但不够动态，也不够方便。

[steverao]

从你的描述里面来看，Nacos Server和Gateway跟具体的微服务应用不是部署在同一个内网环境吗？这样使用确实有问题，但是其实一般的企业应用系统里面，考虑到安全和便捷性等诸多因素，网关和Nacos还是跟应用部署在同一套内网环境更合适一些。

从你的描述里面来看，Nacos Server和Gateway跟具体的微服务应用不是部署在同一个内网环境吗？这样使用确实有问题，但是其实一般的企业应用系统里面，考虑到安全和便捷性等诸多因素，网关和Nacos还是跟应用部署在同一套内网环境更合适一些。

请问如何解决nacos服务发现 默认获取的IP是容器内部IP的问题？

容器内部IP指的是？一般容易场景部署都是默认注册Pod IP地址，如果想注册固定的IP地址通过：spring.cloud.nacos.discovery.ip进行设置。

比如我有两个微服务模块Order与User ，一个微服务网关Gateway，三个微服务分别用docker在三台服务器部署，此时nacos会默认将其内网IP注册到nacos注册中心中。此时Gateway从nacos获取的ip也是内网ip，其转发的ip也是该内网地址，此时gateway将无法正常请求这两个微服务模块。 通过spring.cloud.nacos.discovery.ip是一种解决办法，但不够动态，也不够方便。

从你的描述里面来看，Nacos Server和Gateway跟具体的微服务应用不是部署在同一个内网环境吗？这样使用确实有问题，但是其实一般的企业应用系统里面，考虑到安全和便捷性等诸多因素，网关和Nacos还是跟应用部署在同一套内网环境更合适一些。

[cevencheng]

请问如何解决nacos服务发现 默认获取的IP是容器内部IP的问题？

容器内部IP指的是？一般容易场景部署都是默认注册Pod IP地址，如果想注册固定的IP地址通过：spring.cloud.nacos.discovery.ip进行设置。

比如我有两个微服务模块Order与User ，一个微服务网关Gateway，三个微服务分别用docker在三台服务器部署，此时nacos会默认将其内网IP注册到nacos注册中心中。此时Gateway从nacos获取的ip也是内网ip，其转发的ip也是该内网地址，此时gateway将无法正常请求这两个微服务模块。 通过spring.cloud.nacos.discovery.ip是一种解决办法，但不够动态，也不够方便。

对啊，你的 Gateway 和 后端的三个微服务不应该都是在同一个内网吗 ？如果自动获取的Pod IP地址不满足，你通过那个设置定制你想要获取到的IP也能满足了。