웹 애플리케이션 디자인에서 Unix 철학이 폐기되었습니까? [폐쇄]

웹 애플리케이션 디자인에서 Unix 철학이 폐기되었습니까? [폐쇄]

Unix 철학은 공유 메모리 공간 및 링크보다는 파이프, fifo, 소켓 등과 같은 프로세스 간 통신 형태와 협력하는 작고 일반적으로 재사용 가능한 협력 프로그램의 사용을 권장합니다. MH 및 uzbl 프로그램은 디자인에 Unix 철학을 구현하는 응용 프로그램의 예로 자주 인용됩니다.

그렇다면 웹 애플리케이션 설계에서 유닉스 철학은 완전히 포기된 것이 아닌가? 요청을 처리하는 거의 모든 웹 애플리케이션은 이제 하나의 리소스뿐만 아니라 전체 도메인의 모든 리소스에 대한 전체 요청/응답 주기(외부 데이터베이스 프로그램에 대한 호출 제외)를 처리하는 단일의 대규모 장기 실행 프로세스로 구축되었습니다.

이는 주로 웹 요청에 대한 동적 응답을 구축하기 위해 외부 프로그램 모음에 파이핑하면 과도한 프로세스 시작 시간 오버헤드가 발생하기 때문입니까? 출력을 Ruby 또는 Python 스크립트로 파이프하려는 경우 상황을 이해할 수 있지만 컴파일되는 Haskell과 같은 언어를 사용하면 웹 애플리케이션을 구축할 때 Unix 철학을 따르는 데 대한 실제 장벽이 사라질 수 있습니까?

답변1

내 생각에는 애플리케이션 사이에 선을 긋는 위치(예: 애플리케이션에 대한 정의)와 염두에 두고 있는 사용 사례에 따라 많이 달라집니다.

wget/ 의 병합으로 웹 브라우저를 구현할 수 있지만 curlHTML/XML 파서는 각 문서 노드에 대해 간단한 애플리케이션을 호출하고 독립형 JavaScript 엔진은 모든 노드와 상호 작용하며 "간단한" 디스플레이는 "그냥" 위의 내용을 화면에 출력하고(입력을 일부 핵심 조정 프로세스로 반환) 오늘날의 다른 브라우저보다 (아마도) 더 혼란스러울 것입니다.

데이터를 외부 프로세스로 파이핑하는 경우 - 실제로는 그게 다입니다.여기 간다. 평균 웹 애플리케이션 코드의 크기가 걱정된다면 그렇습니다. 크기가 큰 경우가 많습니다(대개 "간단한" 애플리케이션이 아니라 해석된 프로그래밍 언어로 작성된 플랫폼 위에 있는 레이어이기 때문입니다). 그러나 동등한 수준으로 비교합니다. 이메일 클라이언트, 오피스 스위트 등 원하는 대로 지정하세요. 이 모든 것은 매우 복잡하고 파이프를 통해 통신하는 여러 프로세스로 구현하기에는 기능이 너무 많습니다. 이러한 응용 프로그램을 사용하여 수행하는 작업도 복잡한 경우가 많습니다. 복잡한 문제에 대한 간단하고 좋은 해결책은 없습니다.

이제 UNIX 모토인 "적은 일을 하지만 잘하는 응용 프로그램" 뒤에 숨은 동기를 살펴봐야 할 때입니다. "애플리케이션"을 "범용 모듈러 유닛"으로 바꾸면 기본적이고 좋은 프로그래밍 방법 중 하나를 얻을 수 있습니다.부품을 개별적으로 재사용하고 개발할 수 있도록 모듈식으로 작업 수행. IMHO, 그것이 정말로 중요한 것입니다(프로그래밍 언어의 선택은 그것과 아무 관련이 없습니다).

