I. 배경
사용자 동작 매립을 위해 오픈 소스 SDK 컴포넌트를 기반으로 캡슐화된 간단한 스프링 부트 스타터 컴포넌트를 공유하고, 스프링 부트 스타터 컴포넌트를 개발하는 데 필요한 기본 루틴도 공유했습니다:
1단계: 기존 구성 속성을 추상화하고 새 속성을 추가하는 XXXProperties 클래스 파일을 정의합니다.
2단계: 핵심 비즈니스 처리 클래스, 핵심 비즈니스 처리 클래스를 초기화하여 일반적으로 XXXAutoConfiguration의 클래스 파일에 작성된 IOC에 주입합니다.
3단계: 사용자가 Starter에서 패키지 이름의 경로가 일관되지 않도록 하려면 spring.facts 파일을 선언하여 클래스를 IOC로 스캔하는 방법을 제공하세요.
약간의 내용을 이어서 이 섹션에서는 학습할 가치가 있는 SpringBoot 스타터 구성 요소의 몇 가지 고급 구성에 대해 설명합니다.
이 글의 내용은 개인 지식 행성인 '깨어나는 신세계 프로그래머'에 처음 게시되었습니다.
둘째, 공통 어노테이션의 스프링 부트 스타터
스타터 구성 요소의 경우 일반적으로 기본 기능을 완료하여 클라이언트의 다른 사용자가 클라이언트의 요구를 사용할 수 있도록하기 위해 일반적으로 호환성 프로세스의 일부 상황을 충족하기 위해 일부 고급 구성을 개발 한 다음 이러한 구성과 많은 수의 주석을 사용하여 유연한 구성을 제공합니다. 그중에서도 이러한 고급 구성은 다음과 같은 플레이를 달성하기 위해 만들 수 있습니다:
를 사용하여 다양한 패키지 환경에서 어셈블리 클래스를 자동으로 로드할 수 있습니다.
특정 인터페이스 또는 구성의 자동 차단, 코드 개선 등을 달성하기 위한 AOP 기반 주석.
구성 요소의 통합은 커스터마이저 패턴을 기반으로 우아하게 확장됩니다.
。。。。。。
이 과정에서 다음과 같은 주석이 사용될 수 있습니다:
프로필 어노테이션: 서로 다른 자동 어셈블리 클래스를 로드하는 환경을 구분하는 데 사용됩니다.
조건부 클래스 어노테이션: 자동 클래스 어셈블리를 트리거하기 전에 현재 클래스 경로에 클래스가 존재하는지 식별하는 데 사용됩니다.
조건부 누락 클래스 어노테이션: 현재 클래스 경로에 클래스가 존재하지 않을 때 트리거됩니다.
조건부 누락 빈 어노테이션: 현재 IOC 컨테이너에 빈이 존재하지 않는 경우를 식별하는 데 사용됩니다.
실제로 스타터 개발에는 많은 주석이 사용되며, 관심 있는 파트너는 계속해서 오를 정리할 수 있습니다.
셋째, 스프링 부트 스타터 학습 방법론
이 기사를 시작하기 전에 공유 할 수있는 방법이 있습니다. 이러한 종류의 학습을 위해 기본 구성 요소 설계 및 포장을 배운 후 질문의 바다를 사용하여 학습 할 수 있지만 개인적으로이 방법은 또한 많은 수의 읽기 및 학습 입력이며, 프로세스 과정에서 질적 변화를 달성하기 위해 계속해서 양적 변화를 달성 할 수 있도록 허용하지만 방법의 침전 및 합산을 계속할 수 있지만 종종 지식을 공유하는 데 사용되는 쥐의 삼촌의 왼쪽 귀도 있습니다! 학습의 첫 번째 단계 : 지식 습득.
그래서 어떻게 하나요? 나는 당신이 장면의 살인에 출연하는 샤오 양 선생님을 본 적이 있는지 모르겠습니다, 그것은 1,000 + 영화를보고, 문제 해결에 대한 몽타주 접근 방식을 배웠지만, 또한 사고로 문제를 처리 할 수있는 어느 정도의 기술을 가질 수 있도록, 그런 다음 이런 종류의 요구에 대해서도, 당신이 이런 종류의 입력의 읽기 및 학습의 5-10 + 스타터 구성 요소를 주입하도록 자신을 제공하면, 나는 그들 자신을 통해 생각합니다. 자신의 요약과 관찰을 통해 스타터의 디자인 사고와 코드 확장을 위해 어느 정도의 질적 변화를 가질 수 있다고 믿습니다.
어떻게 하나요? 간단합니다. 깃허브에 로그인하여 스프링 부팅 스타터 키워드를 검색하고 표시되는 결과 중에서 관심 있는 5~10개 이상의 스타터 구성 요소를 골라 하나씩 읽고, 분석하고, 요약한 다음 각 구성 요소가 어떤 문제를 해결하는지에 대해 생각해 보세요.
아래 그림과 같습니다:
넷째, 몇 가지 고급 디자인의 스프링 부트 스타터 구성 요소 패키징
스타터 구성 요소의 확장 포트는 사용자 정의 패턴을 기반으로 합니다.
이 디자인의 커스터마이저 패턴을 사용하면 클라이언트 프로젝트의 스타터 컴포넌트에 대한 참조가 일부 단계에서 스타터 컴포넌트, 관련 속성 및 작동할 객체에 있을 수 있도록 확장 지점에 묻혀 있는 스타터에서 만들 수 있습니다. 여기 mybatis 스프링 부팅 스타터 컴포넌트를 예로 들어보겠습니다.
리포지토리 주소: github.com/spr...
먼저 기능 인터페이스를 사용하여 사용자 정의 패턴의 클래스를 정의합니다:
@FunctionalInterface
public interface ConfigurationCustomizer {
/**
* Customize the given a {@link Configuration} object.
* @param configuration the configuratio object to customize
*/
void customize(Configuration configuration);
}
그런 다음 컨테이너가 묻혀 있는 곳에서 해당 클래스의 서브클래스를 컨테이너에서 로드하고 주기적 초기화 호출 작업을 수행합니다:
private void applyConfiguration(SqlSessionFactoryBean factory) {
MybatisProperties.CoreConfiguration coreConfiguration = this.properties.getConfiguration();
Configuration configuration = null;
if (coreConfiguration != null || !StringUtils.hasText(this.properties.getConfigLocation())) {
configuration = new Configuration();
}
if (configuration != null && coreConfiguration != null) {
coreConfiguration.applyTo(configuration);
}
if (configuration != null && !CollectionUtils.isEmpty(this.configurationCustomizers)) {
// 다음은 하위 클래스와 확장이 클래스의 처리를 사용자 정의 할 수 있도록하는 순환 호출의 확장 지점입니다.
for (ConfigurationCustomizer customizer : this.configurationCustomizers) {
customizer.customize(configuration);
}
}
factory.setConfiguration(configuration);
}
다음은 사용 모드로 수행할 수 있는 몇 가지 작업입니다.
로켓엠큐 스프링 부트 스타터를 예로 들면, 창고 주소는 다음과 같습니다: github.com/ro... 우선 좋은 사용자 정의 자동 구성 클래스에서 클라이언트가 자동으로 어셈블되지 않게 하려면 클래스 시작 부분에 Enable이라는 이름을 지정하여 다음과 같은 방식으로 어셈블을 활성화할 수 있습니다. 클라이언트가 자동으로 어셈블되지 않도록 하려면 클래스 시작 부분에 Enable 클래스를 제공하여 이러한 방식으로 어셈블을 활성화할 수 있습니다:
/**
* Annotation to enable a RocketMQ implementation.
*
*
*/
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(RocketMQAutoConfiguration.class)
public @interface EnableRocketMQ {
}
이러한 어노테이션을 정의하고 이를 사용할 때 시작 클래스에서 선언하세요. 그런 다음 Auto 어셈블리 클래스에서 다음 코드와 같이 일부 어셈블리를 트리거하기 전에 특정 프로퍼티가 특정 값과 같음을 표현하기 위해 ConditionalOnProperty 어노테이션을 결합할 수도 있습니다:
@Bean
@ConditionalOnClass(DefaultMQProducer.class)
@ConditionalOnMissingBean(DefaultMQProducer.class)
@ConditionalOnProperty(prefix = "spring.rocketmq", value = {"nameServer", "producer.group"})
public DefaultMQProducer mqProducer(RocketMQProperties rocketMQProperties) {
//코드의 일부 생략
return producer;
}
를 사용하여 다양한 패키지 환경에서 어셈블리 클래스를 자동으로 로드할 수 있습니다.
Spring부팅 스타터 구성 요소 디자인에서 많은 디자이너가 spring.factories 파일을 제공 한 다음이 파일이 각 구성 요소 세트에 필요하다는 것을 알 수 있으며, 반드시 대답은 아닙니다. 이 파일이 없으면 스타터도 실행할 수 있으며, 자신의 스캔 범위를 처리하고 젖은 스캔 범위를 고려해야합니다.
이 파일을 사용하면 현재 클라이언트 프로젝트의 패키지 이름이 이 파일의 패키지 이름과 일치하지 않을 때 더 유용합니다. 이렇게 하면 현재 클라이언트 프로젝트의 프로젝트를 스캔하고 로드하여 다른 패키지의 클래스를 로드할 수도 있습니다.
그런 다음 SpringBoot 2.7,이 파일은 오래되었고, 후속 버전은 취소되며, 새 버전의 규칙은 여기에서 wxjava 스프링 부팅 스타터 구성 요소를 예로 들어, 창고 주소는 다음과 같습니다:
이 샘플 프로젝트에서는 리소스 파일 아래에 다음 파일이 정의되어 있습니다:
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
구현 클래스는 해당 파일에 직접 정의되며 인터페이스 선언은 파일 이름에 반영됩니다.
com.binarywang.spring.starter.wxjava.miniapp.config.WxMaAutoConfiguration
ChatGPT에게 버전 2.7 이후의 이 변경 사항에 대해 어떻게 생각하는지 물어보세요.
SpringBoot 2.7은 SPI 파일의 규칙을 변경하고 spring.factories 파일을 제거했는데, 이 부분에 대한 설명과 함께 SPI 파일의 규칙을 다른 방식으로 변경 한 이유와 그렇게하면 어떤 이점이 있는지 알려주세요!
ChatGPT는 다음과 같이 답변했습니다:
SpringBoot 2.7에서는 SPI 파일에 대한 규칙, 특히 이전 버전의 spring.factories 파일과 관련된 규칙이 변경되었습니다. 이전 버전의 SpringBoot에서 spring.factories 파일은 자동 구성 클래스뿐만 아니라 다른 유형의 서비스 및 구성 요소를 구성하는 데 널리 사용되었습니다.
SpringBoot 2.7의 변경 사항
규칙 변경: SpringBoot 2.7에서는 SPI를 관리하는 새로운 방법을 위해 spring.factories 파일 사용을 제거합니다.
새로운 접근 방식: 여기에는 주석 기반 구성을 사용하거나 서비스 등록 및 검색을 위한 새로운 프로필 형식을 채택하는 것이 포함될 수 있습니다.
변경 이유
간소화된 구성: 새로운 접근 방식은 구성 프로세스를 간소화하여 서비스의 자동화된 구성 및 관리를 보다 직관적이고 이해하기 쉽게 만드는 것을 목표로 합니다.
성능 최적화: 시작 및 런타임 시 애플리케이션의 성능을 개선하기 위해 SPI 파일의 규칙을 변경할 수 있습니다.
유연성 향상: 새로운 메커니즘은 더 큰 유연성을 제공하여 더 세밀한 제어와 사용자 지정이 가능합니다.
마일리지
가독성 및 유지보수성 향상: 보다 직관적인 구성 방법으로 코드를 더 쉽게 읽고 유지보수할 수 있습니다.
성능 개선: 시작 시간 및 운영 효율성이 개선될 수 있습니다.
더 나은 사용자 지정 지원: 새로운 메커니즘이 사용자 지정 및 확장 기능을 더 잘 지원할 수 있습니다.
특정 인터페이스 또는 구성의 자동 차단, 코드 개선 등을 달성하기 위한 AOP 기반 주석.
스타터 구성 요소를 개발하는 과정에서 일부 스타터 구성 요소의 목표는 시스템 기능, 자동 향상 및 기타 처리를 가로채는 것이며, 이때 AOP 사고를 사용하여 스타터 구성 요소의 향상된 클래스를 정의 할 수 있으며, 여기서는 제한된 흐름의 Redis 래틀 리미터 스프링 부팅 스타터로 정의 할 수 있습니다. 스타터 컴포넌트를 예로 들면, 웨어하우스 주소는 다음과 같습니다:
먼저 사용자 지정 주석을 정의할 수 있습니다:
@Target(value = {ElementType.METHOD})
@Retention(value = RetentionPolicy.RUNTIME)
public @interface RateLimit {
//===================== 공개 매개 변수============================
Mode mode() default Mode.TIME_WINDOW;
/**
* 시간 창 모델은 각 시간 창에서 요청 횟수를 나타냅니다.
* 토큰 버킷 모델은 초당 생성되는 토큰 수를 나타냅니다.
* @return rate
*/
int rate();
//코드의 일부 생략
}
그런 다음 이 어노테이션에 대한 AOP 인터셉터 클래스를 정의합니다:
@Aspect
@Component
@Order(0)
public class RateLimitAspectHandler {
private static final Logger logger = LoggerFactory.getLogger(RateLimitAspectHandler.class);
private final RateLimiterService rateLimiterService;
private final RuleProvider ruleProvider;
public RateLimitAspectHandler(RateLimiterService lockInfoProvider, RuleProvider ruleProvider) {
this.rateLimiterService = lockInfoProvider;
this.ruleProvider = ruleProvider;
}
@Around(value = "@annotation(rateLimit)")
public Object around(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable {
Rule rule = ruleProvider.getRateLimiterRule(joinPoint, rateLimit);
Result result = rateLimiterService.isAllowed(rule);
boolean allowed = result.isAllow();
if (!allowed) {
logger.info("Trigger current limiting,key:{}", rule.getKey());
if (StringUtils.hasLength(rule.getFallbackFunction())) {
return ruleProvider.executeFunction(rule.getFallbackFunction(), joinPoint);
}
long extra = result.getExtra();
throw new RateLimitException("Too Many Requests", extra, rule.getMode());
}
return joinPoint.proceed();
}
}
이 단락의 핵심 구성은 실제로 @Around(value = "@annotation(rateLimit)") 코드로, 알림 주변의 이 컷아웃 차단을 통해 AOP의 스타터 처리 기능을 일종의 자동 향상시킬 수 있습니다.
그런 다음 AutoConfiguration 클래스로 이동하여 이 AOP 클래스를 임포트합니다:
@Configuration
@ConditionalOnProperty(prefix = RateLimiterProperties.PREFIX, name = "enabled", havingValue = "true")
@AutoConfigureAfter(RedisAutoConfiguration.class)
@EnableConfigurationProperties(RateLimiterProperties.class)
@Import({RateLimitAspectHandler.class, RateLimitExceptionHandler.class})
public class RateLimiterAutoConfiguration {
private final RateLimiterProperties limiterProperties;
public final static String REDISSON_BEAN_NAME = "rateLimiterRedissonBeanName";
public RateLimiterAutoConfiguration(RateLimiterProperties limiterProperties) {
this.limiterProperties = limiterProperties;
}
// 코드의 일부 생략
}
또한 방금 언급한 주석과 결합하여 더욱 우아한 디자인을 완성할 수 있습니다.
V. 요약
이 문서에서는 네 가지 SpringBoot 스타터 고급 디자인을 요약한 것으로, 오픈 소스 디자인을 읽음으로써 스타터 구성 요소 패키징 기술과 이해를 효과적으로 향상시킬 수 있습니다:
이 글은 최근에 하고 싶은 콘텐츠의 두 번째 요약이며, 후속으로 성장하는 IO SDK의 소스 코드 분석 및 설계를 공유하여 클라이언트 측 데이터 매립 및 보고 코드 설계의 일종을 배울 수 있기를 바랍니다.
이 과정에서 혼란스러운 점이나 궁금한 점이 있다면 언제든지 함께 공유해 주세요.
여섯째, 운동
관심있는 파트너는 연구 이후 헛되이 배울 수 없지만 Github로 이동하여 1-5 스타터 구성 요소에 대한 자신의 관심을 검색하고 동시에 기술을 이해하고 동시에 그것에 대해 생각하고 분석 할 수 있으며 동시에 시작의 법칙을 사용하여 그들이하는 일을 설명하는 것이 좋습니다.
시작의 법칙이란 무엇인가요? 다음 설명을 참조하세요:
"S"- 상황, 배경 또는 환경.
"T"-작업, 작업을 개발합니다.
"A" - 조치, 구현 단계.
"R" - 결과, 결과 반향.
"T" - 생각하고, 개선에 대해 생각하세요.
예를 들어, 이 문제/과제에 대해 당시 어떤 배경 문제가 발생했는지, 문제를 분석하는 과정에서 어떤 작업 목표나 기대치를 설정했는지, 그 후 어떤 실행 단계를 거쳤는지, 어떤 결과를 얻었고 얼마나 효과적이었는지, 마지막으로 알려진 결과에 대해 더 나은 결과를 얻기 위해 앞으로 어떻게 개선할 수 있을지 생각해보는 것입니다.
동시에이 기사는 기사에서 새로운 세계 프로그래머의 행성 각성에 대한 개인적인 지식의 첫 번째 저자이기도하지만 행성에서도 콘텐츠의 "오픈 소스 디자인 시리즈 주제"에서 공유되고 있으며, 관련 내용에 대해 배우고 싶다면 와서 배울 수 있으며, 나는 친구 Xi 교환입니다.
