마이크로 서비스 거버넌스 대 SOA

Question

저는 지난 10 년 동안 SOA 프로젝트에 참여했으며 이제는 마이크로 서비스 아키텍처로 전환했습니다.

SOA에서 좋은 점은 실제로 어떤 노력으로 구축되었지만 결국 모든 시스템이 동일한 '언어'로 끝나고 통신이 서비스 버스를 통해 중앙 집중화된다는 것이 었습니다. Microservice 아키텍처 팀에서

는 독립적이며이 어떠한 서비스 버스는 모든 intergration 포인트가 어떻게 작동하는지 궁금합니다.

1) SOAP을위한 SOA (에서 WSDL)는이 같은 일부 계약을 enfore하는 방법이 있나요?

2) 팀 개발 서비스 B가 자율하고 새로운 서비스를 배포하는 경우 이전 버전도 그대로 유지해야합니다. SOA에서이 문제는 서비스 버스에서 우리가 v1을 유지하고 우리가 v2 로의 변환을 수행했음을 해결했습니다. 서비스 B가 새로운 버전을 가지고 있다는 것은 소비자들에게는 사소한 것이 었습니다.

3) 팀이 가능한 한 자율적 ('민첩')해야한다는 것을 알고있는 것처럼 아래 그림과 같이 마이크로 서비스가 상당히 많을 때 어떤 유형의 의사 결정을 할 수 있습니까?

나는 최고의 해결책을 찾지 못했지만 여기에는 다른 해결책이 없기 때문에 다른 의견에 관심이 있습니다.

감사합니다.

Answer 1

우리는 또한 비슷한 변화를 겪고있다.

계약을 시행하는지 여부는 서비스 버스를 통해 또는 직접 연결하는 경우와는 별개입니다. SOAP 및 WSDL을 사용하도록 마이크로 서비스를 구축 할 수 있습니다. 업계 전체가이 문제에서 멀어지고있는 것처럼 보입니다. 우리는 REST를 사용하고 있습니다.

microservice를 배포하는 팀은 고객과 같은 모든 외부 당사자를 처리해야합니다. 즉, 변경이 발생하면 이전 버전과의 호환성을 유지하고 다른 팀에서 변경 관리 프로세스를 거쳐 이전 버전을 폐기하기 전에 업그레이드해야합니다. 가능한 한 변경 내용을 깨는 것을 피하고 그렇지 않으면 의미 론적 버전 지정을 사용합니다. 자동화 된 테스트는 모든 것을 가능하게합니다.

, 나는 주변에 지상 규칙을 설정합니다 거버넌스의 관점에서

다음 주요 변경을 고려하고,이 버전 관리 시스템에서 처리되는 방법 (그리고되지 않습니다) 어떤

같은 TLS 인증 메커니즘으로
• 는 고객이 얼마나 자신을 인증하는 방법/서비스에 대한 문서 게시 및 업데이트 될 위치를
• 보안 권장 사항

모든 서비스를 다루는 표준 데이터 모델이 없을 수도 있지만 도메인에 적합한 좀 더 작은 규칙을 소개하는 것이 좋습니다.내 도메인에서 이것은 항상 통화량과 함께 3 자의 ISO 표준 통화 코드를 사용한다는 것을 의미합니다. 우리는 통화를 가정하지 않거나 다른 표현을 사용하지 않습니다.

Answer 2

필자는 비슷한 전환기에 참가하여 길을 따라 많은 실수를 저질렀습니다. 저는 여기에 중앙 관리기구로 할 것이 몇 가지 있습니다 :

1.

내가 큰 실수는 단지 오래된 SOAP 서비스가 자신의 일이 될시키는 생각

최초의 건축 독립을 만듭니다. 그것은 작동하지 않습니다. 두 번째 실수는 Microservices를 Data CRUD 서비스 (제품, 고객 등)로 보내는 것입니다. 그것도 작동하지 않습니다.

이러한 것들은 단지 많은 동기식 상호 의존성과 많은 문제를 일으킬 것입니다!

상호 의존성을 최소화하는 아키텍처에 투자 할 것입니다. 가능한 한 동기식 통신의 필요성을 줄입니다. MQ를 사용한다는 의미는 아니지만 마이크로 서비스의 주요 기능은 다른 서비스와 함께 작동해야합니다.

이전 SOAP 서비스 라인을 따르지 않는 전혀 새로운 유형의 분해가 필요합니다. 따라서이 작업은 어렵지만 나중에는 (기하 급수적 인) 문제를 피할 수 있습니다. Self-Contained Systems을 확인하십시오.

프로토콜 지배

2. 당신이 편안하고 HTTP로 전환하는 경우 특히, 나는 규칙을 설정합니다 (그래서 모든 응용 프로그램이 균일하게 크롤링 할 수 있습니다) 형식 표준

을 연결

• 모범 사례 링크 (모든 리소스 은이 링크를 통해 접근 가능해야하며 URL은 하드 코딩되지 않아야합니다.)
• D ocumentation 표준 (Media-Types를 문서화하는 방법)
• 버전 미디어 유형
• 그리고 중요한 것은, 비 호환 변경 후 오래된 버전을 표시하는 자동 방법. 그리고 표준 유예 기간이 지나면 이들이 제거됩니다 (살아 있어야하는 시간). 일정 간격 또는 릴리스 수 중 하나를 사용하십시오.

이러한 방법 중 하나를 수행 할 방법이 없으므로 이러한 모든 방법을 찾아 내야합니다.

나는 Swagger와 같은 특정 제품을 요구하지 않고 팀과 함께 이러한 결정을 내릴 수 있습니다.

JSON-RPC를 찾고 REST가 아닌 경우 위의 사항 중 일부는 귀하와 관련이 없을 수 있습니다.

3. 인프라와 같은 것들

인증 및 권한 부여에 대한 통일 된 표준을 만듭니다. 다시 말하자면, 제품을 가능한 한 제품에 독립적으로 만들고 동기식 통신을 필요로하지 않습니다.

예를 들어 Json Tokens을 사용하도록 정의하십시오. 이러한 것들은 아무에게도 통신하지 않고 "오프라인"으로 사용할 수 있으며 인증에 도움이되는 사용자에 대한 단언을 포함 할 수 있습니다.

특정 메시지의 통신 ​​암호화와 같은 보안 제한 조건도 정의하십시오. 다시 말하지만, 나는 단지 "어떻게"가 아닌 "무엇"을 요구할뿐입니다.

4. 아마도 건축 감독 팀을 만들 것

연속 감독. 적절한 아키텍처를 만드는 것은 어렵습니다. 프로젝트가 때때로 요구하는 빠르고 더러운 솔루션을 위해 떨어지지 않고 변경하기가 더 어렵습니다. 부적절한 종속성과 숨겨진 문제를 만듭니다.

이 사람들은 손에 도메인 전문가 및 건축가하고 궁극적으로 전체 풍경의 기능에 대한 책임해야 할 필요가있다.

글쎄, 그건