Sermant 개발 플레이, 개발자 능력 메커니즘 분석

이 기사는 Huawei Cloud 커뮤니티 " 개발자 역량 메커니즘 분석, Sermant 개발의 즐거움 ", 저자: Huawei Cloud Open Source 에서 공유되었습니다 .

머리말:

"Sermant 프레임워크 하에서의 서비스 거버넌스 플러그인의 신속한 개발 및 활용 가이드" 에서는 Sermant 플러그인 개발을 경험하고 Sermant 플러그인 개발의 전 과정을 빠르게 이해할 수 있도록 안내하겠습니다. 이 글에서는 입문부터 숙달까지의 아이디어를 바탕으로 Sermant 플러그인 개발에 대한 몇 가지 지침을 제공할 것이며, 게임에서 일반적으로 사용되는 기능에 대한 보다 심층적인 분석은 메커니즘에서 제공됩니다. .

플러그인 로딩 및 플러그인 스케줄링

플러그인의 로딩 및 스케줄링을 분석하기 전에, Sermant가 Java 바이트코드 향상 기술을 기반으로 한 플러그인 서비스 그리드로서 설계 초기에 플러그인에 대한 완전한 클래스 격리 메커니즘을 설계했다는 점을 검토할 수 있습니다. Sermant Class Isolation "아키텍처 분석 - JavaAgent 시나리오에서 클래스 충돌 해결 실습"의 자세한 소개 및 분석을 통해 개발자가 복잡한 클래스 충돌 문제에 빠지지 않도록 방지할 수 있습니다. 개발자 입장에서는 클래스 충돌 문제에 주의할 필요가 없으며, Sermant의 클래스 격리 메커니즘은 눈에 띄지 않는 데에도 도움이 되며 Sermant의 로컬 클래스 로딩 메커니즘의 도움으로 고성능 서비스 관리 플러그인을 보다 효율적으로 개발할 수 있습니다.

https://oscimg.oschina.net/oscnet/up-2ce581c1d546617a73942fccc54d035793d.png

그림 - 서맨트 클래스 격리 메커니즘

플러그인 로딩

Sermant 플러그인을 개발 중이므로 가장 먼저 이해해야 할 것은 플러그인이 로드되고 예약되는 방법입니다. Sermant의 플러그인 메커니즘은 Java의 SPI 메커니즘의 이점을 활용합니다. 확장성이 뛰어난 많은 프로젝트에서 SPI를 로드하는 데 사용됩니다. 확장하면 SPI 메커니즘을 사용하는 일반적인 시나리오에는 로그 프레임워크, 데이터베이스 드라이버, 직렬화 도구, 캐시 프레임워크 등이 포함됩니다.

Java SPI(Service Provider Interface)는 Java에서 제공하는 서비스 공급자 인터페이스로, 인터페이스를 구현하는 클래스나 추상 클래스를 런타임 시 동적으로 로드하는 데 사용됩니다. SPI 메커니즘을 통해 구현을 제공하는 당사자는 원본 코드를 수정하지 않고도 플러그인 형태로 시스템에 자체 구현을 주입할 수 있습니다. SPI 메커니즘은 Java의 인터페이스 기반 프로그래밍 아이디어로, 코드의 확장성과 유연성을 향상시키고 애플리케이션의 확장 및 유지 관리를 더 쉽게 만듭니다.

그림 - Sermant SPI 로딩 메커니즘

SPI에는 인터페이스 정의, 구현 생성 및 구성 파일이라는 세 가지 핵심 요소가 있습니다. Sermant에서는 프레임워크에 정의된 플러그인 선언 인터페이스를 통해 플러그인 개발자가 플러그인의 핵심 요소를 정의할 수 있습니다. 플러그인 개발자는 인터페이스 계약을 따르고 필요한 플러그인 선언 구현만 생성하면 됩니다. 플러그인 선언 인터페이스는 다음과 같이 정의됩니다.

