마이크로서비스 아키텍처의 진화
모놀리식 모드의 응용 프로그램은 일반적으로 서로 다른 하위 모듈을 포함하는 앱 서버를 가지고 있으며, 각 하위 모듈은 동일한 응용 프로그램 패키지에 작성되며 때로는 모듈 간의 경계가 특별히 명확하게 설계되지 않은 경우가 있습니다. 특히 초기 코드가 혼합된 경우 함께, 그것은 서로를 부르는 것을 의미합니다.
이 상대적으로 무거운 모놀리식 아키텍처는 여전히 중복 배포 및 로드 밸런싱을 통해 애플리케이션의 고가용성을 보장합니다.
모놀리식 아키텍처는 더 이상 복잡한 비즈니스 요구에 적합하지 않습니다.우리는 비즈니스 아키텍처를 약간 조정하고 하위 시스템으로 하나씩 대체할 것입니다.이 하위 시스템은 독립적인 배포 파일과 독립적인 수명 주기를 가집니다. 각 하위 시스템의 고가용성에 대한 요구 사항도 다르며 하위 시스템과 하위 시스템은 네트워크 호출을 통해 전체 비즈니스를 완료합니다.
단일 인스턴스 및 단일 프로세스 모델과 같은 원래의 모놀리식 시스템은 통합된 배치 보기를 형성하는 수백 개의 하위 서비스가 될 것입니다.
이때 인간의 육체로 가서 하나씩 제어하면 비용이 매우 높고 오류 확률이 매우 높습니다. 이러한 방식으로 자동화된 방법에 의존하여 애플리케이션 구성 및 서비스 검색 기능을 완료해야 합니다.
모놀리식 시스템에서 마이크로서비스 시스템으로의 진화
온라인 상점이 있고 판매에는 물건을 판매할 수 있는 포털을 제공하는 판매 모듈이 있다고 가정합니다. 온라인 스토어에서 판매되는 상품은 반드시 보관되어야 하며, 재고를 관리하기 위한 창고관리 시스템이 있습니다. 청구 및 할인에 대한 요구도 있습니다. 단일 애플리케이션의 경우 단일 애플리케이션의 기능으로 제공됩니다.
동일한 절차이기 때문에 주소만 알려주시면 모든 서비스를 이용하실 수 있습니다.
마이크로서비스 아키텍처의 진화
모놀리식 애플리케이션을 마이크로서비스 아키텍처로 분할하기 위해 애플리케이션 프로세스의 다양한 기능이 서로 다른 하위 시스템으로 분할되고 각 하위 시스템은 자체 책임을 맡습니다.
영업은 프런트 엔드 비즈니스를 지원하므로 가용성 요구 사항이 더 높고 더 많은 동시 요청을 지원하므로 여기에서 더 많은 인스턴스를 배포하고 더 많은 동시 로드 지원을 제공한 다음 더 높은 가용성을 제공할 수 있습니다.
서비스와 서비스 간의 호출을 포함하여 각 시스템에 대해 네트워크를 열어야 합니다. 이 복잡한 결합을 해결하기 위해 api 게이트웨이를 사용할 수 있습니다. 클러스터에는 매우 많은 서비스가 있을 수 있으며 이러한 서비스는 동일한 도메인 이름을 통해 노출될 수 있으므로 다양한 고객 요청을 수락하고 게이트웨이를 통해 다른 서비스로 전달하는 API 게이트웨이가 필요합니다.
서비스 간의 호출에는 서비스 검색 메커니즘이 필요하고 서비스 레지스트리가 필요합니다.각 서비스가 가동된 후 자체 등록해야 하며 다른 갱신은 내가 살아 있다고 말할 것입니다. 그는 자신의 건강 상태를 등록해야 하며 다른 사람들이 서비스 호출을 할 때 이 서비스 뒤에 어떤 실제 서버가 실행되고 있는지 알 수 있습니다.
여기에 서비스 등록센터가 있는데, 서비스센터에 등록된 주소 정보는 점대점 방식으로 등록하면 각 노드의 헬스 상태가 실시간으로 업데이트 되어야 한다. 다른 하나는 중앙 집중식 로드 밸런싱 또는 분산 로드 밸런싱을 통해 통합 입구의 가상 IP가 바인딩됩니다.
일반적인 마이크로서비스 비즈니스 시나리오
창고와 회계 사이에는 고정된 호출 관계가 있을 수 있습니다. 현재 시스템 아키텍처는 실패를 위해 설계되었습니다. 시스템을 설계할 때 모든 구성 요소가 신뢰할 수 없다고 가정해야 합니다. 회계에는 두 가지 오류가 발생할 수 있습니다. 아마도 하나는 오류 코드가 반환될 수 있으며 다른 하나는 응답하지 않을 수 있다는 것입니다.응답이 없으면 많은 응용 프로그램이 비즈니스 코드로 작성되고 50x를 반환합니다. 애니메이션이 일시 중단되면 창고는 회계에 문제가 있음을 모르고 회계에 요청을 전달하고 응답을 기다립니다. 응용 프로그램이 제대로 작성되지 않고 충분히 견고하지 않으면 무한정 대기합니다. 그러나 회계는 정상이라고 생각할 것입니다. 회계는 오류 메시지를 반환하지 않기 때문에 판매는 계속해서 요청을 전달합니다.
그러면 창고가 많은 판매 요청을 받게 되고 반환 값을 얻기 위해 이러한 요청을 회계에 전달하는 효과적인 방법이 없으며 창고의 요청 백로그가 점점 더 많아져 창고가 또한 오작동 .
창고 출현 후 유사한 문제가 발생할 수 있으며 각 구성 요소가 영향을 받을 수 있으며 이로 인해 각 로컬 오류가 글로벌로 확장됩니다.
많은 경우 웨어하우스는 통합 기능이 필요하며, 하나는 오류 코드를 반환하고 이 오류 코드를 올바르게 처리할 수 있어야 한다는 것입니다.
또한 에러코드를 리턴하지 않는다면 적어도 동시접속이 몇 개나 나갔는지 알아야 위의 동시접속을 제한해야 하며, 동시접속이 많을 경우 융합 및 서비스 저하를 해야 하며, 많은 요청을 보냈지만 응답을 받지 못했다고 영업팀에 알립니다. 그러면 지금 더 많은 요청을 처리할 방법이 없습니다.
마이크로 서비스 아키텍처 시스템이므로 각 서비스는 이를 서비스 레지스트리에 등록해야 하며 각 서비스의 하향 호출에는 로드 밸런싱 기능이 필요합니다.
HTTP 서비스가 제공되는 경우 확인이 수행되지 않습니다. 그러면 이 서비스는 많은 악의적이거나 비악의적인 요청의 영향을 받게 되므로 요청의 유효성, 빈도 등을 제어할 수 없습니다.
서비스가 삭제 기능을 제공하고 확인 및 인증이 수행되지 않으면 이 보호는 의문의 여지가 없습니다.
전체 기업은 인증 및 인증을 위한 일련의 중앙 서비스를 갖게 됩니다. 모든 응용 프로그램은 이 서비스에 연결됩니다. 서비스 간 호출은 신뢰할 수 있는 권한을 기반으로 해야 합니다. 귀하가 누구인지 알고 싶습니다. 이 권한이 있어야 합니다. 저를 부를 수 있습니다. 일반적으로 여기에는 인증 서버가 있습니다.
각 서비스는 자격 증명을 인증하는 기능을 얻기 위해 인증 서버와 통신합니다.
보다 완벽한 서비스 아키텍처
클라이언트는 요청을 시작하고 서버는 이러한 요청에 응답하며 서버에는 비즈니스 논리와 플랫폼 기능이 있습니다.
그런 다음 완전한 마이크로서비스 프레임워크는 비즈니스 기능과 플랫폼 기능을 전체적으로 통합합니다.
시스템 경계
플랫폼 기능과 비즈니스 기능을 분류하는 방법.
비즈니스 로직이란 무엇입니까? 판매 창고 회계 할인이 있습니다. 이것은 실제로 비즈니스 관련 논리 코드입니다.
이들은 사업입니다.
나머지는 인증, 회로 차단, 로드 밸런싱 및 프로토콜과 관련이 있으며 비즈니스와 관련이 없습니다. 이들은 플랫폼 측면에서 더 많은 기능입니다. 그것은 비즈니스와 비즈니스 간의 호출이며, 어떤 합의와 어떤 종류의 호소에 따라 플랫폼 측에서 모두 통합됩니다.
이러한 종류의 아키텍처는 일반적으로 두 가지 유형으로 나뉩니다. 하나는 Java 프로그래머에게 친숙한 스프링 클라우드이고, 이 프로젝트는 Netflix 회사의 일부 오픈 소스 소프트웨어인 netfix를 통합합니다. 이러한 오픈 소스 소프트웨어에는 클라이언트 로드 밸런싱을 위한 서비스 레지스트리 또는 리본과 같은 eurka가 포함됩니다.
이들은 많은 오픈 소스 라이브러리를 비즈니스 코드에 포함합니다 비즈니스 코드가 플랫폼 측 기능에 사용되는 경우 비즈니스 코드와 플랫폼 기능이 긴밀하게 통합되어야 합니다. 둘째, 변경을 원할 경우 실제로 배포된 패키지를 이동해야 합니다.예를 들어 서비스 검색 기능 또는 로드 밸런싱 기능의 버전을 업그레이드하려면 전체 war 패키지를 업그레이드해야 합니다.
이러한 방식으로 비즈니스 측면과 플랫폼은 긴밀하게 연결된 관계가 됩니다.
따라서 비즈니스가 비즈니스에 속하고 플랫폼이 플랫폼에 속하도록 만드는 더 우아하고 합리적인 방법이 있습니다. 비즈니스가 직면한 기본 플랫폼 측면의 요구 사항을 단순화할 수 있습니까?
인증하고 서비스를 검색합니다. 이러한 융합의 기능은 플랫폼 측에 던져지므로 비즈니스 측은 실제로 비즈니스에만 관심이 있습니다. 이 모드는 서비스 그리드에서 권장하는 기능으로 istio에서 추구한 결과입니다.
