마이크로 및 모 놀리 식 서버 아키텍처

우리는 현재 새로운 제품 / 프로젝트를 진행하고 있으며 특정 산업 / 서비스 기업을 대상으로하는 클라이언트-서버 애플리케이션입니다. 우리는 Java 프론트 엔드를 사용하여 TCP 위에서 사용자 정의 프로토콜을 실행하는 서버 (C 언어 및 Linux 전용)를 구축하고 있습니다. 우리는 약 20 %의 코딩 작업을 수행하고 있으며 Micro 또는 Monolithic Kernel Architecture 중 하나를 선택해야하는 상황에 직면 해 있습니다.

Micro vs. Monolithic은 일반적으로 커널 아키텍처와 관련이 있지만 서버에 대해 구체적으로 이야기하고 있습니다.

왜 기존 서버가 아닌 사용자 정의 서버입니까?

• 우리의 UI 요구는 중요하고 매우 역동적이므로 웹 / 웹 브라우저 기반 솔루션은 적합하지 않습니다.
• 통계 처리는 클라이언트 측에서 중요하므로 브라우저는 거의 도움이되지 않았습니다. (물론, 우리는 서버 측에서 처리를 수행하고 처리 된 데이터를 클라이언트에 전달할 수 있지만 서버에 많은로드가 발생하고 클라이언트 리소스가 낭비 될 수 있습니다).
• 또한, 단일 이벤트로도 관리 할 수있는 최소한 3 가지 기술 (JS / HTML / CSS)을 사용하면 사막 폭풍 속에서 집을 쓸어 버리는 것과 같은 전체 경험을 할 수 있습니다. n 번 청소하면 먼지가 n + 1 배가됩니다.

마이크로 및 모 놀리 식 서버는 어떻습니까? 당신은 무엇을 이야기?

다음과 같은 (가설적인) 클라이언트 요청을 고려하십시오.

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

이러한 요청을 받으면 서버는 일반적으로 수행합니다 (단순화를 위해 스레드 및 포크와 같은 동시성 기술은 무시합니다).

• 요청 문자열 구문 분석
• 조치를 식별하십시오 (이 HistoricDataSets LIMIT Year (2010)경우 가져 오기 ).
• 지속성 계층 (Oracle, 예를 들어 설명하자)과 상호 작용하고 데이터를 가져옵니다.

• 프로토콜에 따라 데이터를 포맷하십시오. 전의:

  응답 ID : 123
  성공 : 실제
  응답 텍스트 : DataSet

• 이렇게 형식이 지정된 데이터를 사용하여 클라이언트에 응답하십시오.

이것이 우리가 모 놀리 식 서버 (모두 OS 작업이 커널 공간에서 수행되는 모 놀리 식 커널 이라고 함)라고 부르는 것입니다.

이번에 서버가 수신되면 동일한 요청을 다시 고려하십시오 (우리는 단순성을 위해 공유 메모리 만 IPC로 가정했습니다).

• Parser프로세스 의 공유 메모리에 요청을 넣습니다.
• 는 Parser작업을 식별 문자열을 구문 분석하고 지시 Executioner작업을 실행하는 과정을.
• 그런 Executioner다음 Fomatter데이터를 프로토콜 문자열로 형식화 한 후 서버로 리턴하는 처리 할 데이터를 전달 합니다.
• 서버는이를 클라이언트에 발송합니다 (응답).

물론, 대신에 Parser, Executioner그리고 Formatter그것은 하나의 그러나 별도의 프로세스 수 있었다. 이것이 우리가 마이크로 서버 라고 부르는 것입니다 (최소한 최소한의 마이크로 커널이 필요합니다). 서버는 효과적으로 듣고 응답하는 반면 모든 단계는 다른 프로세스에 의해 처리됩니다.

어느 것을 고를까요? 우리는 혼란스러워합니다! 모 놀리 식 서버는 (대부분의 HTTP- 웹 서버?) 시도되고 테스트되었지만 프로그래밍하기 쉽고 동시성을 매우 잘 처리 할 수 ​​있습니다. 초소형 서버 인 마이크로 서버는 하나의 작업을 수행하는 하나의 프로그램의 UNIX 원칙과 신속하고 일치하는 것처럼 보이지만 esp 개발도 복잡합니다. 동시성을 염두에 두십시오.