SPI 메커니즘의 또 다른 핵심 요소인 구성 파일의 경우 개발자는 플러그인 선언 구현이 생성된 후 리소스 디렉터리에 META-INF/services 디렉터리를 추가하고 com.huaweicloud.sermant라는 디렉터리를 생성해야 합니다. .plugin.agent.declarer.PluginDeclarer SPI 파일에 플러그인 선언 구현의 클래스 이름을 추가하면 Sermant에 연결할 때 Sermant가 구성에 따라 해당 플러그인 선언을 로드할 수 있습니다. 사양.

플러그인 스케줄링

SPI 메커니즘에만 의존하는 것은 Sermant의 강력한 프레임워크 기능을 지원할 수 없습니다.Sermant 시스템에서는 각각의 다양한 거버넌스 기능이 독립적인 플러그인이며 각 서비스 거버넌스 기능의 구현은 여러 플러그인 선언에 의존합니다. 일반적으로 각 플러그인은 전체 서비스 관리를 완료하기 위해 여러 바이트코드 측면에 의존합니다. 여러 플러그인은 바이트코드 향상 논리를 실행하기 위해 필연적으로 동일한 포인트컷을 사용합니다. 이러한 상황에서 Sermant는 어떻게 각 플러그인의 실행 순서를 보장하고 바이트코드가 반복적으로 짜여지지 않도록 보장할 수 있습니까?

Sermant는 가장 낮은 수준의 Aspect 스케줄러를 유지하는데, 먼저 플러그인 로딩 과정에서 스케줄러는 순서화된 목록을 통해 플러그인의 인터셉터(Sermant에서 서비스 관리 로직을 정의하는 컴포넌트)를 캐시합니다. 진입점이 트리거되면 인터셉터가 예약되며, 이때 Sermant는 메소드 스택의 실행 방법을 모방하고 먼저 입력된 메소드가 종료됩니다.

그림 - Sermant 플러그인 스케줄링 로직

대상 메서드를 입력할 때 스케줄러는 플러그인 로드 방법에 따라 인터셉터를 실행하여 메서드 입력 시 실행 순서가 메서드 실행 규칙을 준수하는지 확인합니다. 플러그인 로딩 방식에 따라 인터셉터를 실행하며, 로딩 순서의 역순은 서비스 메소드 스택에서 메소드가 끝나는 규칙이다.

위의 로직을 기반으로 스케줄러 계층을 통해 동일한 대상 클래스의 대상 메소드에 대해 의미 없는 바이트코드 향상이 반복적으로 수행되지 않음을 보장할 수 있습니다. 동일한 타겟에 대한 메소드 호출 스택의 로직을 따르며 이는 메소드 호출 스택의 로직과 더욱 일관성이 있습니다.Aspect 프로그램의 실행 스타일입니다. 그리고 인터셉터의 실행 순서를 제어하는 ​​목적은 플러그인을 제어하여 달성할 수 있습니다. 즉, 서비스 거버넌스가 적용되는 시기를 제어하기 위해 플러그인의 순서를 제어하는 ​​것은 일부 특수한 시나리오에 큰 이점이 됩니다.

개발자 관련 역량 분석

플러그인 및 클래스 로딩과 같은 프레임워크의 핵심 메커니즘 외에도 플러그인 개발자는 Sermant가 제공하는 일부 개발 기능에 대해 더 많이 이해해야 합니다. 서비스 관리 플러그인 개발. 간단히 말해서 플러그인은 측면의 모음이며 궁극적으로 복잡한 거버넌스 기능을 완성합니다. 관점 지향 프로그래밍에는 관점의 교차 위치를 지정하는 조인 포인트와 관점 실행의 특정 동작인 조언이라는 두 가지 핵심 개념이 있습니다. Sermant에 대응하는 플러그인 개발에 대응하는 로직도 있는데, Sermant에서 관점의 위치를 ​​선언하는 것을 플러그인 선언이라 하고, 관점 로직을 실행하는 것을 인터셉터라고 한다.

