Kong으로 단일 데이터베이스 분할

우리의 생활에서 어떤 일들은 마치 관례적인 공적인 일일 뿐인 것 같지만, 의외로 그것들은 우리의 여정에 깊은 영향을 미쳤다.나에게 있어서 그 중 하나는 2008년 플로리다 주 올랜도에서 열린 Gartner 대회에 참가하는 것이다.
그 활동은 나로 하여금 처음으로 Salesforce 생태계를 이해하게 할 뿐만 아니라 다음과 같은 개념도 이해하게 했다.

Service-Oriented Architecture(로이 슈르트(Roy Schulte)를 통한 인상적인 강연)

Web 2.0 및 Mashups

RESTful API Design

비록 나는 이번 활동에 대한 기대가 높지 않지만, 플로리다 중부의 그 며칠은 내 경력의 향후 13년 동안의 관심의 관건이 되었고, 나의 어떤 기대보다 훨씬 높았다.
도중에 나는 이런 개념에 전념한 프로젝트와 제안에서 많은 교훈을 얻었다.본고에서 저는 RESTful API를 응용 프로그램 디자인의 핵심에 두는 프로젝트에서 얻은 몇 가지 경험과 교훈을 깊이 있게 연구하고자 합니다.

RESTful API의 트랩

RESTful API 소프트웨어 스타일은 클라이언트 애플리케이션에 비즈니스 요구 사항을 충족하는 데 필요한 리소스(데이터)를 쉽게 액세스할 수 있도록 합니다.실제로 Angular, React, Vue 등 자바스크립트 기반 프레임워크는 곧 RESTful API에 의존해 웹 기반 앱 시장을 이끌었다.
이러한 RESTful 서비스api와 전단 자바스크립트 프레임워크의 모델은 많은 조직들이 단일하거나 유행이 지난 응용 프로그램에서 프로젝트를 이전하는 것에 대한 지원을 불러일으켰다.RESTful API 모델은 아직도 Great Recession의 충격에서 회복되고 있는 기술경제에 시급한 진작을 제공했다.
몇 개의 민첩한 교체를 이 새로운 개발 모델에 신속하게 추진하고 반복적으로 만나는 두 개의 함정은 피하는 것보다 많다.

유행이 지난 응용 프로그램 디자인은 결국 매우 큰 RESTful API와 같은 크기의Javascript 프레임워크로 대체되었다.이것은 미래의 기능과 강화를 조율하는 데 도전을 가져왔다.기본적으로 큰 바위 하나가 다른 큰 바위에 의해 대체되었다.

남겨진 응용 프로그램 디자인은 여러 개의 RESTful API와 자바스크립트 프레임워크를 사용하는 구성 요소화 클라이언트를 사용했지만 데이터베이스 하나만 사용했다.이러한 디자인의 결과는 데이터 소유권 충돌, 데이터베이스 연결 수가 예상보다 많고 대형 데이터베이스를 지원/유지하는 비용이 더욱 높다.

다음은 트랩 #2의 예로, 여러 서비스가 데이터베이스에서 리소스를 놓고 다툰 것입니다.

불행하게도 저는 녹지 개발 기회에서도 같은 장면을 보았습니다. 사람들은 하나의 데이터베이스를 사용하여 전체 마이크로 서비스 집합을 제공하는 경향이 있습니다.

마이크로 서비스는 데이터베이스부터 시작해야 한다

대부분의 프로그래밍 언어에서는 하나의 파일로 기능이 완비된 프로그램을 만들 수 있다.Java에서는 모든 컨텐트가 같은 클래스 파일에 있을 수 있으며 main() 메서드를 호출하기만 하면 됩니다.

public class SingleClassApplication {
    public static void main(String[] args) {
        // Start doing something really cool here
    }
}

