Kitex 2주년 기념 리뷰 - 용량 업그레이드, 커뮤니티 협력 및 향후 전망

[심천] Yuanchuanghui: 오후 5시 26분, 파티홀이 여러분을 기다리고 있습니다.”

이 기사는 CloudWeGo 2주년을 기념하는 시리즈의 첫 번째 기사입니다.

오늘의 공유 내용은 크게 세 부분으로 나누어집니다. 첫 번째는 지난 1년간의 성능 , 기능 , 사용 편의성 향상에 대해 살펴보겠습니다 . 두 번째는 커뮤니티 협력 프로젝트의 진행입니다. 특히 두 가지 핵심 프로젝트인 Kitex-Dubbo 상호 운용성 과 구성 센터 통합입니다 . 세 번째는 우리가 현재 하고 있고 계획하고 있는 몇 가지 일에 대한 스포일러를 제공하는 것입니다.

능력 업그레이드

성능

2021년 9월 CloudWeGo 공식 홈페이지에서 " ByteDance Go RPC Framework Kitex Performance Optimization Practice "라는 글을 게재했습니다 . 이 글에서는 자체 개발한 네트워크 라이브러리인 Netpoll과 자체 개발한 Thrift Decoder를 통해 편집하는 방법을 소개하고 있습니다. Kitex 성능을 최적화하는 fastCodec.

그 이후로 Kitex 코어 요청 링크에 대한 성능 개선은 매우 어려웠습니다. 실제로 새로운 기능을 지속적으로 추가하면서 Kitex 성능 저하를 방지하기 위해 열심히 노력해야 합니다.

그럼에도 불구하고 우리는 Kitex 성능을 최적화하려는 노력을 멈추지 않았습니다. Byte 내에서는 이미 핵심 링크에 대한 일부 성능 개선을 실험하고 홍보하고 있으며 이에 대해서는 나중에 소개하겠습니다.

DynamicGo 기반 일반 호출

먼저, 출시된 성능 최적화인 DynamicGo 기반의 일반화된 호출을 소개하겠습니다. Generic Calling 은 Kitex Generic Client를 사용하여 SDK 코드(즉, Kitex Client)를 미리 생성하지 않고도 대상 서비스의 API를 직접 호출할 수 있는 기능입니다.

예를 들어 ByteDance의 내부 인터페이스 테스트 도구, API 게이트웨이 등은 HTTP 요청(요청 본문은 JSON 형식)을 수신하고 이를 Thrift Binary로 변환하여 Kitex 서버로 보낼 수 있는 Kitex의 일반 클라이언트를 사용합니다.

구현 계획은 a를 map[string]interface{} 일반 컨테이너로 사용하고, 요청 시 먼저 json을 map으로 변환한 다음, Thrift IDL을 기반으로 map -> thrift 변환을 완료하는 것입니다. 응답은 역순으로 처리됩니다.

이것의 장점은 유연성이 뛰어나고 미리 생성된 정적 코드에 의존할 필요가 없다는 것입니다. 대상 서비스를 요청하는 데 IDL만 필요합니다.
그러나 가격이 좋지 않습니다. 이러한 일반 컨테이너는 Go의 GC 및 메모리 관리에 의존하므로 많은 양의 메모리를 할당해야 할 뿐만 아니라 여러 데이터 복사본이 필요합니다.

