마이크로 서비스 및 저장 프로 시저

마이크로 서비스 아키텍처에서 저장 프로 시저가 나쁜 습관으로 간주됩니까?

내 생각은 다음과 같습니다.

• 마이크로 서비스에 관한 대부분의 책은 마이크로 서비스 당 하나의 데이터베이스를 권장합니다. 저장 프로시 저는 일반적으로 모 놀리 식 데이터베이스에서 작동합니다.

• 다시 말하지만 대부분의 마이크로 서비스 아키텍처 서적은 자율적이고 느슨하게 결합되어야한다고 말합니다. 특히 Oracle에서 작성된 저장 프로 시저를 사용하면 마이크로 서비스가 해당 기술에 밀접하게 연결됩니다.

• 필자가 읽은 대부분의 마이크로 서비스 아키텍처 서적은 마이크로 서비스가 비즈니스 중심 ( 도메인 기반 디자인 (DDD)을 사용하여 설계)되어야한다고 권장합니다 . 비즈니스 로직을 데이터베이스의 저장 프로 시저로 이동하면 더 이상 그렇지 않습니다.

이것에 대한 생각?

마이크로 서비스와 함께 스토어드 프로 시저 사용을 명시 적으로 금지하거나 주장하는 것은 없습니다.

면책 조항 : 개발자 POV의 저장 프로 시저를 좋아하지 않지만 마이크로 서비스와 관련이 없습니다.

저장 프로시 저는 일반적으로 모놀리스 데이터베이스에서 작동합니다.

나는 당신이 논리적 오류에 굴복한다고 생각합니다.

현재 저장 프로 시저가 감소하고 있습니다. 여전히 사용중인 대부분의 저장 프로시 저는 기존 코드베이스에서 유지됩니다. 당시에는 모 놀리 식 데이터베이스가 마이크로 서비스가 대중화 될 때보 다 훨씬 널리 보급되었습니다.

저장된 procs와 모 놀리 식 데이터베이스는 모두 오래된 코드베이스에서 발생하므로 더 자주 함께 볼 수 있습니다. 그러나 그것은 인과 관계가 아닙니다. 당신은 저장 발동를 사용하지 않는 때문에 당신이 monololithic 데이터베이스를 가지고있다. 저장된 procs를 사용 하기 때문에 단일 데이터베이스가 없습니다 .

마이크로 서비스에 관한 대부분의 책은 마이크로 서비스 당 하나의 데이터베이스를 권장합니다.

이러한 작은 데이터베이스가 저장 프로 시저를 가질 수없는 기술적 이유는 없습니다.

내가 언급했듯이, 나는 저장된 procs를 좋아하지 않습니다. 나는 그것들이 성 가시고 미래의 유지 보수에 내성을 가지고 있습니다. 많은 작은 데이터베이스에 sprocs를 퍼 뜨리면 이미 원하지 않는 문제가 더욱 악화된다고 생각합니다. 그러나 이것이 할 수 없다는 것을 의미하지는 않습니다.

다시 말하지만 대부분의 마이크로 서비스 아키텍처 서적은 자율적이고 느슨하게 결합되어야한다고 말합니다. Oracle에서 구체적으로 작성된 저장 프로 시저를 사용하여 마이크로 서비스를 해당 기술에 긴밀하게 연결합니다.

다른 한편으로, 마이크로 서비스가 사용하는 ORM에 대해 동일한 주장을 할 수 있습니다. 모든 ORM이 모든 데이터베이스를 지원하지는 않습니다. 커플 링 (구체적으로 견고 함)은 상대적 개념입니다. 합리적으로 가능한 한 느슨해 져야합니다.

Sproc은 일반적으로 마이크로 서비스와 상관없이 밀접한 결합으로 어려움을 겪습니다. 나는 일반적으로 sprocs에 대해 조언 할 것이지만, 특히 마이크로 서비스를 사용하고 있기 때문에 그렇지 않습니다. 그것은 전과 같은 주장입니다 : 나는 sprocs가 (일반적으로) 갈 길이라고 생각하지 않지만, 그것은 내 편견 일 수 있으며 마이크로 서비스와 관련이 없습니다.

읽은 대부분의 MSA 서적은 마이크로 서비스가 비즈니스 지향적 (ddd를 사용하여 설계)이어야한다고 권장합니다. 비즈니스 로직을 데이터베이스의 저장 프로 시저로 이동하면 더 이상 그렇지 않습니다.

