웹 응용 프로그램에 별도의 API 및 UI 서버를 사용할 경우의 이점

현재 우리는 2 년 가까이 개발 된 대형 내부 애플리케이션을 보유하고 있습니다. 방금 최근 프로젝트에 참여했으며 일부 아키텍처가 약간 당황했습니다. 그래서 건축가 에게이 같은 질문을하기 전에 나가서 조언을 해 줄 수 있기를 바랍니다. ).

아래 내용이 조금 길다면 죄송합니다. 제 질문을하기 전에 시스템의 상태를 잘 그려보고 싶습니다. :)

• 시스템 설정 방법은 주로 다양한 다른 서비스의 데이터를 집계하는 하나의 기본 웹 응용 프로그램 (asp.net, AngularJS)을 사용하는 것입니다. 기본적으로 AngularJS 응용 프로그램의 호스트입니다. 말 그대로 클라이언트 측을 부트 스트랩하는 하나의 MVC 컨트롤러가 있으며 다른 모든 컨트롤러는 WebAPI 컨트롤러입니다.

• 클라이언트 측으로부터의 호출은이 컨트롤러에 의해 처리되며, 항상 웹 응용 프로그램을 호스팅하는 상자에만 배포됩니다. 우리는 현재 그러한 상자를 4 개 가지고 있습니다.

• 그러나이 호출은 궁극적으로 또 다른 WebAPI 응용 프로그램 집합 (일반적으로 보안, 고객 데이터, 제품 데이터 등의 비즈니스 영역 별)으로 라우팅됩니다. 이러한 WebAPI는 모두 전용 박스에 함께 배포됩니다. 이 상자들 중 4 개도 있습니다.

• 단 하나의 예외로, 이러한 WebAPI는 조직의 다른 부분에서는 사용되지 않습니다.

• 마지막으로 이러한 WebAPI는 "백엔드"서비스에 대한 또 다른 호출 세트를 작성합니다.이 서비스는 일반적으로 다양한 ERP 시스템 및 데이터 저장소 (통합 할 수없는)의 상단에있는 기존 asmx 또는 wcf 서비스입니다.

• 애플리케이션의 비즈니스 로직의 대부분은 레거시 데이터 변환, 집계, 비즈니스 규칙 실행, 일반적인 유형과 같은 WebApi에 있습니다.

내가 혼란스럽게 한 것은 WebApplication과 WebAPI를 제공하는 것과 같은 분리가 있으면 가능한 이점입니다. 다른 사람이 사용하지 않기 때문에 확장 성 이점이 없습니다 (즉, API 서버의 부하가 증가하면 웹 서버의 부하가 증가해야함에 따라 부하 증가를 처리하기 위해 다른 4 개의 API 상자를 넣을 필요가 없습니다- 따라서 웹 서버 대 Api 서버의 1 : 1 비율이 있어야합니다)

• 또한 여분의 HTTP 호출 Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => 백엔드 서비스를 만들어야하는 이점이 전혀 없습니다. (WebApp과 WebAPI 간의 HTTP 호출은 내 문제입니다)

• 그래서 현재는 현재 WebAPI를 별도의 솔루션에서 WebApplication 솔루션 내에서 별도의 프로젝트 참조로 단일 프로젝트 모델과 단일 배포 모델로 이동하도록 추진하려고합니다. 그래서 그들은 궁극적으로 클래스 라이브러리가 될 것입니다.

• 배포 측면에서 이는 4 + 4가 아닌 8 개의 "풀 스택"웹 상자가 있음을 의미합니다.

새로운 접근 방식의 장점은 다음과 같습니다.

• 웹 응용 프로그램과 WebAPI 서버간에 직렬화 / 직렬화주기가 1 회 줄어들 기 때문에 성능이 향상됩니다.
• 웹 애플리케이션 및 WebApi 서버의 발신 및 수신 경계에서 각각 DTO 및 맵퍼 측면에서 삭제할 수있는 많은 코드 (즉, 유지 보수 / 테스트 불필요).
• 백엔드 서비스를 간단하게 모의하고 미드 티어 HTTP 점프 주위의 혼란을 피할 수 있기 때문에 의미있는 자동화 된 통합 테스트 생성 기능이 향상되었습니다.

그래서 질문은 : 내가 틀렸습니까? WebApplication 상자와 WebAPI 상자를 분리 한 기본적인 "마법"을 놓쳤습니까?