이에 우리는 프로토콜 변환 성능을 향상시킬 수 있는 DynamicGo(홈페이지: http://github.com/cloudwego/dynamicgo )를 개발했습니다. 프로젝트 소개에 매우 자세한 소개가 있습니다. 여기서는 핵심 설계 아이디어만 소개하겠습니다. 원본 바이트 스트림을 기반으로 데이터 처리 및 변환이 현장 에서 완료됩니다 .

풀링 기술을 통해 Dynamicgo는 메모리를 한 번만 사전 할당하면 되며 가속을 위해 SSE 및 AVX와 같은 SIMD 명령어 세트를 사용하여 궁극적으로 상당한 성능 향상을 달성합니다.

아래 그림에서 볼 수 있듯이 일반화 호출의 원래 구현과 비교하여 6KB 데이터의 인코딩 및 디코딩 테스트에서 성능이 4~9배 향상되었으며 사전 생성된 정적 코드 보다 훨씬 더 뛰어났습니다.

실제 원리는 매우 간단합니다. IDL 구문 분석을 기반으로 유형 설명자를 생성하고 다음 프로토콜 변환 프로세스를 수행합니다.

매번 JSON 바이트 스트림에서 키/값 쌍을 읽습니다.
IDL 설명자에 따라 키에 해당하는 Thrift 필드를 찾습니다.
해당 유형의 Thrift 인코딩 사양에 따라 Value 인코딩을 완료하고 이를 출력 바이트 스트림에 씁니다.
전체 JSON이 처리될 때까지 이 프로세스를 반복합니다.

DynamicGo는 JSON/Thrift 프로토콜 변환을 최적화하는 것 외에도 Thrift DOM 방법을 제공하여 데이터 조정 시나리오의 성능을 최적화합니다. 예를 들어, Douyin의 비즈니스 팀은 요청의 불법 데이터를 삭제해야 하지만 DynamicGo의 Thrift DOM API를 사용하는 것은 요청의 특정 필드에서만 매우 적합하며 10배의 성능 향상을 달성할 수 있습니다. DynamicGo의 문서는 여기서 확장되지 않습니다.

Frugal - 고성능 JIT 기반 Thrift 코덱

Frugal은 JIT 컴파일 기술을 기반으로 한 고성능 Thrift 코덱 입니다.

공식 Thrift 및 Kitex 기본 코덱은 Thrift IDL 구문 분석과 해당 인코딩 및 디코딩 Go 코드 생성을 기반으로 합니다. JIT 기술을 통해 런타임 에 더 나은 성능으로 인코딩 및 디코딩 코드를 동적으로 생성 할 수 있습니다 . 더 컴팩트한 기계어 코드 생성, 캐시 미스 감소, 분기 미스 감소, SIMD 명령어를 사용하여 가속, 레지스터 기반 함수 호출 사용(Go 기본값은 기본 스택에).

인코딩 및 디코딩 테스트의 성능 지표는 다음과 같습니다.

보시다시피, Frugal 성능은 기존 방법보다 훨씬 높습니다.

성능상의 이점 외에도 코덱 코드가 생성되지 않기 때문에 추가적인 이점도 있습니다.

한편으로는 웨어하우스가 더 간결해졌습니다 . 생성된 코드가 700MB인 프로젝트가 있는데, 알뜰하게 전환한 후에는 웨어하우스 유지 관리에 대한 부담이 약 5% 감소한 37M에 불과합니다. , IDL을 수정한 후에는 많은 코드가 생성되지 않습니다. 반면에 실제로 검토할 수 없는 코드는 IDE의 로딩 속도 와 프로젝트의 컴파일 속도 도 크게 향상될 수 있습니다.

사실 프루갈은 지난해 출시됐지만 당시 초기 버전 취재가 부족했다. 올해 우리는 안정성 최적화에 중점을 두고 알려진 모든 문제를 수정했습니다. 최근 출시된 버전 v0.1.12는 프로덕션 작업에서 안정적으로 사용할 수 있습니다. 예를 들어 ByteDance 전자상거래 사업 부문에서 특정 서비스의 최대 QPS는 약 25K입니다. Frugal로 완전히 전환되어 몇 달 동안 안정적으로 운영되고 있습니다.

Frugal은 현재 Go1.16 ~ Go1.21을 지원하고 현재 AMD64 아키텍처만 지원하며 향후 ARM64 아키텍처도 지원할 예정입니다. 향후 버전에서는 Frugal을 Kitex의 기본 코덱으로 사용할 수 있습니다.

기능

Kitex는 지난 해 v0.4.3에서 v0.7.2로 업그레이드되었습니다. 명령줄 도구 , gRPC , Thrift 인코딩 및 디코딩, 재시도 , 일반화된 호출 및 서비스 거버넌스 구성을 다루는 40개 이상의 기능 관련 풀 요청이 있습니다 . 여러 측면에서 여기서는 몇 가지 더 중요한 기능에 중점을 둡니다.

대체 - 비즈니스 사용자 정의 다운그레이드

첫 번째는 Kitex v0.5.0 버전에 추가된 fallback 기능입니다.

수요 배경은 RPC 요청이 실패하고 응답을 얻을 수 없는 경우 비즈니스 코드에서 일부 다운그레이드 전략을 구현해야 하는 경우가 많다는 것입니다.

예를 들어, 정보 흐름 비즈니스에서 API 액세스 계층에서 권장 서비스를 요청할 때 간헐적으로 오류(예: 시간 초과)가 발생하는 경우 간단하고 투박한 접근 방식은 사용자에게 오류가 발생했음을 알리고 사용자가 다시 시도하도록 하는 것입니다. 이로 인해 좋지 않은 경험이 발생합니다. 더 나은 다운그레이드 전략은 일부 인기 항목을 반환하는 것입니다. 사용자는 이에 대해 거의 알지 못하며 경험은 훨씬 더 좋아질 것입니다.

이전 버전의 Kitex의 문제점은 서킷 브레이커, 타임아웃 등 내장된 미들웨어 이후에는 미들웨어에서 비즈니스 맞춤형 미들웨어를 구현할 수 없다는 점입니다. 유일한 방법은 비즈니스 코드를 직접 수정하는 것인데, 이는 상당히 거슬리고 불편합니다. 모든 메소드를 수정해야 하며 놓치기 쉽습니다. 특정 메서드를 호출하는 비즈니스 로직을 추가할 때 해당 메서드가 누락되지 않도록 보장하는 메커니즘이 없습니다.

새로운 폴백 기능을 통해 기업은 다운그레이드 전략을 구현하기 위해 클라이언트를 초기화할 때 폴백 방법을 지정할 수 있습니다 .

다음은 간단한 사용 예입니다.

클라이언트를 초기화할 때 지정된 이 메서드는 각 요청이 끝나기 전에 호출됩니다. 이를 기반으로 사용자 정의 다운그레이드 전략을 구현할 수 있으므로 구현이 수렴됩니다. 전략.

Thrift FastCodec - 알 수 없는 필드 지원

실제 비즈니스 시나리오에서는 요청 링크에 여러 노드가 포함되는 경우가 많습니다.

A -> B -> C -> D 링크를 예로 들면, 노드 A의 특정 구조체는 B와 C를 통해 노드 D로 투명하게 전송되어야 합니다. 이전 구현에서는 예를 들어 A에 새 필드가 추가되면 새 IDL을 Extra 사용 하여 모든 노드의 코드를 재생성 하고 이를 다시 배포하여 노드 D의 Extra 필드 값을 가져와야 합니다. 전체 프로세스가 복잡하고 업데이트 주기가 상대적으로 길기 때문에 중간 노드가 다른 팀의 서비스인 경우 팀 간 조정이 필요하므로 매우 힘듭니다.

Kitex v0.5.2에서는 자체 개발한 fastCodec에 Unknown Fields 기능을 구현하여 이 문제를 매우 효과적으로 해결할 수 있습니다.

예를 들어, 동일한 링크 A -> B -> C -> D에서 노드 B와 C의 코드는 변경되지 않은 상태로 유지됩니다(아래 그림과 같이) id=2 . 해당 필드를 구조체에서 찾을 수 없습니다. 따라서 내보내지 않은 이 _unknownFields 필드(실제로는 바이트 슬라이스의 별칭)가 기록됩니다.

A, D 서비스는 아래 그림과 같이 새로운 IDL로 재생성되어 Extra 해당 필드를 포함하므로 id=2 해당 필드를 파싱할 때 해당 필드에 작성하면 Extra 정상적으로 비즈니스 코드를 사용할 수 있습니다.

또한 v0.7.0에서는 이 기능에 대한 성능 최적화를 수행하여 " 직렬화 없음 "(바이트 스트림 직접 복사)을 사용하여 알 수 없는 필드의 인코딩 및 디코딩 성능을 약 6~7 배 향상했습니다.

GLS 기반 세션 전달 메커니즘

여러분에게 소개할 만한 또 다른 기능은 긴 링크와도 관련이 있습니다.

Byte 내에서는 LogID를 사용하여 전체 호출 체인을 추적합니다. 이를 위해서는 링크의 모든 노드가 필요에 따라 이 티켓을 투명하게 전송해야 합니다. 우리 구현에서는 LogID가 요청 본문에 포함되지 않고 메타데이터 형식으로 투명하게 전송됩니다.

A -> B -> C 링크를 예로 들면 A가 B의 A_Call_B 메소드를 호출할 때 수신 LogID는 핸들러 입력 매개변수에 저장됩니다 . B가 C를 요청할 때 이를 메소드에만 전달 ctx 하는 것이 올바른 사용법입니다 . 이렇게 하면 LogID가 전달될 수 있습니다. ctx client C.B_Call_C

그러나 실제 상황은 C 서비스를 요청하는 코드가 여러 레이어로 패키지되어 있어 ctx의 투명한 전송이 쉽게 누락되는 경우가 많습니다 . C 서비스에 대한 요청이 제3자에 의해 완료되는 경우가 더 많습니다. library 및 라이브러리의 인터페이스는 들어오는 코드를 지원하지 않으며 ctx 이러한 코드 변환에는 비용이 많이 들고 완료하려면 여러 팀의 조정이 필요할 수 있습니다.

이러한 문제점을 해결하기 위해 우리는 GLS(goroutine Local Storage) 기반의 세션 전송 메커니즘을 도입했습니다. 구체적인 계획은 다음과 같습니다.

Kitex 서버 측에서는 요청을 받은 후 먼저 GLS에 컨텍스트를 백업한 다음 비즈니스 코드인 Handler를 호출합니다.
요청을 보내기 위해 비즈니스 코드에서 클라이언트를 호출할 때 먼저 입력 ctx에 예상 티켓이 포함되어 있는지 확인하세요. 그렇지 않은 경우 GLS 백업에서 꺼내서 요청을 보내세요.

구체적인 예는 다음과 같습니다.

설명하다:

서버 초기화 시 ContextBackup 스위치를 켜주세요
클라이언트 초기화 시 하나를 지정하세요. backupHandler
각 요청이 이루어지기 전에 이 핸들러가 호출되어 입력 매개변수에 다음이 포함되는지 확인합니다. LogID
포함되지 않은 경우 백업에서 ctx 읽고 현재 ctx 백업에 병합한 후 반환합니다(반환은 useNewCtx = true Kitex가 이 새 ctx 항목을 사용하여 요청을 보내야 함을 의미합니다).

위의 설정을 켜면 비즈니스 코드가 잘못된 컨텍스트를 사용하더라도 전체 링크가 직렬로 연결될 수 있습니다.

마지막으로 핸들러의 새 고루틴에서 요청을 보내는 문제를 해결하는 서버 초기화의 비동기 매개변수를 소개하겠습니다. 동일한 고루틴이 아니기 때문에 로컬 저장소는 직접 공유할 수 없습니다. pprof의 고루틴 색상 메커니즘을 배우고 백업을 ctx 새 고루틴에 전달하여 비동기 시나리오 에서 암시적으로 티켓을 전달하는 기능 을 실현합니다 .

사용의 용이성

고성능과 풍부한 기능성 외에도 Kitex의 사용 편의성 향상에도 많은 관심을 기울이고 있습니다.

문서 |

우리 모두 알고 있듯이 프로그래머가 가장 싫어하는 두 가지가 있습니다. 하나는 문서를 작성하는 것이고 다른 하나는 문서를 작성하지 않는 것입니다. 따라서 우리는 문서 작성 초기 비용을 줄이는 것을 매우 중요하게 생각하고 문서 구축을 촉진하기 위해 열심히 노력합니다.

ByteDance 내에서 Kitex의 문서는 Feishu의 검색에 더 잘 통합되고 Byte 직원의 문의를 용이하게 할 수 있는 Feishu 지식 기반 형식으로 구성됩니다. Feishu 문서는 업데이트하기 쉽고 시기적절할 때 더 많이 업데이트됩니다. 새로운 기능이 개발되고 문서가 Feishu 지식 베이스에 먼저 작성되는 경우가 많으며 일부는 공식 웹사이트에 제때에 동기화되지 않습니다. 다양한 이유로 인해 내부 분기와 외부 분기 간의 차이가 커졌습니다.

따라서 지난 2분기 동안 우리는 새로운 문서 최적화 작업을 시작했습니다. 사용자 피드백을 기반으로 모든 문서를 재구성하고 더 많은 예제를 추가했으며 모든 문서를 영어로 번역하고 공식 웹사이트에 동기화했습니다. 이 작업은 올해 완료될 것으로 예상됩니다. 이미 공식 웹사이트에서 타임아웃 제어, 검소함, 패닉 처리 등 일부 업데이트된 문서를 볼 수 있습니다. 공식 웹사이트를 방문하여 버그를 잡는 데 도움을 주세요.

또한, 내부 문서를 공식 웹사이트에 자동으로 동기화하는 메커니즘도 구축하고 있습니다. 향후 오픈 소스 사용자도 내부 사용자처럼 적시에 업데이트된 문서를 얻을 수 있기를 바랍니다.

기타 최적화 |

문서화 외에도 Kitex는 다른 유용성 관련 작업도 수행합니다.

미들웨어, 전류 제한, 재시도, 타임아웃 제어 등 다양한 기능의 사용법을 예시로 보여주고 실제 프로젝트 코드를 통해 Kitex 사용자에게 참고 자료를 제공하는 샘플 프로젝트 "Note Service"를 출시했습니다. 여기에서 예제를 확인하세요: https://github.com/cloudwego/kitex-examples/tree/main/bizdemo/easy_note.

둘째, 우리는 문제 해결의 효율성을 높이기 위해 열심히 노력하고 있습니다. 예를 들어 일일 통화 요구 사항(예: 시간 초과 오류의 구체적인 이유, 패닉에 대한 메서드 이름)을 기반으로 오류 메시지에 보다 구체적인 상황 정보를 추가했습니다. 메시지 및 중고품 코덱 오류 메시지 등)을 통해 특정 문제 지점을 빠르게 찾을 수 있습니다.