이것은 항상 데이터베이스의 비즈니스 로직 인 sprocs에 대한 나의 주된 관심사였습니다. 의도가 없더라도 항상 그런 식으로 끝나는 경향이 있습니다.

그러나 다시 말하지만 마이크로 서비스 사용 여부에 관계없이 그 그립이 존재합니다. 더 큰 문제로 보이는 유일한 이유는 마이크로 서비스가 전체 아키텍처를 현대화하도록 강요하고 sprocs가 더 이상 현대 아키텍처에서 선호되지 않기 때문입니다.

소프트웨어를 작성하려면 기술과 밀접한 관련이 있어야합니다.

적어도 개발중인 프로그래밍 언어에 의해 제공되는 런타임 환경.

보다 일반적으로 마이크로 서비스는 여러 기술과 밀접하게 연결되어 있습니다.

• 높은 수준의 HTTP / SSL / SOAP 프로토콜 구현을 제공하는 네트워크 서비스 프레임 워크
• 지속성을 제공하기위한 저장소 / ORM / DAO 프레임 워크
• 데이터 조작 프레임 워크로 데이터 작업을위한 도구를 제공합니다.
• 멀티 태스킹, 파일 시스템, 메모리, GPU 컴퓨팅, 확장 카드 등과 같은 OS 리소스에 대한 액세스를 제공하는 프로세스 / 스레딩 / OS 프레임 워크

그리고 그것은 베어 본 마이크로 서비스를 만드는 것입니다.

저장 프로 시저

저장 프로시 저는 사용하거나 사용하지 않도록 선택할 수있는 또 다른 기술입니다. 마술처럼 코드를 모 놀리 식으로 만들지 않습니다.

그것이 무엇입니까 :

• 다른 기술. 응용 프로그램에있는 각 기술은 해당 프로그래머가 해당 기술 믹스를 읽고 이해하고 현명한 디자인을 선택할 수있는 가능성을 줄입니다.
• 다른 프로그래밍 패러다임을 사용하는 언어 전문가가 아닌 사람들이 자신의 명령, 기능, OO 등의 관점을 시도하고 강요하기가 너무 쉬워 종종 별보다 적은 결과를 초래합니다.
• API. 코드베이스의 다른 클래스와 같이 유지 관리해야합니다. 또한 데이터베이스가 제네릭이 아닌 인터페이스를 제공하고 있음을 의미합니다. 따라서 데이터베이스 엔진 자체를 교체하고 메모리 캐싱과 같은 일반적인 동작을 투명하게 적용하기가 더 어려워집니다.
• 인공물. 버전 관리, 테스트 및 배포해야합니다. 이 작업을 수행 할 수 있지만 데이터베이스는 다른 접근 방식이 필요한 살아있는 인공물입니다. 일반적으로 원본을 삭제하고 교체 할 수는 없습니다. 시스템을 원하는 상태로 마이그레이션하려면 시간이 지남에 따라 변경 사항을 신중하게 조정해야하는 경우가 종종 있습니다.

이들 각각은 실제 비용입니다. 어떤 경우에는 비용이 합리적이며 다른 경우에는 그렇지 않습니다.

스크립팅 엔진을 호스팅하여 거의 동일한 비용을 지불하게됩니다. 유일한 감소는 호스트 언어와 동일한 프로그래밍 패러다임을 선택할 수 있다는 것입니다.

비즈니스 로직

비즈니스 규칙을 데이터베이스로 옮기는 것은 나쁜 습관입니다. 저장 프로 시저 때문이 아닙니다.

데이터베이스와 비즈니스 로직이 다른 전단 수준에서 작동하기 때문에 나쁜 습관입니다.

• 성숙한 응용 프로그램의 데이터베이스는 수십 년 동안 사용할 수 있습니다. 일반적으로 이러한 시스템은 엔진을 주기적으로 업데이트하지만 데이터베이스 자체는 마이그레이션되었습니다. 처음부터 죽이고 재건되지 않았습니다. 마이크로 서비스가 그렇게 오래 살 수없는 이유는 없습니다.

