많은 사람들이 프로그래밍 패러다임, 프로그래밍 아키텍처, 프로그래밍 소스 코드 프레임워크, 미들웨어, R&D 도구 파이프라인의 차이점을 구분하지 못하므로 이에 대해 다시 이야기하겠습니다.
(1) 프로그래밍 패러다임
1. 기능
프로그래밍은 큰 흐름 카드로 시작됩니다.
함수를 만드세요:
하나는 재사용용으로 큰 플로우카드를 다시 입력하지 않고 (그때 펀치카드가 너무 번거로웠어요)
두 번째는 프로그램을 명확하고 읽기 쉽게 만드는 것입니다. 이는 프로그래머가 유지 관리하기 편리합니다.
둘, 객체
자신에게 표시되고 하위 클래스에 표시되며 모든 사람에게 표시됩니다. 프로그램을 명확하고 읽기 쉽게 만들고, 나쁜 프로그래머가 코드를 오용하는 것을 방지하기 위한 것입니다.
3. 구성품
메서드, 속성 및 이벤트는 보다 풍부한 프로그래밍 표현을 위한 구성 요소입니다.
(2) 프로그래밍 패러다임
이전 학교의 프로그래밍 패러다임은 지속적으로 커지고 있으며, 아래에서 이야기할 학교의 프로그래밍 패러다임은 지속적으로 작고 작으므로 원래의 원점으로 돌아가는 것이 좋습니다.
1. 인터페이스
기능 정의와 구현의 분리는 매우 초기 단계입니다.
그런데 이종 프로그래밍 언어로 개발된 코드 간 호출을 하려면 어떻게 해야 할까요?
인터페이스 정의 표준과 데이터 유형 표준이 필요하며, 모두가 이를 준수해야 서로 호출할 수 있습니다. 이것이 IDL이 하는 일입니다.
2. 웹서비스 기술 표준
과거에는 이 기계의 다양한 소프트웨어가 서로 호출하기를 원했으며 일반적으로 공유 메모리 기술/DDE 동적 데이터 교환 기술, DLL 공유 개체 코드/DLL 인터페이스 사양 준수 및 IPC 인터페이스 호출 기술을 채택했습니다. 나중에 두 시스템의 다양한 소프트웨어가 서로 호출하여 RPC 호출 기술이 탄생했습니다.
나중에 인터넷 기술과 RPC 아이디어의 도움으로 W3C 조직은 HTML/XML/JSON, HTTP, WSDL, UDDI, SOAP와 같은 웹 서비스 기술 표준을 만들었습니다.
3. 서비스
1. SOA-SCA 서비스: IBM이 WS 표준을 사용하여 정의한 서비스 및 구성 요소의 과도기적 제품입니다. SCA-SDO와 같은.
2. 마이크로서비스: 이것은 일반적인 클래스이며 구성 요소에 대한 아이디어는 더 이상 필요하지 않습니다. 심지어 WS도 더 이상 필요하지 않고 JSON, HTTP 및 Restful만 필요합니다.
3. 더 적은 수의 서비스를 갖춘 서버리스: 기능 수준으로 세분화가 더욱 작고, 기능 수준이기 때문에 소스 코드 프레임워크도 사용되지 않습니다.
(3) 건축 아이디어와 방법
많은 건축 아이디어와 방법이 있으며, 일반적인 것들은 다음과 같습니다:
고객 소비-서비스 생산 모드: C/S와 같은 아이디어입니다.
RPC/CORBA와 같은 요청 에이전트 모드가 아이디어입니다.
메시지 전송, 메시지 구독 미들웨어 등 메시지 버스 모드가 아이디어
게다가:
마스터-슬레이브 클러스터 아키텍처: 성능 분배를 촉진하고 단일 장애 지점을 방지합니다.
P2P 균등 클러스터 아키텍처: 성능 분배에 편리하며 단일 지점 장애도 방지할 수 있습니다.
읽기-쓰기 분리 아키텍처: 편리한 성능 오프로딩
데이터와 애플리케이션 아키텍처의 분리: 편리한 성능 분배
스토리지-컴퓨팅 분리 아키텍처: 편리한 성능 분배
게다가:
MVC 아키텍처 패턴: 모델-뷰-컨트롤러(코드가 분리되고 연결됨)
MVVM 아키텍처 패턴: 모델 뷰가 분리 및 관련 데이터 동기화를 수행하는 것이 편리하므로 코드가 분리되고 연관됩니다.
ORM 아키텍처 모드: 모델-관계형 데이터베이스 매핑에 편리하므로 코드가 분리되고 연결됩니다.
게다가:
AOP 아키텍처 모드: 기존 코드가 비침습적이어서 편리하지만 새로운 기능을 추가하여 코드를 분리하고 연관시킬 수 있습니다.
IOC 아키텍처 모드: 편리한 코드 분리이지만 연결됨
(4) 프로그래밍 소스 코드 클래스 라이브러리 프레임워크
예를 들어 SSH는 MVC 아키텍처 방식의 오픈 소스 코드 프로그래밍 프레임워크로, MVC 아키텍처 방식으로 코드를 작성하는 데 편리합니다.
나중에 Spring 오픈 소스 코드 프로그래밍 프레임워크가 세계를 지배했고 Spring MVC가 등장했습니다.
마이크로서비스 시대에 사람들은 Spring 프로그래밍 프레임워크를 사용하고 싶어하지만 Spring MVC 아키텍처 방법과 프로그래밍 프레임워크를 사용하고 싶지 않아 Spring Boot가 등장합니다.
소수의 서비스가 존재하는 서버리스 시대에 신속하게 서비스를 생성-빠르게 제공-빠르게 파괴하기 위해 번거로운 미들웨어와 다양한 프로그래밍 언어 가상 머신, Spring Native에 의존하는 등 너무 많은 종속성을 원하지 않습니다. GraalVM 컴파일 기술로 등장했습니다.
(5) 미들웨어
최초의 미들웨어는 세 가지 고전으로, 모두 분산 시스템의 문제를 해결합니다.
분산 원격 호출 미들웨어: Microsoft WCF, IBM WebSphere ESB 등. 예전에는 그냥 호출이 가능한 단순한 RPC 호출 기술에 등록검색센터-구성센터-라우팅 등 거버넌스와 로드밸런싱-퓨즈 등 품질보증 기능을 추가했다.
분산 메시지 전송 미들웨어: Microsoft MQ, IBM MQ 등
분산 트랜잭션 관리 미들웨어: BEA Tuxedo, Microsoft MTS 등
나중에 웹 시대가 도래하면서 당시에는 새로운 프로그래밍 패러다임도 인기를 끌었습니다. 즉, 컴포넌트라는 세 가지 새로운 미들웨어가 등장했습니다.
웹 컨테이너 미들웨어: IBM WebSphere HTTP Server 등
페이지 컨테이너 미들웨어: IBM WebSphere JSP Server 등
구성요소 컨테이너 미들웨어: IBM WebSphere EJB Server 등
여기서 미들웨어를 언급하는 이유는 미들웨어가 다음 두 가지와 관련되어 있기 때문입니다.
하나는 프로그래밍 패러다임과 관련이 있습니다: EJB와 같은 컴포넌트 패러다임
두 번째는 요청 에이전트, 메시지 버스 등 아키텍처 스타일과 관련이 있습니다.
그러나 상용 미들웨어 시장은 결국 소멸됐다. 선동자는 인터넷 회사입니다. 그 이유는 다음과 같습니다.
인터넷 기업은 사용자 수가 많고 동시성이 높은 대용량 데이터를 보유하고 있기 때문에 인터넷 자체적으로 고강도 미들웨어를 개발할 수밖에 없다.
하지만 인터넷 기업의 비즈니스 모델은 양털이 개에서 나오는 것이기 때문에 실제 생산에서 검증된 강력한 미들웨어를 오픈 소스로 공개할 예정이다.
그 결과 상용 미들웨어 시장은 사라졌다.
이제 클라우드 네이티브 기술 시대에
분산 원격 호출 미들웨어: gRPC 등
분산 메시지 전송 미들웨어: ActiveMQ, RabbitMQ, RocketMQ, Kafka는 예전에는 오픈소스로 인기가 많았으나 이제는 Pulsar가 인기를 끌고 있습니다.
분산 트랜잭션 관리 미들웨어: Seata 등
웹 컨테이너 미들웨어: Apache에서 Nginx, 지금까지 Envoy까지
페이지 컨테이너 미들웨어: 이제 프로그래밍 아이디어가 대중화되었습니다. 순수한 프런트엔드 HTML+CSS+JS 기술은 MVVM 아키텍처로 구축되었습니다. AJAX 기술은 서버 계층을 호출하는 데 사용됩니다. 서버 계층도 HTTP/Restful 기술을 사용하는 공통 클래스입니다. 서비스를 노출하기 때문에 별로 JSP/ASP 기술을 사용하지 않습니다.
구성 요소 컨테이너 미들웨어: 이제 구성 요소가 필요하지 않으며 모두 공통 클래스이므로 구성 요소 컨테이너 서버가 필요하지 않습니다.
(6) 소프트웨어 엔지니어링 - R&D 도구 파이프라인
코드 저장 - 코드 버전 관리 - 자동화된 컴파일 도구 - 자동화된 테스트 도구 - 패키징 도구 - 릴리스 도구 - 자동화된 배포 도구 - DevOps 도구(예: 로그, 경보, 서비스 체인 추적 도구)
예전에는 마이크로소프트의 EXE 설치 패키지, 자바계의 WAR 설치 패키지 등 설치 패키지로 패키징하는 것이 일반적이었지만, 이제는 컨테이너로 패키징하는 것이 대중화됐다. Docker 컨테이너 기술은 과거에도 인기가 있었고, wasm 컨테이너 기술은 앞으로도 인기를 끌 것입니다.
어떤 사람들은 이 R&D 도구 조립 라인, 마이크로서비스 미들웨어, 마이크로서비스 프로그래밍 프레임워크를 통틀어 클라우드 네이티브라고 부르는데, 왜 클라우드 네이티브라고 불리는지는 모르겠지만 지금은 이 이름이 매우 유명합니다.