또한 Kitex 명령줄 도구는 계속해서 개선되고 있습니다.

예를 들어, 많은 기업 사용자가 Windows에서 개발하는데, 이전에는 Kitex가 Windows에서 정상적으로 코드를 생성할 수 없었기 때문에 이러한 사용자도 지원하려면 Linux 환경이 필요했는데, 이는 이러한 사용자의 피드백을 기반으로 최적화되었습니다. .
또한 참조되지 않은 구조를 식별하고 코드를 생성할 때 직접 필터링할 수 있는 IDL 클리핑 도구를 구현했습니다. 이는 중단된 일부 오래된 프로젝트에 매우 유용합니다.

지역사회 협력 프로젝트

지난 해 CloudWeGo 커뮤니티의 지원으로 우리는 특히 Dubbo 상호 운용성과 구성 센터 통합이라는 두 가지 프로젝트에서 많은 결과를 얻었습니다.

Dubbo 互통 | 더보 인터커뮤니케이션

Kitex는 원래 Thrift RPC 프레임워크였지만 아키텍처 설계는 확장성이 좋습니다. 그림에서 볼 수 있듯이 새로운 프로토콜을 추가할 때 핵심 작업은 코덱 인터페이스에 따라 해당 프로토콜 코덱(Codec 또는 PayloadCodec)을 구현하는 것입니다.