• 비즈니스 규칙이 얼마나 빨리 변하는 지에 대비하여 수십 년을 대조하십시오. 내 경험에 따르면 오래된 비즈니스 규칙은 아마도 몇 년이되었을 것입니다. 그러나 대부분은 빠르게 변경되며, 다음 규칙 중 어떤 규칙이 변경 될지는 절대 알 수 없습니다. 규제 기관의 새로운 요구 사항, 폐기 된 오래된 제품, 레터 헤드 변경, 상사에게보고하는 직원 수 등 변경 등 ...

비즈니스 로직이 전단 레이어, 특히 느리고 수명이 긴 레이어에 분산되면 변화에 대한 저항이 생깁니다. 반드시 나쁜 것은 아닙니다. 결국 비즈니스 로직이없는 유일한 데이터베이스는 트리플 스토어입니다.

테이블 스키마를 지정하는 것은 비즈니스 로직을 데이터베이스로 옮기는 것입니다.

건축물

솔루션을 만들고 유지하기 위해 너무 많은 도구가 필요하지 않고 해결하기가 너무 어려워지지 않고 적절한 문제에 적합한 도구를 사용하는 데 경쟁하고 있습니다.

쉽지 않습니다.

그러나 여러 언어에 분산 된 비즈니스 로직을 어떻게 유지 하시겠습니까?

• 각 비즈니스 규칙 구현을 추적하고 유지 관리 할 수있는 카탈로그.
• 테스트는 어디에서 어떻게 구현되었는지에 관계없이 각 비즈니스 규칙에 대해 사용될 수 있습니다.
• 불일치가 발견 될 때 진실의 근원 (또는 최소한 토론의 근원)이 존재하도록 참조 구현.

그러나 이것 역시 비용이 든다.

• 비즈니스 규칙에 많은 구현을 허용하는 것이 더 낫습니까? 그것은 각각 팀 기술과 프레임 워크 조항을 이용할 수 있지만 많은 작은 vagaries를 막기 위해 엄격한 품질 관리가 필요합니까?
• 아니면 단일 언어로 작성된 하나의 진실 된 출처를 갖는 것이 더 낫습니까? 다른 플랫폼, 프레임 워크 또는 아직 발명되지 않은 툴에 직면 한 변화에 저항하는 단일 구성 요소 자체를 구현하는 데 비용이 적게 들지만, 단일 실패 원인일까요?

저장 프로 시저를 사용하는 몇 가지 마이크로 서비스를 실제로 유지 관리한다고 말함으로써 대답을 시작합니다. 또한 나는 경력의 여러 시점에서 많은 저장 프로 시저를 작성했으며 잘못 사용하면 상황이 매우 잘못 될 수 있음에 동의합니다.

따라서 짧은 답변은 마이크로 서비스 아키텍처에서 저장 프로 시저가 본질적으로 나쁘지 않다는 것입니다. 그러나 다음을 이해해야합니다.

1. 스토리지 엔진 대체에 장애물을 추가하고 있습니다. 일부 운영 또는 성능 특성 또는 기능 제한으로 인해 스토리지 엔진을 전환해야하는 경우 많은 새로운 코드를 작성하고 테스트하기 때문에 비용이 더 많이 듭니다. 마이그레이션 단계에서 또는 성능 요구에 따라 활동을 분리하기 위해 둘 이상의 스토리지 엔진을 실행하면 성능 문제가있는 2 단계 커밋 (2PC)을 사용하지 않는 한 일관성 문제가 발생할 수 있습니다.
2. 유지 관리 할 다른 API가 있으므로 종속성이 손상 될 수 있습니다. 프로 시저에서 매개 변수 유형을 추가, 제거 또는 변경하면 기존 코드가 손상 될 수 있습니다. 테이블과 쿼리에서도 같은 일이 발생하지만 문제가 발생한 위치를 추적하는 데 도구의 유용성이 떨어질 수 있습니다. 저장 프로 시저 관련 문제는 일반적으로 개발 / 배포 프로세스에서 매우 늦게 런타임에 발견됩니다.
3. 데이터베이스 권한이 더욱 복잡해졌습니다. 프로 시저가 로그인 한 사용자 또는 다른 역할로 실행됩니까? 이에 대해 생각하고 관리해야합니다 (자동으로 자동화 된 방식으로).
4. 새 버전으로 안전하게 마이그레이션 할 수 있어야합니다. 종종 절차를 삭제하고 다시 만들어야합니다. 다시 한 번 권한으로 인해 문제가 발생할 수 있습니다.
5. 실패한 마이그레이션 롤백은 추가 노력을 의미 할 수 있습니다. 프로덕션 환경이 개발자와 분리되면 상황이 더욱 어려워집니다.