그러나 이런 방법은 그다지 지지를 받지 못하고 여러 개발자의 가벼운 공헌에도 이롭지 않다.
응용 프로그램의 각 방면에 관련될 때'소유권'(또는 기록 시스템)의 개념도 있다.만약에 하나의 서비스나 기능이 특정한 물건(예를 들어 고객)의 소유자라고 주장하는 것이 아니라면 업무 규칙이 동시에 나타나지 않으면 도전이 생길 것이다.여러 RESTful API가 지정된 객체의 소유권을 선언하는 경우에도 마찬가지입니다.
이러한 동일한 개념은 RESTful API 설계를 사용하면 데이터베이스 레이어로 바뀝니다.다음 지침을 고려하십시오.

A single RESTful API should be considered the system of record for a given aspect of the application. As such, the corresponding data tier should leverage a data store focused solely on that aspect of the application.

다음 그림은 이 설명서와 일치하는 마이크로서비스 설계를 보여 줍니다.

성공적인 마이크로 서비스 설계는 데이터베이스에서 시작되었다.일단 도착하면 고객이 지정한 서비스에 대한 수요를 충족시키기 위해 확장하는 것은 어떠한 다른 서비스에도 영향을 미치지 않는다.

대비: 데이터베이스 제약은?

내가 추천하는 방법은 전용 데이터베이스로 주어진 마이크로 서비스를 격리하는 것이다.이렇게 하면 관련 어셈블리의 수량과 크기를 사용자 요구사항과 일치시킬 수 있으며 동일한 요구 수준이 아닌 컴포넌트의 추가 비용을 방지할 수 있습니다.
데이터베이스 관리자는 응용 프로그램의 모든 요소가 하나의 데이터베이스에 존재할 때 제약과 관계가 제공할 수 있는 장점을 알아차리고 하나의 데이터베이스 디자인을 변호했다.예를 들어 삭제를 기다리는 고객과 관련된 주문이 존재하면 하나의 데이터베이스 디자인으로 고객의 요청을 삭제할 수 없습니다.
데이터베이스가 있으면 분명 좋은 점이 있지만 모든 마이크로 서비스에 데이터베이스를 사용하도록 선택하기 전에 다음과 같은 몇 가지를 고려하십시오.

단일 데이터베이스를 사용하여 얻은 장기적인 가치와 단일 대형 데이터베이스를 확장하는 데 드는 비용을 비교한다.향후 단일 데이터베이스 설계를 확장하고 지원하는 데 예상되는 비용은 얼마입니까?

API 계층에서 이러한 구속을 적용할 위험과 가치는 무엇입니까?단일 마이크로 서비스는 주어진 데이터베이스의 소유자로 간주되기 때문에 업무 논리상 이벤트 주문서를 가진 고객을 삭제할 수 없다는 것을 명심하십시오.

이벤트 드라이브(또는 메시지 기반) 디자인을 사용하여 하나의 마이크로 서비스가 요청을 어떻게 처리하는지는 다른 마이크로 서비스의 응답 상황에 따라 결정되는 장점을 고려한다.이것은 하나의 응용 프로그램/하나의 데이터베이스 디자인과 유사하지만 필요할 때 전용 처리 능력을 확장하고 분배하는 능력을 분리하고 제어할 수 있다.

물론 데이터베이스가 하나의 전용 서비스 실례만 지원하더라도 제약과 관계를 실현하고 실시해야 한다.

공공 원소는 추상화되어야 한다

만약 계획이 부적절하면, 진정한 마이크로 서비스 설계를 채택하면 부작용을 초래할 수 있다.내가 계속 보고 있는 가장 큰 도전은 공공 구성 요소와 서비스 층의 중복이다.
다음 목록은 각 마이크로서비스에서 자주 반복되는 요소의 예를 제공합니다.

인증

캐시

측정

모니터링

안전

사실 이 예를 고려해 보면, 나는 올해 초의 '글에서 이 예를 소개했다.

생명주기의 모든 면을 개발하는 것처럼 우리는 가능한 한 사물의 건조함을 유지하는 것에 항상 관심을 가져야 한다.이것은 응용 프로그램 창고의 공공 단계나 다른 단계에서 추상적이고 처리할 수 있는 요소를 포함한다.
내가 자주 추천하는 방법 중 하나는 Kong가 제공하는 분포식 마이크로 서비스 추상층 방법이다.