Dubbo 상호 운용성 프로젝트는 기업 사용자의 요구에서 시작되었습니다. 그들은 Dubbo Java를 사용하여 공급업체에서 일부 주변 서비스를 구현하여 이러한 서비스를 요청하고 프로젝트 관리 비용을 절감하기를 희망합니다.

이 프로젝트는 지역사회 학생들의 열렬한 지지를 받았으며, 많은 학생들이 이 프로젝트에 참여했습니다. 특히 핵심 업무 중 하나를 담당하고 있는 @DMwangnima님은 Dubbo 커뮤니티의 개발자이기도 하므로, 개발 과정에서 많은 우회를 피했습니다.

구체적인 구현 계획에 관해서는 Dubbo 관계자와 다른 아이디어를 채택했습니다. hessian2 프로토콜 분석에 따르면 기본 유형 시스템이 Thrift와 기본적으로 겹치므로 Thrift IDL을 기반으로 Kitex Dubbo-Hessian2 프로젝트 스캐폴딩을 생성했습니다.

첫 번째 단계에서 기능을 빠르게 구현하기 위해 직렬화 및 역직렬화를 위해 Dubbo-go 프레임워크의 hessian2 라이브러리를 직접 빌려왔고, Dubbo 공식 문서 및 Dubbo-Go 소스 코드를 참조하여 Kitex 자체 DubboCodec을 구현했습니다.