N-Tier 아키텍처 자료를 연구했지만 상황에 구체적인 이점을 줄 수있는 것을 찾을 수없는 것 같습니다 (확장 성이 내가 말할 수있는 한 문제가 아니기 때문에 내부 응용 프로그램이므로 WebAPI 응용 프로그램의 관점에서 보안은 문제가되지 않습니다.)

또한 시스템을 제안 된 설정으로 재구성하면 이점 측면에서 무엇을 잃을 것입니까?

한 가지 이유는 보안입니다 - (! 하하 경우 때 ) 이익 프런트 엔드 웹 서버에 액세스 해커, 그는 모든 액세스를 얻을이에 액세스 할 수 있습니다. 웹 서버에 미들 티어를 배치하면 DB에있는 모든 것에 액세스 할 수 있으며 다음으로 아는 것은 DB에서 "select * from users"를 실행하여 오프라인에서 분리 한 것입니다. 비밀번호 크래킹.

또 다른 이유는 페이지가 구성되고 엉망이되고 XML이 처리되는 웹 계층이며 중간 계층보다 훨씬 많은 리소스를 사용하는 웹 계층으로, DB에서 웹 계층으로 데이터를 가져 오는 효율적인 방법입니다. 웹 서버에 상주하거나 캐시 된 모든 정적 데이터를 전송하는 것은 말할 것도 없습니다. 웹 서버와 로직 계층 사이에 1 : 1 비율이 없어야합니다. 지금까지 8 : 1을 보았습니다 (논리 사이에 4 : 1 비율). 계층 및 DB). 그러나 계층이 수행하는 작업과 해당 계층에서 얼마나 많은 캐싱이 수행되는지에 따라 다릅니다.

웹 사이트는 단일 사용자의 성능을 확장하기 위해 구축 할 때 실제로 신경 쓰지 않습니다. 더 많은 사용자에게 서비스를 제공 할 수 있다면 약간의 호출 속도가 느려지는 것은 중요하지 않습니다.

이러한 계층을 갖추는 것이 좋은 또 다른 이유는 API를 개발하고 (독립형으로 쉽게 테스트 할 수있는) UI를 개발하기 위해 UI를 개발하는 개발에 더 많은 규율을 강요하기 때문입니다. 나는 다른 팀이 다른 계층을 개발했으며 다른 계층에 대해 걱정할 필요가 없기 때문에 변경 사항을 신속하게 파악할 수있는 각 계층의 전문가가 있었기 때문에이 작업을 수행 한 곳에서 일했습니다. 예 : UI javscript dev 다른 사람이 개발 한 새로운 웹 서비스를 이용하여 사이트에 새로운 섹션을 추가 할 수 있습니다.

나는 여기에 옳고 그름의 대답이 없다고 생각합니다. 이 아키텍처의 목적에 대해 동료들에게 물었습니까?

귀하의 설명을 이해하는 방법 에서 아키텍처 의 " WebAPI "는 일종의 자체 제작 미들웨어 역할을합니다. 이제 미들웨어 사용시 어떤 이점이 있는지 조사 할 수 있습니다. 백 오피스 시스템을 변경 한 경우 ( WebAPI 인터페이스가 동일하게 유지되는 한) 기본적으로 Webapp를 채택 할 필요가 없습니다 .

더 나아가 : 고객 데이터베이스 (백엔드 서비스)가 있고 해당 데이터베이스와 통신하는 5 개의 웹 앱이 있다고 가정하십시오. 고객 데이터베이스 시스템을 다른 공급 업체와 같이 새 시스템으로 교체하고 웹 서비스 인터페이스에 영향을 줄 수없는 경우 5 개의 웹 애플리케이션 모두의 통신 계층을 변경해야합니다. 당신이 당신을 통해 통신하는 경우 WebAPI , 당신은 단지의 통신 계층 변경해야 할 것 WebAPI를 .

기본적으로 레이어 아키텍처는 현재 패턴 및 안티 패턴으로 간주됩니다 . ( Lasagna-Code 참조 ) 향후 몇 년 동안이 시스템을 더 이상 확장 할 계획이없는 시스템이 하나 뿐인 경우에는이를 안티 패턴으로 간주합니다. 그러나 나는 정확한 상황 / 상황을 모르기 때문에 비현실적으로 태프 판사입니다. :)