이것들은 종종 가치가 있다고 생각하는 저장 프로 시저의 일부 사용입니다.

1. 편집 이력 시행 (감사 로그). 트리거는 일반적으로이 목적으로 사용되며 트리거는 저장 프로 시저입니다. 일부 데이터베이스에서는 응용 프로그램 역할에 대한 삽입 및 업데이트를 완전히 허용하지 않을 수도 있습니다. 클라이언트는 적절한 권한으로 다른 역할로 실행되고 필요한 모든 동작을 적용하는 프로 시저를 실행합니다.
2. 점검 제한 조건의 확장. 이로 인해 비즈니스 논리 영역에 들어갈 수 있지만 데이터베이스의 기본 제공 제한 도구가 필요한 것만으로는 충분하지 않은 경우가 있습니다. 수표를 표현하는 가장 좋은 방법은 명령 코드를 사용하는 경우가 많으며, 응용 프로그램에 의존하여 데이터를 잘못 사용하면 데이터가 잘못 될 위험이 있습니다.
3. 보기가 부적절하거나 너무 복잡한 경우 복잡한 쿼리를 캡슐화합니다. 올바른 뷰에 저장 프로 시저에서 훨씬 더 이해하기 쉽게 표현할 수있는 매우 복잡한 SQL이 필요한 몇 가지 사례를 보았습니다. 이것은 드물지만 발생합니다.

일반적으로 먼저 뷰를 시도하고 필요한 경우에만 절차에 의존하는 것이 좋습니다. 잘 설계된 뷰는 실제로 기본 테이블을 쿼리하는 방법에 대한 세부 정보를 추출하여 API로 작동 할 수 있습니다. 스토어드 프로 시저로 API (보기) 기능을 보강하는 것은 일부 상황에서 의미가 있습니다. 쿼리 결과에서 응용 프로그램의 데이터 모델로 데이터를 매핑하는 모든 혼란을 우회하여 SQL 쿼리에서 직접 JSON을 내보낼 수도 있습니다. 그것이 좋은 아이디어인지 아닌지는 자신의 필요에 따라 결정하는 것입니다.

자동화 된 도구를 통해 데이터베이스 리소스 (스키마, 권한 등)를 이미 관리해야하므로 저장 프로시 저는 마이크로 서비스에 본질적으로 나쁘지 않습니다.

저장 프로시 저는 구현 세부 사항입니다. 파일 시스템의 어딘가에 저장된 데이터베이스 함수, 람다 또는 쉘 스크립트는 모든 구현 세부 사항이며 아키텍처와 관련이 없습니다.

마이크로 서비스에 관한 대부분의 책은 마이크로 서비스 당 하나의 데이터베이스를 권장합니다.

이 데이터베이스에서 저장 프로 시저를 코딩 할 수 있습니다.

다시 말하지만 대부분의 마이크로 서비스 아키텍처 서적은 자율적이고 느슨하게 결합되어야한다고 주장합니다.

비즈니스 기능, 개발 수명주기, 관리, 배포, 팀 위치 등 구현 세부 사항과 관련이 없습니다. 마이크로 서비스는 기술적 문제를 해결하지 못합니다 (반대). 그들은 경영 및 시장 출시와 관련된 문제를 해결하기 위해 왔습니다. 전략이 아니라 전략입니다. 최소한의 비용으로 실패를 방지하는 방법. 특정 비즈니스 기능이 가치가없는 것으로 판명되면 다른 기능, 배포, 프로젝트 관리, 릴리스 등을 엉망으로 만들지 않으면 서 제거 할 수 있습니다.

"분할"은 이미 디커플링 에이전트처럼 작동합니다. A가 Oracle에 의해 지원되고 B가 MongoDB에 의해 지원되는 두 가지 서비스가 있다고 가정하십시오. 디커플링의 황금 규칙을 어 기지 않으면 B에 부작용이 거의없는 A + Oracle을 삭제할 수 있습니다.

Oracle에서 구체적으로 작성된 저장 프로 시저를 사용하여 마이크로 서비스를 해당 기술에 긴밀하게 연결합니다.