10월에 코드의 첫 번째 버전이 완성되었습니다. 프로젝트 주소는 https://github.com/kitex-contrib/codec-dubbo 입니다 . 관심 있는 사용자는 위 문서에 따라 사용해 볼 수 있습니다. Thrift와 유사한 Kitex와 비교할 수 있으며 Thrift IDL을 작성하고 kitex 명령줄을 사용하여 스캐폴딩을 생성한 다음(프로토콜은 hessian2로 지정해야 함) 클라이언트와 서버가 초기화되는 코드에서 DubboCodec을 지정합니다. , 비즈니스 코드 작성을 시작할 수 있습니다.

이는 사용자 임계값을 낮출 뿐만 아니라 IDL을 사용하여 인터페이스 관련 정보를 관리하므로 유지 관리성이 향상됩니다.

현재 Kitex 와 Dubbo-Java, Kitex 및 Dubbo-Go 간의 상호 운용성을 달성할 수 있었습니다 .

향후 계획:

첫 번째는 dubbo-java와의 호환성을 개선하고 사용자가 IDL 주석에 해당 Java 유형을 지정할 수 있도록 하는 것입니다.
두 번째는 등록센터와의 연결이다. Kitex에는 이미 해당 등록 센터 모듈이 있지만 특정 데이터 형식이 Dubbo와 일치하지 않습니다. 이 영역은 여전히 일부 수정이 필요하며 관련 작업이 곧 완료될 예정입니다.
마지막으로, 성능 문제가 있습니다. 현재 Kitex Thrift와 비교하면 큰 격차가 있습니다. dubbo-go-hessian2 라이브러리는 전적으로 리플렉션을 기반으로 하기 때문에 여전히 성능 최적화의 여지가 많습니다. 인코딩과 디코딩의 성능 병목 현상을 해결하기 위해 Hessian2의 FastCodec을 구현할 계획입니다.