Sermant의 플러그인 선언은 클래스 이름, 슈퍼클래스, 주석 등을 기반으로 클래스를 찾을 수 있고, 메서드 이름, 유형, 매개변수, 반환 값 등을 통해 메서드를 찾을 수 있습니다. 풍부한 클래스 매칭 기능과 메서드 매칭 기능을 통해 지정할 수 있습니다. 더 쉽게 자신의 기대가 엮이는 지점입니다.

Sermant의 인터셉터는 Before, After 및 Throw라는 세 가지 주요 수명 주기를 제공하며 메서드 실행 건너뛰기 , 메서드 매개 변수 수정 , 메서드 반환 수정예외 발생 수정 과 같은 일반 기능을 제공합니다.

그림 - Sermant 인터셉터가 제공하는 기능

인터셉터의 Before 로직은 메소드가 실행되기 전 플러그인의 로딩 순서에 따라 Sermant의 Aspect 스케줄러에 의해 스케줄링되는데 여기서 Sermant가 제공하는 API를 통해 메소드 실행을 종료하고 해당 메소드에 대한 관련 정보를 얻을 수 있습니다. 현재 차단된 객체. , 메소드의 입력 매개변수를 얻고 수정할 수도 있습니다. 입력 매개변수를 수정하면 다른 플러그인에서 인식될 수 있습니다. 이는 측면 스케줄러의 중요성을 반영합니다. 매개변수 수정에 예상치 못한 문제가 발생한 경우 효과, 플러그인 순서를 조정하면 이 효과를 피할 수 있습니다.

플러그인의 After 및 Throw 로직은 대상 메소드가 종료될 때 플러그인 로딩 순서의 역순으로 Sermant의 Aspect 스케줄러에 의해 균일하게 스케줄링되며, 이때 메소드의 반환 값 및 예외를 다시 수정할 수도 있습니다. . After에서 메소드의 반환 값을 수정해야 하는 경우 Before 로직과 동일하며, 인터셉터의 실행 순서에 주의해야 하며, 예상치 못한 효과가 발생하는 경우에는 플러그인 순서.

Throw 로직에서 Sermant는 메소드가 예외를 throw할 때만 Throw 로직을 처리하도록 인터셉터를 트리거할 수 있으며, 해당 메소드에서 예외가 발생하면 Throw 인터셉터 처리 로직이 트리거될 수 없습니다. Throw logic 을 사용하면 메서드가 더 이상 예외를 발생시키지 않습니다.

통합된 동적 구성

"JavaAgent에서 동적 구성 센터를 사용하여 마이크로서비스의 다양한 거버넌스를 구현하는 방법" 에서 동적 구성에 대해 자세히 소개했지만 이 기사에서는 자세히 설명하지 않습니다. Sermant 동적 구성 모델은 설계된 구성 관리 솔루션을 기반으로 하는 계층형 모델입니다. , 핵심 구성 요소에는 그룹과 키가 포함됩니다. Sermant는 구성 항목을 서로 다른 그룹(그룹화 정보)을 통해 격리하여 구성 관리를 보다 유연하고 확장 가능하게 하는 동시에 Key를 통해 구성 항목의 특정 속성을 식별하여 구성 항목에 대한 정밀한 제어 및 제어를 수행합니다. 주류 구성 센터에서는 다음과 같습니다.

그림 - Sermant 통합 동적 구성과 관련된 개념

Sermant는 개발자와 사용자를 위한 구성 센터 간의 차이점을 보호합니다. Sermant는 코드 수정 없이 여러 구성 센터에 연결할 수 있습니다. 개발자는 실제 구성 센터를 알지 못한 채 그룹과 키를 통해 구성을 나누기만 하면 됩니다. 필드를 통해 동적 개발이 가능합니다. 구성 센터에 의존하지 않는 서비스 거버넌스 기능.

통합 로그 분석

