안녕하세요, 앞으로 몇 달에 걸쳐 Couchbase .NET 2.0 SDK의 개발 과정을 소개하는 블로그 시리즈를 연재할 예정입니다. 이 글에서는 높은 수준의 아키텍처, 몇 가지 동기 부여 및 기능, 그리고 다른 Couchbase 클라이언트와 관련하여 .NET SDK의 전반적인 목표가 무엇인지에 대해 살펴볼 것입니다: 전체 Couchbase 클라이언트 제품군의 범위 내에서 .NET SDK의 목표를 논의하는 것은 개발자가 어떤 SDK를 선택하든 일관된 프로그래밍 경험을 할 수 있도록 API를 통합하는 데 있어 중요한 단계입니다.

역사 및 동기 부여

먼저 Couchbase .NET SDK를 다시 작성하게 된 동기에 대해 이야기해 보겠습니다. 거의 모든 구성 요소를 고객과 사용자 커뮤니티 전반의 요구 사항에 더 잘 맞도록 재설계하고 재개발하는 등 처음부터 완전히 다시 작성하는 작업이라는 점에 유의하세요. 지금쯤이면 대부분의 사용자들이 소프트웨어 회사가 할 수 있는 최악의 전략적 실수 중 하나는 작동하는 기능적 코드를 처음부터 다시 작성하는 것입니다., 하지만 Couchbase는 .NET 1.X SDK의 역사와 상태, 그리고 클라이언트와 함께 가고자 하는 방향을 고려할 때 이것이 최선의 결정이라고 생각합니다.

여기서 약간의 역사가 필요할 수 있습니다. 현재 클라이언트는 원래 Memcached .NET 클라이언트를 기반으로 합니다: Enyim.Caching. 몇 년 전에 작성되었으며 원래는 Memcached 텍스트 프로토콜을 지원했고 나중에는 Memcached 바이너리 프로토콜도 지원했습니다. 그 자체로 다른 API를 만들기 위한 프레임워크가 아닌 독립형 API로 설계되었습니다. 즉, 현재 .NET Couchbase 클라이언트는 Enyim.Caching 소스의 포크 위에 구축되었으며, 훌륭한 지원자였던 원저자가 더 이상 프로젝트를 지속하는 데 필요한 시간이 없었기 때문에 포크가 이루어졌습니다. Couchbase 클라이언트는 Enyim.Caching에서 이미 지원하던 K/V 기능 위에 보기 지원 및 기타 Couchbase Server 전용 기능을 추가했습니다.

클라이언트는 원래 K/V 기반 프로토콜을 기반으로 했기 때문에 Couchbase의 일부 기능을 적용하는 것은 다소 까다로운 API를 만들었습니다. 게다가 더 많은 레이어가 추가됨에 따라 복잡성이 증가하여 클라이언트를 지원하고 유지 관리하기가 점점 더 어려워졌습니다. 또한 클라이언트가 실제로 .NET 3.5를 기반으로 하고 있기 때문에(4.0용으로 빌드하고 있지만 3.5는 LCD입니다) 강력한 새 Task(async/await) 기반 비동기 라이브러리/기능 및 네트워킹 API의 개선 사항과 같은 최신 .NET 기능을 사용하지 못하고 있었습니다. 따라서 이전 버전과의 호환성을 유지하고 클라이언트를 발전시키는 것은 불가능하며, 완전히 새로운 방향으로 나아가야 합니다.

목표 및 기능

Couchbase .NET 2.0 SDK의 목표/목적은 매우 간단합니다:

• 모든 Couchbase SDK 플랫폼(Java, .NET, PHP, Node, C 등)에서 프로그래밍 인터페이스의 통합 및 일관성 유지
• 유연한 테스트 중심 설계 - 핵심은 확장성입니다.
• 고도의 구성이 가능하지만 기본 구성으로 쉽게 시작하고 실행할 수 있습니다.
• 비동기 I/O - 네트워크 프로그래밍을 위한 비차단 모델
• 간단하고 사용하기 쉬운 프로그래밍 인터페이스
• 클라이언트/서버 연결의 최소한의 사용
• 개선된 문서화

몇 가지 가능한 기능은 다음과 같습니다:

• 클러스터 캐리어 구성 게시 지원(CCCP) - 풀 메커니즘을 통해 클러스터의 현재 상태를 기반으로 클라이언트 구성을 업데이트하는 새로운 방법입니다.
• 작업 기반 비동기 패턴(TAP) K/V 및 보기 작업 지원
• 퍼스트 클래스 N1QL 지원 - N1QL은 Couchbase의 멋진 새 SQL 유사 쿼리 언어입니다.
• A LINQ 핵심 API를 통한 공급자 구현
• 데이터 기반 애플리케이션을 빠르게 개발하기 위한 ASP.NET 및 프레임워크와 같은 다른 .NET 기술과의 통합 지점

높은 수준의 아키텍처

지난 몇 년 동안 Couchbase의 SDK 팀은 .NET, Java, Node.js 등 다양한 플랫폼과 프레임워크에서 여러 Couchbase Server 클라이언트를 개발해 왔습니다. 이러한 각 클라이언트가 서버의 변화에 따라 개발되고 발전하면서 클러스터 인식 클라이언트, 더 구체적으로는 Couchbase의 경우 "스마트" 클라이언트를 개발하기 위한 몇 가지 패턴이 나타났습니다. "프로그래밍 인터페이스 통합"이라는 목표 아래 각 클라이언트 내에서 이러한 패턴을 구현합니다. 다음 글에서 이러한 패턴에 대해 자세히 설명하겠습니다.

카우치베이스 클라이언트 구성 요소

이러한 구성 요소는 Couchbase 클라이언트를 구성합니다:

• IO - 리소스 관리 및 일반 네트워크 프로그래밍 액세스
• 구성 - 클라이언트 및 서버 구성
• 작업 - JSON 문서의 키/값 및 보기 작업: 가져오기, 설정 등
• 클러스터 맵 - 활성 노드 및 클러스터 전체에서 키가 저장된 위치를 관리합니다.
• 로깅 및 계측 - 클라이언트 활동의 일반적인 로깅, 추적 및 모니터링

다음 단계

여기까지입니다. 다음에는 구성 구성 요소의 한 부분에 대한 설계 및 개발에 대해 살펴보겠습니다: 서버 구성입니다. 서버 구성은 클러스터의 상태와 유사한 클라이언트 상태를 구동합니다. 일반적으로 클러스터의 변경은 클라이언트 상태의 변경을 의미하므로 안정성을 유지하기 위해 해결해야 하는 다양한 복잡성과 문제가 수반됩니다.