메모 (댓글 이후): 가장 엄격한 의미에서 대부분 당신의 말이 맞습니다. 웹 응용 프로그램은 UNIX 철학을 따르지 않습니다(여러 개의 작은 독립 프로그램으로 분할됨). 그러나 앱의 전체 개념은 다소 모호해 보이며 sed어떤 측면에서는 앱으로 간주될 수도 있습니다.상태, 일반적으로 필터 역할만 합니다.

따라서 문자 그대로 얼마나 받아들이고 싶은지에 따라 다릅니다. 프로세스의 일반적인 정의(커널이 인식한다는 의미에서) 단일 프로세스로 실행되는 프로세스를 사용하는 경우, 예를 들어 httpd 모듈에 의해 해석되는 PHP 웹 애플리케이션은 완전히 반대입니다. 로드된 공유 라이브러리는 여전히 단일 프로세스의 범위에 속합니까(동일한 주소 공간을 사용하기 때문에), 아니면 더 독립적이 되었습니까(프로그래머의 관점에서 불변, 완전히 재사용 가능 및 잘 정의된 API 통신을 통해)?

반면, 오늘날 대부분의 웹 애플리케이션은 클라이언트와 서버 부분으로 나누어져 별도의 프로세스로 실행되며 종종 서로 다른 시스템(또는 물리적으로 별도의 하드웨어)에서 실행됩니다. 두 부분은 잘 정의된(일반적으로 텍스트) 인터페이스(HTTP를 통한 XML/HTML/JSON)를 통해 서로 통신합니다. 일반적으로 (적어도 브라우저에서는) 여러 가지가 있습니다.애플리케이션(JavaScript/DOM, 입력/출력...)에서 작업하는 클라이언트이며 때로는 플러그인(Java, Flash...)을 실행하는 별도의 프로세스이기도 합니다. 이는 특히 Linux에서 원래 UNIX 철학과 똑같습니다.프로세스(거의) 모든 계정을 통해.

그 외에도 서버 부분은 거의 항상 여러 부분으로 나뉩니다. 전형적인 예는 구조화된(또는 구조화되지 않은) 데이터에 대해 요청된 작업을 수행하는 별도의 데이터베이스 엔진입니다. 데이터베이스를 웹 서버에 통합하는 것은 그다지 의미가 없습니다. 그러나 데이터베이스를 요청 구문 분석, 데이터 저장소에서 데이터 가져오기, 데이터 필터링 등을 전담하는 여러 프로세스로 분할하는 것은 별 의미가 없습니다. 모든 작업을 수행할 수 있는 거대 기업과 거의 0에 가까운 그룹을 만들어야 합니다. 직장인들은 대부분의 시간을 서로 이야기하며 보낸다.

에 관해서는텍스트인터페이스: 40년 전에 처리된 데이터에 대한 사실이 오늘날 반드시 사실인 것은 아닙니다. 바이너리 형식은 역직렬화에 필요한 공간 및 전력 소비 측면에서 더 저렴하고 데이터 볼륨이 훨씬 더 큽니다.

또 다른 중요한 질문은 UNIX 철학의 실제 목표가 무엇인가입니다. 저는 수치 시뮬레이션, 은행 시스템, 공개적으로 접근 가능한 사진 갤러리/소셜 네트워크가 없었다고 생각합니다.시스템 유지 관리그러나 이러한 서비스를 실행해 온 것은 확실하며 앞으로도 그럴 가능성이 높습니다.

답변2

Unix 철학이 웹 애플리케이션 디자인에 존재했는지는 확실하지 않습니다. 그러나 많은 웹 애플리케이션이 실제로 설명대로 작동할 수 있지만 오늘날의 웹 애플리케이션은 데이터 소비자가 될 가능성이 더 높다고 가정할 수도 있습니다(점점 API/웹을 고려하십시오). 웹 소비를 위한 데이터를 생성하는 서비스 기반 방법).
이는 결국 서로 협력하는 작고 재사용 가능한 구성 요소(JavaScript 함수 형식)의 사용을 장려하는 것으로 볼 수 있으므로 작은 병렬 처리가 가능합니다.

관련 정보