질문
-각 접근법의 장단점은 무엇입니까?
-언제 사용합니까? (또한 일반적인 질문으로 해석 될 수 있습니다 : IPC 사용시기?)
-마이크로 커널을 선택하면 어떤 기능이 코어 서버의 일부가되어야합니까?

유사 / 관련 질문

• 거대한 모 놀리 식 응용의 위험
• 외부 대 임베디드 브라우저 (접선)
• 모 놀리 식 앱을 멀티 스레드 (Tangential) 로 변환하기위한 조언

• 우리의 잠재 고객은 두 가지 범주로 나눌 수 있습니다.
  • 대규모 : 분당 약 1,700-2,000 건의 요청
  • 작음 : 분당 약 650-700 건의 요청
• 요청주기 당 데이터 볼륨 (요청 및 후속 응답)은 평균 ~ 1.20MB, 더 나쁜 경우는 약 250-300MB로 분배되는 것으로 가정 할 수 있습니다.
• 제품 개념은 비교적 새롭지 만 핵심 운영에 영향을 줄 수있는 기능을 갖추고 있으므로 배포 후 특정 지연 (9-12 개월) 후에 만 ​​고객 예산이 유연해질 것으로 예상됩니다. esp. 작은 것들.
• 각 고객은 자신의 클라이언트-서버 스택을 갖게됩니다. 서버는 고객 팀이 관리하는 고객의 하드웨어에서 실행되고 클라이언트는 기능 직원의 컴퓨터에 배포됩니다.
• 클라이언트 및 서버 응용 프로그램 모두에 대한 원격 업데이트는 필수입니다
• PUSH제품이 클릭하는 경우 서버의 실시간 서비스가 '높을'원할 수 있습니다!

경제학은 때때로 선택의 핵심 이론보다 훨씬 더 중요한 답변을 지배합니다. 가장 중요한 것은 애플리케이션이 진정으로 힘든 배치를 필요로하는 경우에 '광범위한'것을보고 있다면 스스로 개발 한 휠의 수가 적을수록 더 좋습니다. 그것이 작동한다면, 그것이 모 놀리 식인지 마이크로인지 상관하지 않습니다. 상관 없으면 나도 신경 ​​쓰지 않을 것입니다!

매우 일반적인 웹 페이지 기반 앱은 당신에게 적합하지 않을 수도 있습니다. 보다 나은. 그렇게하면 첫 번째 시간을 절약 할 수있을뿐만 아니라 실제 생활에서 실제로 중요한 문제에 대한 이해도를 높일 수 있습니다. 다음은 고려해야 할 몇 가지 사항입니다.

1. 확장 성이 매우 필요한 경우 서버가 가능한 빨리 이탈하는 대신 작업을 어떻게 분할 할 것인지 고려하십시오. 결국 인텔은 지구상에서 가장 빠른 프로세서를 만들고 고객이 지불 할 준비가되어 있어도 한 대의 서버가 실제로 처리 할 수없는로드를 갖게됩니다! 따라서 요청 라우팅 및로드 밸런싱은 프로토콜 자체의 효율성보다 중요합니다.

2. 확장이 필요한 경우에도 여전히 HTTP가 가장 좋습니다. 로드 밸런서를 사용하면 쉽게 구입할 수 있습니다. 맞춤형 프로토콜에는 맞춤형 배치가 필요합니다.

3. HTTP는 HTML, Java 스크립트를 전혀 포기할 필요가 없다는 것을 의미합니다. 규칙적인 아파치 서버와 웹 브라우저가 필요하다는 의미는 아닙니다. 통신이 큰 데이터 전송이 아닌 경우 라이브러리로 사용할 수있는 AOL 서버 또는 lighthttpd 와 같은 두 사용자 정의 클라이언트와 요소간에 HTTP를 사용할 수 있습니다. gSOAP 와 같은 툴킷으로 양쪽에서 SOAP를 사용할 수도 있습니다 .

4. HTTP가 청구서에 맞지 않더라도 BEEP 와 같은 것을 고려 하면 더 효율적으로 작업 할 수 있습니다. 또는 입증 된 RPC, RMI 메커니즘이 많이 있습니다.