로그는 프로그램 개발에 없어서는 안 될 기능으로, 로그를 통해 프로그램 실행 시 프로그램 상태와 발생한 문제를 빠르게 확인할 수 있습니다. Sermant의 로그에는 두 가지 매우 중요한 요구 사항이 있습니다. 첫 번째는 Sermant 로그 시스템이 마이크로 서비스에 미치는 부정적인 영향을 피하기 위한 격리의 필요성입니다. 예를 들어 마이크로 서비스의 로그 구성이 파괴되고 Sermant 로그와 마이크로 서비스 로그가 교차됩니다. 출력되어 마이크로서비스에 영향을 미침 서비스 로그 검색 및 위치 문제 두 번째는 고성능 Sermant Backend를 통해 실행 과정 중 이상 정보를 관찰하고, 사이드카 동작의 이상 문제를 적시에 탐지할 수 있는 모니터링 기능의 필요성이다.

Sermant의 통합 로그는 우선 Sermant 프레임워크는 사용자 정의 클래스 로더를 통해 로그 엔진과 마이크로서비스 로그 엔진을 분리하여 로그 엔진 공유를 방지하고 로그 엔진의 리소스 로딩을 Sermant의 사용자 정의 클래스 로더로만 제한합니다. 지휘하다:

@우세하다  
공개 열거<URL> getResources(문자열 이름)에서 IOException이 발생합니다.  
    // 클래스 격리로 인해 StaticLoggerBinder는 더 이상 상위 클래스 로더를 통해 중복 리소스를 얻지 않고 로더 내의 리소스만 반환합니다.  
    if ("org/slf4j/impl/StaticLoggerBinder.class".equals(이름)) {  
        return findResources(이름);  
    }  
    return super.getResources(이름);  
}

두 번째 단계는 Sermant 프레임워크가 사용자 정의 클래스 로더를 사용하여 로그 엔진이 로드할 수 있는 구성을 제한하고 "logback.xml" 파일 리소스의 로드를 제한하여 로그 구성을 제한하는 것입니다.

@우세하다  
공개 URL getResource(문자열 이름) {  
    URL url = null;  
  
    // 로그 구성 파일의 경우 getResource 메소드를 사용자 정의하여 FrameworkClassloader 아래의 리소스 파일에서 logback.xml을 얻습니다.  
    if (CommonConstant.LOG_SETTING_FILE_NAME.equals(이름)) {  
        파일 logSettingFile = BootArgsIndexer.getLogSettingFile();  
        if (logSettingFile.exists() && logSettingFile.isFile()) {  
            노력하다 {  
                url = logSettingFile.toURI().toURL();  
            } catch (MalformedURLException e) {  
                url = findResource(이름);  
            }  
        } 또 다른 {  
            url = findResource(이름);  
        }  
    }  
    if (url == null) {  
        url = super.getResource(이름);  
    }  
    반환 URL;  
}

마지막으로 JUL 브리지 로그는 jul-to-slf4j(새 창 열림) 의 브리지 기능을 사용하여 JUL 로그를 로그 엔진에 브리지하는 데 사용됩니다. 마지막으로 Sermant 개발자가 통합 로그를 사용하면 JUL 인터페이스를 통해 로그를 구성할 수 있습니다. 더 이상 다른 타사 로그 파사드 종속성에 의존할 필요가 없으며 Java 기본 로그 인터페이스만 사용하면 됩니다. 로그와 마이크로서비스는 완전히 절연, 사이드카 방지 로깅 시스템은 마이크로서비스 로깅 시스템에 부정적인 영향을 미칩니다.

그림 - Serman 로깅 시스템

또한 Sermant에서는 로그 프로세서가 수정되었으며, 로그를 래핑하는 브리지 프로세서를 통해 Sermant의 이벤트 시스템을 통해 상위 수준의 로그 구성을 모니터링합니다.