공급 업체가 잠길 수 있습니다. 여러 번, 공급 업체는 과거 또는 계약상의 이유로 인해 비즈니스에 의해 부과됩니다 ¹ . 공급 업체에 코드를 잠그지 않는 방법을 아는 것이 중요합니다. 예를 들어, 일부 ORM 및 프레임 워크는 데이터베이스 내장 기능 및 기능을 숨기는 새로운 쿼리 언어를 구현합니다.

비록 우리의 서비스가 충분히 미세하더라도, 공급 업체 잠금은 전체의 작은 부분에 영향을 미치기 때문에 더 이상 문제가되지 않습니다. 신속하게 교체 (또는 격리) 할 수있는 작은 부품.

읽은 대부분의 MSA 서적은 마이크로 서비스가 비즈니스 지향적 (DDD를 사용하여 설계)되어야한다고 권장합니다.

비즈니스 중심 이어야 하고 여기에있는 것이 어야합니다 . 모든 비즈니스가 DDD를 이용하는 것은 아닙니다. DDD와 마이크로 서비스는 여러 점에서 겹치지 만 원인은 아닙니다. 빈혈 서비스로 구성된 마이크로 서비스 에코 시스템을 만들 수 있습니다. 또는 복잡한 도메인을 구현하는 서비스와 DB에서 직접 POJO를 제공하는 벙어리 빈약 한 서비스로 구성됩니다. 그것에 아무런 문제가 없습니다.

책에 관해서는 전략 실행에만 집중합니다. 전술- 분산 컴퓨팅을 활용하는 방법 을 성공으로 이끄는 방법이지만 전략에 일반적으로 영향을 미치지 않습니다. 전략은 회사마다 다르며 개발자에게 거의 의존하지 않습니다. 따라서 우리는 여전히 책이 우리의 특정 요구, 요구 사항 및 제약 조건에 대해 말하는 것을 추정하고 적용해야합니다. 목표는 비즈니스 전략을 수익성 있고 지속 가능하게 만드는 것입니다.

모든 아키텍처는 끝의 수단이라는 것을 항상 명심하십시오. 비즈니스 규칙. 우리는 패션이나 예술에 대한 사랑을위한 마이크로 서비스 생태계를 구축하지 않습니다.

마이크로 서비스와는 아무런 관련이 없습니다.

서비스에 데이터 액세스 및 비즈니스 논리 계층이 맨 위에있는 DB가 서비스의 기초가되는 '구식'계층 구조가있는 경우 저장 프로 시저가 적합 할 수 있습니다. 이러한 아키텍처에서 서비스와 데이터베이스 간의 인터페이스는 서비스의 가장 안쪽 세부 사항에 매우 구체적입니다. 일반적으로 지원되는 각 종류의 데이터베이스마다 서비스 별 어댑터가 있으며 어댑터에 의해 노출 된 API의 특수성으로 인해 기본 계층에서 저장 프로 시저를 사용할 수 있습니다.

이와 같은 아키텍처에는 많은 문제가 있습니다. 가장 중요한 것은 대부분의 로직을 단위 테스트를 매우 어렵게 만듭니다. 이러한 아키텍처는 더 이상 선호되지 않습니다.

최신 스타일의 "깨끗한 아키텍처", "양파 아키텍처"또는 이와 유사한 것을 사용하는 경우 데이터베이스는 외부 계층에 지정된 주입 된 종속성 이됩니다. 외부 레이어에 정의되어 있으므로 데이터베이스에 제공된 인터페이스는 generic 이어야합니다 . 그것은 할 수없는 그 세부 사항이되어야하기 때문에, 서비스의 가장 안쪽의 세부 사항을 반영 숨겨진 아키텍처의 가장 바깥 쪽 레이어에서. 모든 데이터베이스 또는 단위 테스트 장치와 함께 사용할 수 있는 일반 저장 프로 시저 인터페이스를 정의하는 것은 매우 어렵고 실제로는 필요하지 않으므로 이러한 종류의 아키텍처에서는 저장 프로 시저가 종종 실용적이지 않습니다.

마이크로 서비스와의 관계는 마이크로 서비스가 새롭고 우월하다는 것입니다. 우리는 더 이상 모놀리스를하지 않습니다. 그리고이 새로운 건축 스타일도 상승합니다. 더 이상 평평한 레이어를하지 않습니다.