5. 백엔드에서 병렬 처리를 수행하여 최대한의 작업을 더 많이 수행 할 수 있으며 작업이 완료 될 때만 서버가 조회됩니다. 이것이 효과가 있다면 MPI 와 같은 프레임 워크가 있거나 도움이 될 수있는 다른 분산 컴퓨팅 도구 키트가 많이 있습니다.

6. 마지막으로, 정확한 요구 사항을 알 수있는 위치에 있지는 않지만 둘 다 필요한 경우 많은 데이터를 배포하거나 많은 계산을 수행해야 할 수도 있습니다. 아직 핵심 아키텍처 비 효율성이 있습니다.

나에게 새 프로토콜을 만들고 새 서버 프레임 워크를 만드는 것은 함께하지 말아야 할 이중 실험입니다. 스테이크가 너무 높으면 먼저 기존 도구를 실험하여 지금까지 수행 된 작업의 한계를 확인해야합니다. 그래야만 실제 문제를 알 수 있습니다.

분산 시스템 연구에서 웹 응용 프로그램보다 훨씬 더 많은 것들이 이루어졌습니다. 그래서 당신은 그것을 연구해야합니다.

디판

이것은 나에게 매우 학문적 인 것 같습니다. 그리고 솔직히 말해서, 두 번째 접근 방식은 모 놀리 식과 같습니다. 이것은 당신이 가야 할 한 :

1. 요청 파싱
2. 요청 처리

요청 매개 변수를 기반으로 선택한 요청 핸들러는 요청 처리의 모든 측면을 캡슐화해야합니다. 처리기가 실제로 데이터 저장소에서 쿼리를 수행하는지 여부와 표준 형식을 사용하여 데이터를 반환하는지 여부는 위 계층과 관련이 없습니다. 사실, 그것은 아마도 그렇게 할 것이지만 그것에 대해 가정하는 데는 가치가 없습니다.

1. 모 놀리 식 커널은 마이크로 커널보다 훨씬 오래되었습니다 . 유닉스에서 사용됩니다. 마이크로 커널의 아이디어는 1980 년대 말에 나타났습니다 .

2. 모 놀리 식 커널을 갖는 os의 예는 UNIX, LINUX 이고, 마이크로 커널을 가진 os는 QNX, L4, HURD 이며, 처음에는 Mach (mac os x 아님) 후에 하이브리드 커널로 변환됩니다. 심지어 MINIX 도 순수한 커널이 아닙니다. 커널의 일부로 컴파일됩니다.

3. 단일 커널은 마이크로 커널보다 빠릅니다 . 첫 번째 마이크로 커널 Mach는 모 놀리 식 커널보다 50 % 느리지 만 L4와 같은 최신 버전 은 모 놀리 식 커널보다 2 % 또는 4 % 느립니다 .

4. 모 놀리 식 커널은 일반적으로 부피 가 크다 . 순수한 모 놀리 식 커널은 프로세서 1 급 캐시 (1 세대 마이크로 커널)에 맞게 크기 가 작아야 합니다.

5. Monolithic 커널 장치 드라이버는 커널 공간에 상주합니다 . Microkernel 장치 드라이버는 사용자 공간에 있습니다.

6. 장치 드라이버는 커널 공간에 상주하므로 단일 커널 은 마이크로 커널 보다 덜 안전 합니다. (드라이버 실패는 충돌로 이어질 수 있음) 마이크로 커널은 일부 군사 장치에 사용되는 모 놀리 식 커널 보다 안전 합니다.

7. 단일 커널은 신호와 소켓 을 사용하여 IPC를 보장하는 반면 마이크로 커널 방식은 메시지 대기열을 사용 합니다 . 1 세대의 마이크로 커널은 IPC를 제대로 구현하지 않아 컨텍스트 전환 속도가 느 렸습니다.

8. 모 놀리 식 시스템에 새 기능을 추가한다는 것은 전체 커널 을 다시 컴파일하는 것을 의미하지만 다시 컴파일 하지 않고도 새 기능이나 패치 를 추가 할 수 있습니다 .