|
|
|
|
@ -8,6 +8,7 @@
|
|
|
|
|
* 版权所有，侵权必究！
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
// 该类所属的包名，表明其位于商城API相关的配置包下，主要负责处理商城API相关的配置信息加载与管理。
|
|
|
|
|
package com.yami.shop.api.config;
|
|
|
|
|
|
|
|
|
|
import lombok.Data;
|
|
|
|
|
@ -16,33 +17,50 @@ import org.springframework.context.annotation.PropertySource;
|
|
|
|
|
import org.springframework.stereotype.Component;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ApiConfig类用于加载和管理与商城相关的配置信息。
|
|
|
|
|
* 它通过一系列的注解来实现从配置文件中读取特定属性并将其映射到类的成员变量上，同时使其能够被Spring容器管理，方便在项目的其他地方进行注入使用。
|
|
|
|
|
* ApiConfig类在整个项目中起着关键的配置管理作用，它专注于加载和管理与商城相关的特定配置信息。
|
|
|
|
|
* 通过运用Spring框架提供的一系列注解，它能够从指定的配置文件中读取相应属性，并将这些属性值映射到类中的成员变量上，
|
|
|
|
|
* 同时使其自身成为Spring容器所管理的组件，方便在项目的其他各个部分通过依赖注入的方式获取这些配置信息并加以运用。
|
|
|
|
|
*
|
|
|
|
|
* @author lgh
|
|
|
|
|
*/
|
|
|
|
|
@Component
|
|
|
|
|
// 使用@Component注解将该类标记为Spring组件，这样Spring容器在扫描时会识别并管理它，使得其他类可以通过依赖注入的方式使用该类的实例。
|
|
|
|
|
// @Component注解是Spring框架中用于标记一个类为Spring组件的基础注解。当Spring容器进行组件扫描时（通常基于@ComponentScan配置的扫描路径），
|
|
|
|
|
// 一旦发现被@Component注解标记的类，就会将其实例化并纳入Spring容器进行管理。这使得其他需要使用该类的地方可以通过依赖注入（如@Autowired注解）轻松获取其实例，
|
|
|
|
|
// 从而实现了类之间的解耦以及配置信息的统一管理和共享。
|
|
|
|
|
@Component
|
|
|
|
|
// @PropertySource注解用于指定配置属性的来源文件，这里的参数"classpath:api.properties"表示会从类路径下查找名为api.properties的文件作为配置信息的数据源。
|
|
|
|
|
// 在实际的项目构建和部署过程中，这个文件会随着项目一起打包，并且在应用启动时，Spring会读取其中的配置内容，按照后续的配置绑定规则进行属性赋值操作。
|
|
|
|
|
@PropertySource("classpath:api.properties")
|
|
|
|
|
// @PropertySource注解指定了配置属性的来源，这里表示会从类路径下的api.properties文件中读取配置信息。
|
|
|
|
|
// @ConfigurationProperties注解在Spring Boot应用中扮演着重要角色，它用于将配置文件中的属性值绑定到对应的Java类的成员变量上。
|
|
|
|
|
// 这里的参数"prefix = "api""指定了配置文件中属性的前缀，意味着Spring会查找以"api"开头的属性，并将其对应的值自动注入到这个类中名称相同（忽略大小写）的成员变量中。
|
|
|
|
|
// 例如，如果配置文件中有"api.datacenterId = 1"这样的配置项，那么就会自动将值1赋给这个类中的datacenterId成员变量，实现了配置文件与Java代码之间的无缝对接，方便配置管理。
|
|
|
|
|
@ConfigurationProperties(prefix = "api")
|
|
|
|
|
// @ConfigurationProperties注解用于将配置文件中以"api"为前缀的属性绑定到这个类的对应成员变量上，实现属性的自动注入。
|
|
|
|
|
// 使用lombok的@Data注解，这是一个便捷的代码生成注解，它会为类自动生成一系列常用的方法，包括成员变量的Getter和Setter方法、toString方法、equals方法以及hashCode方法等。
|
|
|
|
|
// 通过提供这些自动生成的方法，使得在其他类中对该类的成员变量进行访问、赋值以及在对象比较、哈希计算等操作时更加方便，减少了手动编写这些重复代码的工作量，提高了代码的简洁性和可读性。
|
|
|
|
|
@Data
|
|
|
|
|
// 使用lombok的@Data注解，会自动为类生成常用的方法，比如Getter、Setter、toString、equals、hashCode等方法，方便对类的成员变量进行操作和访问。
|
|
|
|
|
public class ApiConfig {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 数据中心ID，用于在分布式系统等场景下标识不同的数据中心，可能在生成分布式唯一ID等相关功能中起到区分作用。
|
|
|
|
|
* 数据中心ID，在分布式系统环境下具有重要意义。
|
|
|
|
|
* 在一些复杂的分布式架构中，可能存在多个数据中心，每个数据中心负责处理不同区域或业务模块的数据存储与管理等工作。
|
|
|
|
|
* 这个数据中心ID就用于唯一标识每个不同的数据中心，例如在生成分布式唯一ID（像Snowflake算法生成唯一ID时，会结合数据中心ID和其他参数来确保全局唯一性）的场景中，
|
|
|
|
|
* 它起到了区分不同数据中心来源的作用，有助于保证整个分布式系统中数据标识的唯一性和准确性。
|
|
|
|
|
*/
|
|
|
|
|
private Integer datacenterId;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 终端ID，通常在分布式架构中用来区分不同的工作终端或者节点，例如在使用Snowflake等分布式ID生成算法时会用到。
|
|
|
|
|
* 终端ID，同样是分布式架构中常用的一个标识概念。
|
|
|
|
|
* 在分布式系统里，往往会有多个工作终端或者节点参与到各种业务处理流程中，比如不同的服务器实例、微服务实例等都可以看作是不同的终端。
|
|
|
|
|
* 终端ID用于明确地区分这些不同的工作终端或者节点，使得系统在进行诸如资源调度、任务分配以及数据交互等操作时，能够准确识别每个终端的身份。
|
|
|
|
|
* 例如在一些分布式ID生成算法（如Snowflake算法）中，终端ID与数据中心ID等参数共同作用，生成唯一的、具有业务含义的标识符，便于对系统中的各种资源和操作进行精确管理。
|
|
|
|
|
*/
|
|
|
|
|
private Integer workerId;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 域名，代表商城系统所使用的网络域名，在构建商城的网络访问地址、配置相关网络服务等方面会用到这个配置信息。
|
|
|
|
|
* 域名，是商城系统在网络环境中的重要标识之一。
|
|
|
|
|
* 它代表了商城系统所使用的网络域名，在构建商城的网络访问地址、配置与外部系统的网络交互（如与第三方支付平台、物流平台等进行接口调用时的回调地址配置）、
|
|
|
|
|
* 以及设置各种网络服务（如配置反向代理服务器指向的目标域名等）等方面都起着关键作用。
|
|
|
|
|
* 通过在配置文件中配置这个域名信息，并将其绑定到该类的成员变量上，方便在整个项目的不同模块中统一使用这个域名来构建完整的网络访问路径，确保网络通信的准确性和一致性。
|
|
|
|
|
*/
|
|
|
|
|
private String domainName;
|
|
|
|
|
|
|
|
|
|
|