이상적인 디자인의 중심에 구멍 배치하기

Kong Gateway 서비스 계층 API의 복잡성을 비즈니스 요구 사항과 기능을 충족하는 데 초점을 둔 단일 엔드포인트(또는 URI) 그룹으로 줄일 수 있습니다.일반적으로 반복되는 구성 요소(예를 들어 신분 검증, 로그 기록과 안전성)는 게이트웨이가 처리하고 서비스 층 설계에서 삭제할 수 있다.
각 RESTful 마이크로서비스는 전용 데이터베이스 인스턴스를 유지하고 반복되는 구성 요소를 추상화합니다. 다음 그림은 의도 기반 마이크로서비스 세트입니다.

서비스 간 통신은 메시징 계층을 통해 처리되며 이 계층은 공용enterprise integration patterns을 사용합니다. 예를 들어 다음과 같습니다.

Command Message - 백그라운드 작업을 수행하기 위해 다른 서비스를 호출

Document Message - 추가 서비스로부터 요청된 정보

Event Message - 특정 주제를 청취하는 모든 사람에게 정보를 브로드캐스트

Request-Reply - 다른 서비스에 요청 및 응답 수신

이 디자인은 현실 생활의 장점을 고려한다.

노드의 경우js 서비스의 사용률이 예상보다 높고 수요를 만족시키기 위해 확장하는 비용은 서비스와 전용 데이터베이스와 무관하다.

만약에 어떤 서비스가 데이터 저장 변경이 첫 번째 선택(예를 들어 SQL에서NoSQL까지)이라는 것을 의식한다면 RESTful API URI가 변경되지 않으면 새로운 디자인은 다른 서비스에 거의 영향을 주지 않고 배치할 수 있다.

추상적인 층 구성 요소의 변경(예를 들어 새로운 로그 기록 방법을 사용)은 모두 네트워크 인터페이스 층에서 할 수 있고 하부 서비스에 영향을 주지 않는다.

결론

2021년부터 저는 다음과 같은 사명 선언을 따르기 위해 노력해 왔습니다. 이것은 모든 IT 전문가에게 적용된다고 생각합니다.

“Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”

• J. Vester

본고의 주요 목표는 진정한 마이크로 서비스 디자인을 실현하는 것이고 전용 데이터베이스를 포함하지만 Kong은 진정한 마이크로 서비스 디자인에 확장 가능하고 사용하기 쉬운 핵심 부분을 제공한다.실제로 Kong Gateway는 개발자가 시원함을 유지하고 유니버설 구성 요소를 분포식 마이크로 서비스 추상층에 도입할 수 있도록 한다.
기억해라. '마이크로 서비스' 는 '마이크로' 라는 단어를 포함하는데, 통상적으로 '매우 작다' 라고 정의된다어떤 마이크로 서비스의 실현 과정에서든지 반드시 이 기본 전제를 명심해야 한다.
기능 개발자는 소프트웨어 패키지와 클래스를 이용하여 프로그램 코드를 그룹으로 나누어 지원 가능성과 유지보수성을 실현한다.이러한 클래스에서 방법과 함수의 정의는 일반적으로 하나의 규칙을 채택하는데, 즉 모든 코드 블록이 매우 작고 이해하기 쉽다는 것이다.나에게 있어서 이상적인 함수나 방법은 마우스를 만지지 않고 되돌아볼 수 있는 함수나 방법이다.
마이크로 서비스는 프로그래머가 수십 년 동안 지켜온 규칙의 연장이어야 한다. 사물의 소형화, 목표 구동, 효율을 유지하고 사물의'미형화'를 유지하는 것이다.
이 목표를 달성하기 위해서 디자인은 반드시 데이터베이스를 포함해야 한다.
오늘 하루 즐겁게 보내세요!