공개 클래스 SermantBridgeHandler는 SLF4JBridgeHandler를 확장합니다.  
    @우세하다  
    protected void callLocationAwareLogger(LocationAwareLogger lal, LogRecord 레코드) {  
        // SLF4JBridgeHandler의 로그 변환 방법을 재정의하고 로그 이벤트를 보고합니다.  
        int julLevelValue = Record.getLevel().intValue();  
  
        if (julLevelValue > Level.INFO.intValue() && julLevelValue <= Level.WARNING.intValue()) {  
            // 경고 수준 로그를 기록합니다.  
            LogEventCollector.getInstance().offerWarning(record);  
        } else if (julLevelValue > Level.WARNING.intValue()) {  
            // 오류 수준 로그를 기록합니다.  
            LogEventCollector.getInstance().offerError(record);  
        }  
        super.callLocationAwareLogger(lal, 레코드);  
    }  
}

상위 로그 모니터링을 위해 상위 로그의 이상 징후를 보고하도록 이벤트 시스템을 구성할 수 있으며, Sermant Backend를 통해 사이드카 동작의 이상 상태를 즉시 발견할 수 있습니다.

결론

이 기사에서는 Sermant 플러그인 개발에서 항상 접하게 되는 몇 가지 기능에 대해 심층 분석을 제공합니다. 더 깊은 이해를 바탕으로 플러그인을 개발할 때에만 Sermant가 제공하는 풍부한 개발자 기능을 보다 유연하게 사용할 수 있습니다. 이는 대부분의 플러그인 개발자에게 영감을 줍니다. 위의 기능 외에도 플러그인 개발 시 Archetype 기능을 사용하여 프로젝트를 빠르게 빌드 하고 하트비트 , 링크 태그 등과 같은 기능을 사용해야 할 수도 있습니다. 서비스 거버넌스 개발 가속화 부분 클래스 로딩 환경 구축 방법 및 추가 개발 지침은 Sermant 개발자 가이드 에서 확인할 수 있습니다 .

개발이 완료된 후 k8s 환경 에서 Sermant를 빠르게 배포 하고 Sermant를 동적으로 설치 및 제거하고 플러그인 을 반복적으로 설치 하고 사이드카 자체 모니터링을 완료하는 등 더 많은 기술을 Sermant User를 통해 학습할 수 있습니다. 수동 .

------------------------------------- --------------------------

서비스 거버넌스 분야에 초점을 맞춘 바이트코드 향상 프레임워크인 Sermant는 고성능, 확장 가능, 액세스하기 쉽고 기능이 풍부한 서비스 거버넌스 경험을 제공하기 위해 최선을 다하고 있으며 성능, 기능 및 경험을 관리합니다. 각 버전에서는 누구나 가입할 수 있습니다.

화웨이 클라우드의 신기술에 대해 빨리 알아보고 팔로우하려면 클릭하세요~

SenseTime 창립자 Tang Xiaoou가 55세의 나이로 세상을 떠났습니다 . 2023년 PHP는 정체되었습니다 . Hongmeng 시스템은 곧 독립을 앞두고 있으며 많은 대학에서 "Hongmeng 클래스"를 설정했습니다. PC 버전 Quark 브라우저가 내부 테스트를 시작했습니다. ByteDance는 OpenAI에 의해 "금지"되었습니다. Zhihuijun의 스타트업 회사는 금액이 6억 위안이 넘고 사전 가치 평가가 35억 위안으로 재융자되었습니다. AI 코드 도우미는 프로그래밍에서 경쟁조차 할 수 없을 정도로 인기가 높습니다 . 언어 순위 Mate 60 Pro의 5G 모뎀과 무선 주파수 기술이 훨씬 앞서 있습니다. No Star, No Fix MariaDB가 SkySQL을 분사하여 독립 회사로 설립되었습니다.
{{o.이름}}
{{이름}}

Supongo que te gusta

Origin my.oschina.net/u/4526289/blog/10322449
Recomendado
Clasificación