이 프로젝트를 진행하는 동안 우리는 커뮤니티 간 협력의 긍정적인 영향을 깊이 경험했습니다. Kitex는 Dubbo 커뮤니티의 성과를 흡수하고 위에서 언급한 Dubbo-go 프로젝트를 개선할 수 있는 영역도 발견했습니다. 또한 Dubbo 커뮤니티에도 도움이 될 것으로 예상됩니다.

또한 이 프로젝트를 완료하기 위해 많은 여가 시간을 할애해주신 이 프로젝트의 커뮤니티 기여자 @DMwangnima, @Lvnszn, @ahaostudy, @jasondeng1997, @VaderKai 및 기타 학생들에게 특별한 감사의 말씀을 전하고 싶습니다.

구성 센터 통합 | 구성 센터 통합 |

커뮤니티 협력의 또 다른 주요 프로젝트는 "구성 센터 통합"입니다.

Kitex는 클라이언트 시간 초과, 재시도, 회로 차단기 및 서버 전류 제한을 포함하여 동적으로 구성 가능한 서비스 관리 기능을 제공합니다.

이러한 서비스 거버넌스 기능은 Byte 내에서 많이 사용됩니다. 마이크로서비스 개발자는 Byte의 자체 구축 서비스 거버넌스 구성 플랫폼에서 이러한 구성을 편집할 수 있으며, 이러한 기능은 준실시간으로 적용됩니다. 마이크로서비스의 SLA를 개선하는 데 매우 도움이 됩니다.

그러나 우리는 기업 사용자들과 소통한 결과 이러한 기능이 일반적으로 사용하기가 매우 간단하고 세부성이 낮고 적시성이 부족하다는 사실을 발견했습니다. 하드 코딩된 지정된 구성만 있거나 간단한 파일을 통해 구성될 수 있으며 적용하려면 다시 시작해야 합니다. .

사용자가 Kitex의 서비스 거버넌스 기능을 더 잘 사용할 수 있도록 Kitex가 사용자 구성 센터에서 서비스 거버넌스 구성을 동적으로 가져와 거의 실시간으로 적용할 수 있도록 구성 센터 통합 프로젝트를 시작했습니다.

config-nacos v0.1.1 버전을 출시했습니다(참고: @whalecold의 지속적인 투자 덕분에 게시 시점에 v0.3.0으로 업데이트되었습니다). 기존 Kitex 프로젝트에 클라이언트를 추가하면 NacosClientSuite 됩니다. Kitex는 N acos에서 해당 서비스 거버넌스 구성을 로드하기 쉽게 만들 수 있습니다 .

nacos 클라이언트 자체에서 제공하는 감시 기능을 사용하기 때문에 구성 변경 알림을 준실시간으로 받을 수 있어 적시성도 매우 높고 서비스를 다시 시작할 필요가 없습니다.

