Sentinel 是由阿里开源的一个流量控制组件，诞生于 2012 年，它的使用可分为两部分：
Java 客户端）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持dashboard）：主要负责管理推送规则、监控、管理机器信息等。笔者注：有
issue称，控制台其实只用来演示Sentinel的基本能力和工作流程，并没有依赖生产环境中所必须的组件；其数据只是简单存储到了内存中，重启控制台服务后发现数据已重置，还需重新配置。
在 Spring Cloud Gateway 中，RequestRateLimiterGatewayFilterFactory 工厂类使用一个 RateLimter 实现来判断请求是否被允许继续处理。如果不允许，则会响应 HTTP 429 - Too Many Requests。 网关中自带了一个限流实现类——RedisRateLimiter，它基于 Redis 存储，使用的是令牌桶算法。
监控是指对分布式系统中各个服务的运行状态、性能指标和交互情况进行实时监测、收集、分析和告警的过程。随着微服务架构的广泛应用，搭建一套完整的、智能化的监控系统成为了保障系统稳定运行的关键环节，以便及时发现和解决潜在的问题，而这也是服务治理中的重要概念。
监控系统按照原理和作用可以大致分为三类：
Log)：主要收集和分析系统产生的日志信息，典型解决方案：ELK(Elasticsearch + Logstash + Kibana)Tracing)：主要追踪请求在微服务间的完整调用路径，帮助定位跨服务的问题，典型解决方案：Zipkin、SkywalkingMetrics)：度量类监控基于时间序列数据库，记录系统各项指标随时间变化的趋势，如：请求量、QPS、TPS、RT 等，典型解决方案：Prometheus时间：2025-03-31 23:57:49
环境：TencentOS Server 4 for x86_64
（1）安装部署
# 安装
yum install -y docker-ce
# 自启
systemctl enable docker
# 启动
systemctl start docker
# 状态
systemctl status docker现有商品表（goods），其数据如下：
| goods_id | goods_name | stock |
|---|---|---|
| 1001 | 老干妈炒饭 | 9 |
商品库存订单表（goods_stock），用来存储订单扣减的记录，其数据如下：
| id | goods_id | order_id | deduct_stock | back_stock | create_time | back_time |
|---|---|---|---|---|---|---|
| 1 | 1001 | 123456 | 1 | NULL | 2025-03-26 17:38:01 | NULL |
今日同事问我一个问题，你看看我这代码，怎么都接不到参数，参数类定义如下：
@Data
public class Demo {
private Long pId;
}现有一张商品表（t_goods），其 SQL 脚本如下：
CREATE TABLE `t_goods`
(
`goods_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '商品ID',
`shop_id` int(11) NOT NULL COMMENT '店铺ID',
`goods_name` varchar(255) NOT NULL COMMENT '商品名称',
`goods_price` decimal(10, 2) NOT NULL COMMENT '商品价格',
PRIMARY KEY (`goods_id`)
) AUTO_INCREMENT = 11 COMMENT '商品表';现有某电商项目，基于 Spring Cloud Alibaba 微服务架构，用户在商家端核销后会进行分账的动作，具体来讲：brand-web 服务监听到核销事件后，根据一定的规则和条件查询出相应的分账比例，然后将参数以 @RequestBody 对象的形式发起调用底层的订单服务，其中分账比例等参数是 BigDecimal 类型。
发现测试环境及线上库的部分分账数据，其中手续费为 0，理应不是 0。
现有某电商平台，商品下单支付的常规交易场景，对接的支付平台为易宝支付。
前端同学在联调测试的过程中，疯狂的发起支付但不支付，如此重复，突然发现再进行此操作，订单即使没有支付，也变为了成功的状态，而且正式环境的情况也一样，问题非常严重。
收到反馈后，下意识已经想到了之前留下的一个 FIXME（支付回调处理时未判断是成功还是失败的状态），当时意识到了这个风险，但迫于没有时间处理，因此搁置了。
首先查看了一下支付平台的回调日志，果然，回调的结果是 FAIL。
在使用 DecimalFormat 和 # 号对数字进行格式化时，默认的不是四舍五入，而是银行家舍入法，在使用 hutool 的 NumberUtil.decimalFormat 方法时尤其要注意！
参考：https://blog.csdn.net/qq_42857603/article/details/129857214
2024-10-9 21:12:08 补充：原来银行家舍入法（四舍六入五成双）才是最科学的数据修约法，比四舍五入更能接近实际值，推荐使用！