또한 구성 세분성을 수정하는 기능도 예약했습니다. 예를 들어 기본 구성 세분성은 클라이언트 + 서버입니다. 이 형식으로 Nacos의 데이터 ID를 입력하면 사용자가 이 데이터 ID의 템플릿을 지정할 수도 있습니다. 예를 들어 컴퓨터실, 클러스터 등을 추가하여 이러한 구성을 보다 세밀하게 조정할 수 있습니다.

우리는 공통 구성 센터와의 통합을 완료할 계획입니다. 이번 호 https://github.com/cloudwego/kitex/issues/973에 더 자세한 지침이 있습니다.

현재 진행 상황은 다음과 같습니다.

file, apollo, etcd 및 Zookeeper와 같은 모듈은 PR을 제출했으며 검토 중입니다.
영사의 계획이 제출되었습니다.

관심 있는 학생들도 참여하여 이러한 확장 모듈을 검토, 테스트 및 확인할 수 있습니다.

미래 전망

마지막으로, 현재 우리가 시도하고 있는 몇 가지 방향에 대한 스포일러를 알려드리겠습니다.

병합 배포

선호도 배포 |

이전 최적화의 대부분은 서비스 내에 있었지만 최적화 지점 수가 점차 줄어들면서 RPC 요청의 네트워크 통신 오버헤드 최적화와 같은 다른 목표를 고려하기 시작했습니다.

구체적인 계획은 다음과 같습니다.

첫 번째는 선호도 스케줄링입니다. 컨테이너화된 스케줄링 메커니즘을 수정하여 클라이언트와 서버를 동일한 물리적 시스템에 스케줄링하려고 합니다.
따라서 동일 시스템 통신을 사용하여 오버헤드를 줄일 수 있습니다.

현재 우리가 구현한 동일 기계 통신에는 다음 세 가지 유형이 포함됩니다.

Unix 도메인 소켓은 표준 TCP 소켓보다 성능이 뛰어나지만 그다지 많지는 않습니다.
공유 메모리를 기반으로 하는 프로세스 간 통신인 ShmIPC (https://github.com/cloudwego/shmipc-go)는 직렬화된 데이터의 전송을 직접 생략할 수 있으며 수신자에게 메모리 주소만 알려주면 됩니다.
마지막으로 Run Process As Library의 약자인 "블랙 기술" RPAL 이 있습니다 . 우리는 Byte의 커널 팀과 협력하여 특정 조건이 충족되면 두 프로세스를 동일한 주소 공간에 배치합니다. 직렬화를 수행할 필요조차 없을 수도 있습니다.

현재 우리는 100개가 넘는 서비스에서 이 기능을 활성화했으며 더 나은 효과를 가진 서비스의 경우 CPU를 약 5~10% 절약하고 시간 소비를 10~70% 줄일 수 있습니다. 연습 성능은 패킷 크기와 같은 서비스의 일부 특성에 따라 달라집니다.

컴파일 시간 병합 서비스 인라인 |

또 다른 아이디어는 컴파일 타임 병합입니다.

이 솔루션의 출발점은 마이크로서비스가 팀 협업의 효율성을 향상시키기는 하지만 특히 서비스 배포, 리소스 점유, 통신 오버헤드 등의 측면에서 시스템의 전반적인 복잡성을 증가시킨다는 사실을 발견한 것입니다.

따라서 우리는 비즈니스를 마이크로서비스 형태로 개발하고 일반적으로 두 가지 서비스를 모두 갖춘 단일 서비스 형태로 배포할 수 있는 솔루션을 구현하고자 합니다.

그런 다음 우리는 이 계획을 세웠습니다. 두 마이크로서비스의 git repo를 함께 병합하고 네임스페이스를 통해 잠재적으로 충돌하는 리소스를 격리한 다음 배포를 위해 실행 가능한 프로그램으로 컴파일할 수 있는 도구를 개발했습니다.

현재 ByteDance 내에는 수십 개의 서비스가 연결되어 있습니다. 가장 효과적인 서비스는 CPU를 약 80% 절약하고 대기 시간을 최대 67%까지 줄일 수 있습니다. 물론 실제 성능은 요청 등 서비스 특성에 따라 달라집니다. 가방 크기.

위의 내용은 친화력에 대한 우리의 시도입니다.

직렬화

연재에 관해서는 아직도 몇 가지 노력과 시도를 하고 있습니다.

검소함 - SSA 백엔드

첫 번째는 Frugal입니다. 앞서 언급했듯이 기존 Thrift 인코딩 및 디코딩 코드보다 성능이 훨씬 뛰어나지만 여전히 개선의 여지가 있습니다.

Frugal의 현재 구현에서는 Go를 사용하여 해당 어셈블리 코드를 직접 생성합니다. 또한 보다 컴팩트한 코드 생성, 분기 감소 등 특정 구현에 몇 가지 최적화 방법을 적용했습니다. 그러나 기존 컴파일러 최적화 기술을 직접 작성하는 것만으로는 최대한 활용할 수 없습니다.

우리는 go struct를 기반으로 SSA 호환 LLVM IR(중간 표현)을 생성하기 위해 Frugal을 재구성하여 LLVM의 컴파일 최적화 기능을 최대한 활용할 계획입니다.

이번 변화를 통해 성능은 최소 30% 이상 향상될 수 있을 것으로 예상된다.

주문형 직렬화 주문형 직렬화 |

또 다른 탐구 방향은 주문형 직렬화인데, 이는 세 부분으로 나눌 수 있습니다.

첫 번째는 컴파일 전입니다. 우리는 현재 참조되지 않은 유형을 식별할 수 있는 IDL 클리핑 도구를 출시했습니다. 그러나 참조된 유형은 필요하지 않을 수 있습니다. 예를 들어 두 서비스 A와 B는 동일한 유형에 의존하지만 필드 중 하나는 A일 수 있습니다. 필수, B는 필요하지 않습니다. 우리는 이 도구에 사용자 주석 기능을 추가하여 사용자가 불필요한 필드를 지정할 수 있도록 하여 직렬화 오버헤드를 더욱 줄이는 것을 고려하고 있습니다.

두 번째는 컴파일이다. 아이디어는 실제로 비즈니스 코드 참조를 위반하는 필드를 얻고 컴파일러의 컴파일 보고서를 기반으로 이를 정리하는 것입니다. 구체적인 계획과 정확성에는 여전히 약간의 검증이 필요합니다.

마지막으로, 컴파일 후 런타임 시 비즈니스에서는 불필요한 필드를 지정할 수 있으므로 인코딩 및 디코딩 오버헤드가 절약됩니다.

요약 |

마지막으로 전반적인 상황을 검토해 보겠습니다.

능력 업그레이드 측면에서는

Kitex는 DynamicGo를 통해 일반화 호출 성능을 최적화했으며 고성능 Frugal 코덱이 안정화되어 프로덕션 환경에서 사용할 수 있습니다.
작년에는 기업이 맞춤형 다운그레이드 전략을 쉽게 구현할 수 있도록 폴백이 추가되었으며, 긴 링크 변환 문제를 해결하기 위해 알 수 없는 필드와 세션 전달 메커니즘이 사용되었습니다.
또한 문서 최적화, 데모 프로젝트, 문제 해결 효율성 향상 및 향상된 명령줄 도구를 통해 Kitex의 유용성을 개선했습니다.

지역사회 협력 측면에서는

우리는 Dubbo Java 및 Dubbo-Go 프레임워크와 상호 운용할 수 있는 Kitex-Dubbo 상호 운용성 프로젝트를 통해 Dubbo의 hessian2 프로토콜을 지원하며, Dubbo 커뮤니티에 피드백할 수도 있는 후속 최적화도 있습니다.
구성 센터 통합 프로젝트에서는 사용자 통합을 용이하게 하기 위해 Nacos 확장을 출시했으며 현재 다른 구성 센터의 도킹을 계속 추진하고 있습니다.

앞으로 탐구해야 할 몇 가지 방향은 아직 남아 있습니다.

병합 배포 측면에서 선호도 배포와 컴파일 및 병합을 통해 마이크로서비스의 이점을 유지할 수 있을 뿐만 아니라 서비스를 제공하지 않는 일부 모놀리스의 이점도 누릴 수 있습니다.
직렬화 측면에서 우리는 계속해서 Frugal을 더욱 최적화하고 컴파일 전, 도중, 후에 컴파일의 모든 측면을 통해 주문형 직렬화 기능을 달성합니다.

이상은 CloudWeGo 2주년을 맞아 Kitex에 대한 리뷰와 전망입니다. 모든 분들께 도움이 되었으면 좋겠습니다. 감사합니다.