"Phoenix 아키텍처" 1장 - 서비스 아키텍처의 진화사

머리말

처음에는 ByteByteGo에 대한 여러 기사를 썼던 것처럼 모든 문장을 이해했습니다. 그러나 "Phoenix Architecture"의 경우 시간이 너무 많이 걸리고 불필요합니다. 어떤 항목은 절대 사용되지 않을 수 있지만 기사에서는 콘텐츠를 완전히 소개하기 위해 이러한 항목을 언급합니다. 그래서 나는 여전히 내 자신의 질문이나 내가 알고 싶은 것에 대해 약간의 추가 메모를 작성합니다.
처음 생각은 글을 블로그 형식으로 요약하는 것이었지만, 그 과정에서 요약하기가 어려웠습니다. 책의 모든 문장이 필요합니다.

요약하다

원래 분산 시대: 컴퓨터의 성능이 심각하게 부족하여 분산에 대한 예비 탐색이 수행됩니다.

단일 시스템 시대: 소규모 시스템의 경우 개발, 테스트 및 배포가 쉽고 대규모 시스템의 경우 전체 계층 구조의 원칙을 따르기 때문에 가장 큰 문제는 분리 불가능하지 않고 확장이 어렵습니다. , code 또한 코드를 재사용하고 관리하기 위해 모듈과 기능에 따라 구분되며 Jar, War 등 다양한 방법을 전개하여 부하 분산을 통한 확장 요구 사항을 충족할 수 있습니다. 그것의 진짜 문제는 무엇보다도 오류의 확산을 막을 수 없다는 것입니다.코드의 어떤 부분에 오류가 있으면 전체 프로그램에 영향을 미칠 수 있습니다. 특정 모듈이 분리되어 있고 유지 보수성이 좋지 않습니다. 세 번째는 기술 이질성을 달성하기가 쉽지 않으며 동일한 언어 또는 동일한 아키텍처를 사용해야 한다는 것입니다. 이를 대체하기 위해 마이크로서비스를 추진하는 또 다른 근본적인 이유가 있는데, 사실은 원래의 "최소한의 오류를 추구한다"에서 "오류는 불가피하다"로의 사고의 변화입니다. 오류를 허용하는 것이 마이크로서비스의 가장 큰 장점입니다.

SOA 시대: 원격 서비스 호출 방식을 기반으로 하는 서비스 지향 아키텍처라고도 하며 분산에 대한 포괄적인 탐색을 수행하고 매우 명확한 지침 원칙을 제시하며 분산 환경의 주요 문제를 성공적으로 해결하고 소프트웨어 개발도 제안합니다. 방법론. 기술에만 주목하는 것이 아니라 연구 개발 과정에도 관심을 기울인다. 하지만 그 규격이 너무 엄격하고 복잡도가 너무 크고 보편성이 강하지 않다는 단점이 있어 결국 실패했다.

마이크로서비스의 시대: 단일 애플리케이션은 분산형 거버넌스, 이기종 기술, 원격 호출, 애자일 개발과 유사한 제품 지향적 사고와 같은 기능을 갖춘 여러 소규모 서비스의 조합을 통해 구축되며 모두가 개발할 뿐만 아니라 테스트, 운영 및 유지 관리 등 데이터 분산화, 강력한 터미널 및 약한 파이프라인, RESTful 스타일을 사용하는 간소화된 통신 메커니즘, 내결함성 및 진화, 자동화 등으로 소프트웨어 개발이 더 자유로워집니다. 단점은 통일된 사양과 제약이 없으면 소프트웨어 아키텍처 설계의 어려움이 크게 증가한다는 것입니다.

포스트 마이크로서비스 시대: 마이크로서비스 시대에는 사람들이 소프트웨어 코드 수준에서 분산 문제를 해결하고, 포스트 마이크로서비스 시대에는 쿠버네티스를 사용하여 하드웨어 수준에서 분산된 세분화된 관리 기능을 직접 구현할 수 있습니다. 비즈니스와 아무 관련이 없습니다. 문제는 소프트웨어 수준에서 제거되어 소프트웨어 개발은 ​​비즈니스에만 집중할 수 있습니다.

무서비스 시대: 무서비스의 비전은 개발자가 기술 구성 요소, 배포 방법, 컴퓨팅 성능 또는 운영 및 유지 관리를 고려하지 않고 순전히 비즈니스에만 집중하면 되며, 이 모든 것은 완료된 클라우드 컴퓨팅 비즈니스에서 제공되는 것입니다. 그러나 현재 기술은 그다지 성숙하지 않았으며 복잡한 비즈니스 로직 및 서버 상태에 대한 종속성과 같은 문제에 대해서는 아직 경쟁력이 없습니다.

메인 콘텐츠

서비스 아키텍처 진화 역사:

• 원래 분산 시대:
  초기에는 컴퓨터의 성능이 심각하게 부족했습니다.컴퓨터의 성능과 컴퓨팅 성능을 향상시키기 위해 원격 서비스(서비스 검색)가 어디에 있는지, 몇 개( 로드 밸런스), 네트워크 분할, 시간 초과 또는 서비스 오류(퓨즈, 격리, 다운그레이드), 메서드 매개 변수를 표현하고 결과를 반환하는 방법(직렬화 프로토콜), 정보를 전송하는 방법(전송 프로토콜) 및 서비스 권한을 관리하는 방법(인증) , 권한 부여), 통신 보안을 보장하는 방법(네트워크 보안 계층), 동일한 결과를 반환하기 위해 서로 다른 시스템의 서비스를 호출하는 방법(분산 데이터 일관성) 등은 미래에 매우 영향력 있는 많은 이론을 제시했습니다.

• 모놀리식 시스템의 시대:
  Wikipedia의 정의에 따르면 "모놀리식은 독립형을 의미합니다. 모놀리식 애플리케이션은 동일한 기술 플랫폼의 여러 구성 요소로 구성된 단일 계층 소프트웨어를 설명합니다."
  먼저 작은 단일 시스템의 이점은 명백하고 개발, 테스트 및 배포가 쉽고 시스템의 각 기능, 모듈 및 메서드 호출 프로세스가 프로세스 간 호출이 아닌 프로세스 간 호출이기 때문입니다. 통신이 발생하고 모든 모듈 및 메서드 호출 네트워크 파티션, 개체 복제 및 성능 손실을 고려할 필요가 없습니다. 따라서 작업 효율이 매우 높습니다.
  단일 시스템의 부족은 소프트웨어의 성능 요구 사항이 단일 기계의 성능 요구 사항을 초과해야 하며 소프트웨어 개발자의 규모는 "2 피자 팀"(제안된 팀의 크기를 측정하기 위한 정량자)을 크게 초과해야 합니다. 피자 두 판이면 배불리 먹일 수 있다는 뜻의 아마존 창업자에 의해 배부른 사람 수(약 6~12명)는 논의할 가치가 있다.
  대규모 모놀리식 시스템의 경우 사람들은 분할할 수 없고 확장하기 어렵기 때문에 점점 더 큰 소프트웨어 규모를 지원할 수 없다고 말할 것입니다. 이 아이디어는 실제로 편향되어 있습니다. 수직적 관점에서 계층 구조를 따른다 수신된 외부 요청은 서로 다른 형태의 데이터 구조로 계층 간에 전송되며 마지막 데이터베이스를 터치한 후 역순으로 응답하게 되며, 수평적 관점에서 보면 또한 모놀리식 아키텍처는 소프트웨어를 기술, 기능, 책임 차원에 따라 다양한 모듈로 분할하여 코드를 재사용하고 관리할 수 있도록 지원합니다. 여러 개의 Jar, War 또는 기타 모듈 형식으로 완전히 구성할 수 있습니다.로드 균형 조정 방식에서 동일한 단일 시스템의 여러 복사본을 동시에 배포하여 트래픽 공유 효과를 달성합니다.이것도 매우 일반적인 확장입니다. . 실제 문제는 실제로 다음과 같습니다.
  1) 단량체가 오류 전파를 차단하기 어렵습니다.. 분할 후에는 자율성과 고립성을 달성할 수 없습니다. 코드의 모든 부분에 있는 결함은 격리하기 어려운 전역적 영향을 미치며 메모리 누수, 스레드 폭발, 차단 및 무한 루프와 같은 전체 프로그램에 영향을 미칩니다. 문제가 포트 번호 또는 데이터베이스 연결 풀 누수와 같은 일부 상위 수준 공용 리소스인 경우에도 전체 시스템 또는 클러스터의 다른 단일 복사본의 정상적인 작업에도 영향을 미칩니다. (위에서 언급한 바와 같이 여러 개의 Wars와 Jar가 수평으로 확장되어 있어서 하나의 Jar가 깨지면 다른 Jar도 깨지는 걸까요? 이건 얘기가 아니라 진짜 모노머입니다) 2) 프로그램을 동적으로 업데이트하는 것이 편리
  하지 않습니다 . 분리할 수 없으며(OSGi를 사용할 수 있지만 매우 복잡함) 코드의 특정 부분을 별도로 중지, 업데이트 및 업그레이드하는 것이 불가능함을 의미하기도 합니다. 따라서 유지 보수성이 좋지 않고 그레이 스케일 릴리스 및 A/B 테스트에 도움이 되지 않습니다.
  3) 기술적 이질성의 어려움에 직면 . 격리의 어려움은 또한 각 모듈의 코드가 일반적으로 동일한 프로그래밍 언어 또는 동일한 프로그래밍 프레임워크를 사용하여 개발되어야 한다는 사실로 이어집니다(JNI는 Java가 C 또는 C++를 혼합하도록 허용할 수 있지만 일반적으로 이것은 최후의 수단입니다. 우아한 선택이 아님) .
  위에 나열된 문제는 모놀리식 시스템을 마이크로 서비스로 대체하는 오늘날의 추세의 근본 원인이 아닙니다. 저자는 가장 중요한 이유는 다음과 같다고 생각합니다: 이 아키텍처 스타일의 기본 개념은 시스템의 모든 부분, 모든 코드 조각 그들은 모두 가능한 한 신뢰할 수 있으며 신뢰할 수 있는 시스템은 결함이 없거나 거의 없어 구축할 수 있습니다. 그러나 아무리 전술적 수준이 좋아도 전략적 수준의 부족을 만회하기 어렵다 높은 신뢰성을 보장하기 위해 고품질에 의존한다는 발상은 소규모 소프트웨어에서 잘 통할 수 있지만 규모가 클수록 시스템 규모, 신뢰할 수 있는 단량체의 전달 시스템은 점점 더 까다로워집니다. 마이크로서비스 아키텍처가 모놀리식 아키텍처에 도전하고 점진적으로 대체하기 시작할 수 있는 것은 바로 소프트웨어 아키텍처의 진화와 "가능한 한 적은 오류 추구"에서 "오류는 불가피하다"에 직면하는 신뢰할 수 있는 시스템 구축 개념의 전환과 함께입니다. 수십 년 동안 운영되어 온 신뢰가 여기에 있습니다.
  이는 시스템 규모가 작을 때 유리하지만 시스템 규모가 크거나 프로그램을 수정해야 하는 경우에는 기술 업그레이드를 위한 배치 및 마이그레이션 비용이 더 많이 들게 됩니다. 프로그램이 실수를 허용하고, 고립성과 자율성을 확보하고, 기술적 이질성을 달성하기 위해, 프로그램이 성능과 컴퓨팅 파워 이후에 다시 분산을 선택하는 이유입니다.

• SOA 시대:
  중국 이름은 Service-Oriented Architecture(Service-Oriented Architecture)입니다.큰 단일 시스템을 분할하기 위해 각 하위 시스템을 독립적으로 배포, 실행 및 업데이트할 수 있습니다.SOA가 도착하기 전에 개발자는 많은 시도를 했습니다. 다음은 세 가지 대표적인 아키텍처입니다.
  1) Chimney 아키텍처는 다른 관련 정보 시스템과 전혀 상호 운용하거나 조정하지 않는 디자인 패턴을 나타냅니다. 기업과 부서를 예로 들면, 기업 내에서 전혀 상호 작용하지 않는 부서가 정말 있습니까? 더욱이 이러한 "독립적 분할"과 "독립적 노후"의 시스템은 기업이 보기를 희망하는 것이 분명히 불가능합니다.
  2) 마이크로커널 아키텍처: 침니 아키텍처에서 비즈니스 관계가 없는 시스템도 인력, 조직, 권한 등과 같은 일부 공개 마스터 데이터를 공유해야 할 수 있으므로 이러한 마스터 데이터를 다른 하위 시스템과 함께 배치하는 것이 좋습니다. 각 서브시스템에서 사용 가능 공용 서비스, 데이터, 사용된 리소스가 모여 모든 비즈니스 시스템에서 공통적으로 의존하는 코어가 됨 특정 비즈니스 시스템은 플러그인 모듈 형태로 존재하여 확장 가능한 유연하고 자연적으로 격리된 기능, 마이크로커널 아키텍처.
  
  이 패턴은 데스크톱 애플리케이션에 적합하며 웹 애플리케이션에서도 자주 사용됩니다. 그러나 마이크로커널 아키텍처에도 한계와 전제조건이 있는데, 시스템의 플러그인 모듈이 서로를 알지 못한다고 가정하고 시스템에 어떤 모듈이 설치될지 예측할 수 없기 때문에 이러한 플러그인이 액세스할 수 있습니다. 일부 공용 리소스는 커널에 있지만 직접 상호 작용하지는 않습니다. 그러나 기업 정보 시스템이든 인터넷 응용 프로그램이든 이 전제는 많은 시나리오에서 사실이 아니며, 우리는 독립적인 시스템을 분할할 뿐만 아니라 분할된 하위 시스템 간의 원활한 통신을 허용하는 방법을 찾아야 합니다. 소통하다.
  3) 이벤트 기반 아키텍처: 하위 시스템이 서로 통신할 수 있도록 하기 위해 실행 가능한 솔루션은 하위 시스템 간에 일련의 이벤트 큐 파이프라인을 설정하는 것입니다. 시스템 외부의 메시지는 이벤트 형식으로 파이프라인으로 전송되고 각 하위 시스템은 파이프라인에서 관심 있고 처리해야 하는 이벤트 메시지를 가져옵니다. 이를 기반으로 각 메시지 처리기는 독립적이고 고도로 분리되어 있지만 이벤트 파이프라인을 통해 다른 처리기와 상호 작용할 수 있습니다.
  
  이후 원격 서비스의 호출로 SOAP 프로토콜이 탄생했고, 이를 기반으로 소프트웨어도 정식으로 SOA 시대로 접어들었다. SOA는 분산 서비스가 처음 제안되었을 때 대부분 예측할 수 있었던 마이크로 서비스의 미래 시대의 문제에 직면하여 보다 체계적이고 구체적인 탐색을 수행했습니다.
  "더 구체적"은 SOA가 더 강력한 운용성을 가지고 있지만 서비스 캡슐화, 자율성, 느슨한 결합, 재사용 가능성, 구성 가능성, 상태 비저장 등과 같은 소프트웨어 설계에 대한 명확한 지침 원칙이 있다는 점에서 반영됩니다. ESB(엔터프라이즈 서비스 버스)라는 메시지 파이프라인을 사용하여 다양한 하위 시스템 간의 통신 상호 작용 등을 실현합니다. 서로 밀접하게 협력할 수 있는 이러한 전체 기술 구성 요소 세트의 지원으로, 기술적 실현 가능성의 관점에서만 판단한다면 SOA는 분산 환경에서 주요 기술 문제를 성공적으로 해결했다고 볼 수 있습니다.
  "보다 체계적"은 SOA의 웅대한 이상을 말하며 궁극적인 목표는 기업이 SOA의 아이디어를 따라 소프트웨어 개발 프로세스를 패키지로 해결할 수 있기를 바라며 일련의 하향식 소프트웨어 개발 방법론을 요약하는 것입니다. 또한 SOA는 기술에만 관심을 두는 것이 아니라 연구 개발 프로세스에 관련된 요구사항, 관리, 프로세스 및 조직에도 관심을 기울입니다.
  그러나 너무 엄격한 사양 정의는 과도한 복잡성을 가져옵니다. 그리고 SOAP를 기반으로 구축된 ESB 및 BPM과 같은 많은 상위 구조는 이러한 복잡성을 더욱 악화시킵니다. 결국 정보시스템의 발전은 정형화된 글이 아니며, 지나치게 정교한 과정과 이론 역시 이를 통제할 수 있는 복잡한 개념을 이해하는 전문가가 필요하다. 여러 이기종 대규모 시스템 간의 복잡한 통합 및 상호 작용을 구현할 수 있지만 널리 적용 가능한 소프트웨어 아키텍처 스타일로 홍보하기는 어렵습니다. 역시 결국 되지 않았다.

• 마이크로서비스의 시대:
  마이크로서비스는 특정 기술 표준이 아닌 비즈니스 기능을 중심으로 구축된 여러 소규모 서비스의 구성을 통해 단일 애플리케이션을 구축하기 위한 아키텍처 스타일입니다. 각 서비스는 서로 다른 프로그래밍 언어, 서로 다른 데이터 저장 기술을 사용하고 서로 다른 프로세스에서 실행할 수 있습니다.서비스는 경량 통신 메커니즘과 자동화된 배포 메커니즘을 채택하여 통신 및 운영 및 유지 관리를 달성합니다. 다음과 같은 특징이 있습니다.
  1) Conway의 법칙의 중요성을 강조하는 비즈니스 역량을 구축 조직이 시스템을 설계할 때 조직의 커뮤니케이션 구조에 의해 제한되므로 제품은 조직의 커뮤니케이션 구조의 전형이어야 함 2) 분산된 거버넌스 , microservices are more 기술적 이질성이 정말 필요한 경우에는 "비통일"을 선택할 수 있는 권리를 가져야 함을 강조하며, 3) 서비스를 통해 독립적이고 자율적인 구성 요소를 구현합니다. "라이브러리"가 아닌 "서비스"를 통해 구성 요소를 구축하는 것을 강조하는 이유는 클래스 라이브러리는 컴파일 타임에 프로그램에 정적으로 연결되어 로컬 호출을 통해 기능을 제공하는 반면 서비스는 out-of-process 구성 요소이기 때문입니다. 4) 제품 사고, 과거에는 단일 아키텍처 하에서 프로그램의 규모는 모든 직원이 전체 제품에 주의를 기울이는 것이 불가능하다고 판단했으며, 개발, 운영, 유지보수, 지원 등의 조직 구성원은 모두가 자신의 업무에만 집중하지만 마이크로서비스 하에서는 개발팀의 모든 구성원이 제품을 생각하고 전체의 모든 측면에 관심을 갖는 것이 가능합니다. 5) 데이터 분산화, 마이크로 서비스 서비스는 데이터가 분산된 방식으로 관리, 업데이트, 유지 및 저장되어야 한다고 분명히 주장합니다.단일 서비스에서 시스템의 각 기능 모듈은 일반적으로 동일한 데이터베이스를 사용합니다.사실입니다. 중앙 집중식 스토리지는 본질적으로 일관성 문제를 피하기가 더 쉽지만 동일한 데이터 엔터티의 추상 형식은 종종 다른 서비스의 관점에서 다릅니다. 예를 들어, 서점에 있는 책의 경우 판매란에서는 가격, 수납란에서는 재고수량, 상품진열란에서는 책의 소개정보에 초점을 맞추어 중앙집중식 창고로 활용한다면 , 모든 필드를 수정하고 동일한 엔터티에 매핑해야 하므로 서로 다른 서비스가 서로 영향을 미치고 독립성을 잃을 수 있습니다. 분산 환경에서 일관성 문제를 처리하는 것은 매우 어렵지만 이를 보장하기 위해 전통적인 트랜잭션 처리를 사용하는 것은 종종 불가능하지만 두 가지 단점 중 덜 필요한 비용은 여전히 ​​지불할 가치가 있습니다.6 ) 강력한 터미널 약한 파이프 , 약한 파이프는 SOAP 및 ESB에 대한 직접적인 이름입니다. 복잡한 통신 메커니즘, 통신 파이프라인에 구축된 이러한 기능은 특정 시스템의 서비스의 특정 부분에 필요할 수 있지만 더 많은 다른 서비스에 부과되는 부담입니다. 서비스에 위의 추가 통신 기능이 필요한 경우 통신 파이프라인의 패키지가 아닌 서비스 자체 엔드포인트에서 해결해야 합니다. 마이크로서비스는 고전적인 UNIX 필터와 유사한 간단하고 직접적인 통신 방법을 옹호합니다.RESTful 스타일 통신은 마이크로서비스에서 더 적합한 선택이 될 것입니다.7) 내결함성 설계에는 마이크로서비스 설계를 위한 자동 메커니즘이 있어야 합니다. 오류 감지, 오류 지속 시 격리, 서비스 복원 시 다시 연결 8) 진화적 설계, 내결함성 설계는 서비스가 잘못될 것임을 인정하고 진화적 설계는 서비스가 사용되지 않을 것임을 인정합니다. 잘 설계된 서비스는 폐기할 수 있어야 하며 영원히 지속되지 않아야 합니다. 시스템에 변경할 수 없고 대체할 수 없는 서비스가 있다면 이는 해당 서비스가 얼마나 우수하고 중요한지를 의미하는 것이 아니라 시스템 설계가 취약하다는 신호입니다. 9) 인프라 자동화, CI/CD의 급속한 발전과 같은 인프라 자동화는 건설, 릴리스, 운영 및 유지 관리 작업의 복잡성을 크게 줄입니다. 마이크로서비스 하에서의 운영 및 유지관리 대상은 단일 아키텍처에 비해 수십 배 증가하기 때문에 마이크로서비스를 사용하는 팀은 인프라 자동화에 더 의존하고 사람이 수백, 수천, 심지어 수만 명을 지원하기 어렵습니다. 서비스의. . 의 빠른 개발은 구축, 출시, 운영 및 유지 보수 작업의 복잡성을 크게 줄입니다. 마이크로서비스 하에서의 운영 및 유지관리 대상은 단일 아키텍처에 비해 수십 배 증가하기 때문에 마이크로서비스를 사용하는 팀은 인프라 자동화에 더 의존하고 사람이 수백, 수천, 심지어 수만 명을 지원하기 어렵습니다. 서비스의. . 의 빠른 개발은 구축, 출시, 운영 및 유지 보수 작업의 복잡성을 크게 줄입니다. 마이크로서비스 하에서의 운영 및 유지관리 대상은 단일 아키텍처에 비해 수십 배 증가하기 때문에 마이크로서비스를 사용하는 팀은 인프라 자동화에 더 의존하고 사람이 수백, 수천, 심지어 수만 명을 지원하기 어렵습니다. 서비스의. .
  위의 마이크로서비스의 정의와 특징으로 볼 때 마이크로서비스는 SOA에서 폐기할 수 있는 거의 모든 제약과 규제를 버리고 보다 자유로운 아키텍처 스타일을 추구한다는 것이 명백해야 합니다. 하지만 통일된 명세와 제약이 없다면 과거 SOA로 해결했던 분산 서비스의 문제가 갑자기 재등장하지 않을까요? 실제로 마이크로서비스에서 이러한 문제에 대한 통합 솔루션은 더 이상 존재하지 않을 것입니다.Java 범위 내에서 사용될 마이크로서비스만 논의하더라도 서비스 간 원격 호출 문제만 솔루션 후보 목록에 포함될 수 있습니다. : RMI(Sun/Oracle), Thrift(Facebook), Dubbo(Alibaba), gRPC(Google) 등
  마이크로서비스가 가져다주는 자유는 양날의 검이다.한편으로는 SOA가 정한 복잡한 기술표준을 차단한다.단순한 서비스가 반드시 동시에 분산된 모든 문제에 직면하는 것은 아니다. SOA의 무거운 기술적 부담을 보물 주머니처럼 짊어질 필요가 없으며, 어떤 문제를 해결해야 하든, 어떤 도구를 도입하든 반면에 이러한 자유도 때문에 소프트웨어 아키텍처 설계의 난이도가 크게 높아졌습니다.

• 포스트 마이크로서비스 시대:
  마이크로서비스 시대에 사람들은 하드웨어의 인프라 수준이 아닌 소프트웨어의 코드 수준에서 이러한 분산된 문제를 해결하는 것을 선택합니다. 하드웨어로 구성된 인프라가 소프트웨어로 구성된 인프라를 따라갈 수 없기 때문입니다. 애플리케이션 서비스의 유연성은 무기력한 움직임입니다. 소프트웨어는 키보드 명령으로만 서로 다른 서비스로 분할할 수 있고 서비스는 복사 및 시작만으로 확장 및 확장이 가능합니다. 키보드를 입력하여 이러한 기능을 연결하시겠습니까? (즉, 소프트웨어는 비즈니스만 고려하자.)
  이 문제의 해결책은 컨테이너다. 이 단계에서 하나의 애플리케이션으로 패키징 컨테이너는 실제로 분산 문제 해결에 참여하지 않음 진정한 변화는 쿠버네티스의 성공적인 개발에서 비롯됨 다음 그림은 쿠버네티스의 기술 솔루션 간의 비교를 보여줍니다. 분산 문제와 기존 마이크로 서비스 솔루션을 해결합니다. 문제 해결의 방법과 효과는 시작점이 다르기 때문에 다르지만 의심할 여지없이 새롭고 더 유망한 문제 해결 방법을 제공합니다.
  
  가상화된 하드웨어가 소프트웨어의 유연성을 따라갈 수 있을 때 비즈니스와 관련이 없는 기술적인 문제는 소프트웨어 수준에서 제거되고 하드웨어 인프라 내에서 조용히 해결되어 소프트웨어가 비즈니스에만 집중할 수 있습니다. 소프트웨어 수준에서 분산 아키텍처로 인해 발생하는 다양한 문제를 독립적으로 처리하는 것부터 애플리케이션 코드 및 인프라, 소프트웨어 및 하드웨어 통합 및 아키텍처 문제를 공동으로 처리하는 시대에 이르기까지 미디어에서 종종 "클라우드 네이티브"라고 합니다. , 이름을 홍보하기 위해 매우 추상적입니다.
  그러나 Kubernetes는 여전히 모든 분산 문제를 완벽하게 해결할 수 없었습니다. "불완전"은 순수한 Kubernetes가 기능적 관점에서 이전 Spring Cloud 솔루션만큼 좋지 않다는 것을 의미합니다. 일부 문제는 애플리케이션 시스템 및 인프라의 가장자리에 있어 인프라 수준에서 미세 조정하기가 정말 어렵기 때문입니다. 예를 들어, 마이크로서비스 A는 마이크로서비스 B의 두 서비스인 B1과 B2를 호출합니다. B1은 정상적으로 작동하지만 B2는 연속 500 오류가 발생한다고 가정하고 특정 임계값에 도달한 후 B2를 융합해야 눈사태 효과를 피할 수 있습니다. 인프라 수준에서만 처리하면 딜레마에 빠지고 A에서 B로의 네트워크 경로를 차단하면 B1의 정상적인 호출에 영향을 미치고 차단하지 않으면 계속 오류의 영향을 받게 됩니다. B2.
  위의 문제들은 Spring Cloud와 같은 Application 코드로 구현된 마이크로서비스에서는 다루기 어려운 문제가 아닙니다. 그러나 인프라는 전체 컨테이너에 대해 관리되고 세분화는 상대적으로 거칠고 컨테이너 수준까지만 낮아 단일 원격 서비스를 효과적으로 관리하고 제어하기 어렵습니다.
  이런 문제를 해결하기 위해 오늘날 "Service Mesh"라고 불리는 "Sidecar Proxy"(Sidecar Proxy)가 도입되었는데, 이는 통신 프록시 서버를 쿠버네티스의 Pod에 주입하여 조용히 인계하는 것을 말합니다. 애플리케이션이 인식하지 못하는 상태에서 애플리케이션의 모든 외부 통신. 이 에이전트는 정상적인 서비스 간 통신(데이터 플레인 통신이라고 함)을 실현하는 것 외에도 컨트롤러로부터 명령을 받고(컨트롤 플레인 통신이라고 함) 제어 플레인의 구성에 따라 데이터 플레인 통신의 내용을 분석 및 처리합니다. 회로 차단, 인증, 측정, 모니터링 및 로드 밸런싱과 같은 다양한 추가 기능을 구현합니다. 이와 같이 응용 프로그램 수준에서 별도의 처리 코드를 추가할 필요가 없으며, 거의 프로그램 코드 못지않은 세밀한 관리 기능도 제공합니다.
  애플리케이션 시스템과 동일한 리소스 컨테이너에서 실행되는 프록시 서비스를 소프트웨어로 간주해야 하는지 인프라로 간주해야 하는지 개념적으로 판단하기는 어렵지만 애플리케이션에 투명하고 소프트웨어 코드를 변경하지 않고도 서비스 거버넌스를 구현할 수 있으므로 충분합니다. 프로그램 코드에서 "선택할 통신 프로토콜", "트래픽 예약 방법", "인증 및 권한 부여 방법"과 같은 기술 문제를 분리하고 오늘날의 Spring Cloud 제품군 버킷에서 대부분의 구성 요소 기능을 대체합니다. 고려 비즈니스 자체 로직을 기반으로 이상적인 스마트 단말기 솔루션입니다.

• no-service의 시대:
  no-service에 대한 특별히 권위 있는 "공식적인" 정의는 아직 없지만 그 개념은 이전 아키텍처만큼 복잡하지 않습니다. 포인트이며 백엔드 기능과 기능의 두 가지 콘텐츠만 포함합니다.
  백엔드 설비는 데이터베이스, 메시지 큐, 로그, 스토리지 등을 말하며 비즈니스 로직의 운영을 지원하기 위해 사용되지만 비즈니스 의미는 없습니다. 이러한 백엔드 설비는 모두 클라우드에서 실행됩니다. "백엔드에 대한 서비스로".
  기능은 비즈니스 논리 코드를 가리킨다.여기서 기능의 개념과 입도는 프로그램 코딩의 관점에서 기능에 매우 가깝다.차이점은 서비스가 없는 기능은 클라우드에서 실행되며 고려할 필요가 없다. 컴퓨팅 파워 또는 용량 계획 "서비스로서의 기능"이라고 부릅니다.
  서버리스의 비전은 개발자가 순전히 비즈니스에만 집중하면 되고 기술 구성 요소를 고려할 필요가 없다는 것입니다.백엔드 기술 구성 요소는 기성품이며 조달, 저작권 및 모델 선택 문제 없이 직접 사용할 수 있습니다. 배포 방법을 고려할 필요가 없습니다. 배포 프로세스는 클라우드에서 완전히 호스팅되고 작업은 클라우드에서 자동으로 완료됩니다. 전체 데이터 센터에서 지원하는 컴퓨팅 성능과 컴퓨팅을 고려할 필요가 없습니다. 전력은 무제한으로 간주할 수 있으며 운영 및 유지 관리에 대해 걱정할 필요가 없으며 시스템의 지속적이고 안정적인 운영을 유지하는 것이 클라우드 컴퓨팅 서비스 제공자의 책임은 더 이상 개발자의 책임이 아닙니다.
  서버리스 아키텍처의 장기적 전망은 좋아 보이지만 저자는 서버리스의 단기적 발전에 대해 그다지 낙관적이지 않습니다. 비즈니스 로직이 복잡하고 서버 상태, 응답 속도에 의존하고 긴 링크가 필요한 애플리케이션에는 적합하지 않습니다. 이는 무서비스에서 "무제한 컴퓨팅 파워"를 가정하여 사용량에 따라 과금을 하여 소비되는 컴퓨팅 파워의 규모를 제어해야 하기 때문입니다. , 요청이 도착해야만 실행을 시작합니다. 이로 인해 함수가 서버의 상태에 의존하는 것이 불편하고 또한 함수가 콜드 스타트 ​​시간을 가지며 응답 성능이 너무 좋을 수 없습니다(현재, 서비스가 없는 콜드 스타트 ​​프로세스는 아마도 수십에서 수백 밀리초 수준일 것입니다. Java의 경우 이 클래스는 성능이 좋지 않은 애플리케이션을 시작하여 몇 초에 가까운 수준까지).

핵심 문장

1. 아키텍처 진화의 가장 중요한 원동력, 또는 이러한 "크고 작은" 변화 추세의 가장 근본적인 원동력은 항상 특정 서비스의 순조로운 "죽음"과 "재생"을 촉진하는 것입니다. 개별 서비스의 생사의 변화는 전체 시스템이 안정적으로 생존할 수 있는지 여부와 관련된 핵심 요소입니다.
2. 건축은 발명된 것이 아니라 지속적인 진화의 결과입니다.
3. 신뢰할 수 있는 시스템을 구축한다는 개념이 "가능한 한 적은 오류를 추구하는 것"에서 "오류는 불가피하다"에 직면하는 것으로 변화한 것은 바로 소프트웨어 아키텍처의 진화와 함께 마이크로 서비스 아키텍처가 모놀리식 아키텍처에 도전하고 점진적으로 대체할 수 있는 기반입니다. .
4. Unix DCE가 제안하는 분산 서비스의 설계 목적은 "개발자가 서비스가 원격인지 로컬인지 상관하지 않고 투명하게 서비스를 호출하거나 리소스에 액세스할 수 있도록 합니다."입니다.
5. 비즈니스와 기술이 완전히 분리되고 원격과 로컬이 완전히 투명합니다.아마 지금이 가장 좋은 시대일 것입니다.

다른

1. 유닉스란?
   간단히 말해서 대부분의 운영 체제의 창시자입니다(예: Windows는 그렇지 않음). 다음은 Zhihu의 답변입니다.

   현재 시스템은 Windows, Mac OS, Linux 및 각종 배포판 등 Windows 3.1 이후 버전의 Windows 커널이 nt 커널인 점을 제외하고 나머지 모든 시스템 및 버전은 유닉스에서 기원합니다. Windows에는 1과 2만 있고 맨 아래 계층은 Unix와 관련이 있으며 이후 버전은 전혀 관련이 없습니다. 그 중 Mac OS는 유닉스와 카네기멜론대 교수가 개발한 커널을 혼합한 혼합 커널이다. Linux는 완전히 유닉스와 유사합니다.

   유닉스에 관해서는 Mac OS, Linux, AIX, HP-UX 및 Solaris와 같은 많은 관련 단어가 있으며 모두 유닉스 계열 시스템입니다.

   유닉스 계열 시스템(영어: Unix-like; 종종 UN X 또는 nix라고도 함)은 FreeBSD, OpenBSD, SUN의 Solaris와 같은 다양한 Unix 파생 시스템과 Minix, Linux와 같은 전통적인 유닉스와 유사한 다양한 시스템을 말합니다 . , QNX 등 그들 중 일부는 자유 소프트웨어이고 일부는 독점 소프트웨어이지만 모두 원래 UNIX의 특성을 상당 부분 상속하고 많은 유사점을 가지고 있으며 모두 POSIX 사양을 어느 정도 준수합니다.
   UNIX의 상표는 International Open Standards Organization이 소유하고 있으며 단일 UNIX 사양을 준수하는 UNIX 시스템만 UNIX라는 이름을 사용할 수 있으며 그렇지 않으면 UNIX 계열(UNIX 계열)이라고만 불릴 수 있습니다.

   
   간단한 그래프:
   

2. 레이어링의 의미는
   
   우리에게 가장 친숙한 레이어드 아키텍처, MVC 아키텍처, 모델(Model)-뷰(View)-컨트롤러(Controller)를 포함하는데, 이 레이어들의 의미는 무엇일까요? 레이어드 디자인의 본질은 복잡한 문제를 단순화하는 것입니다. Zhihu의 대답은 다음과 같습니다.

   높은 응집력: 계층화된 설계는 시스템 설계를 단순화하여 다양한 계층 이 특정 모듈에 집중할 수 있도록 합니다
   .
   기능 재사용은 계층화 후에 달성할 수 있음,
   확장성: 계층화된 아키텍처로 인해 코드를 쉽게 확장할 수 있음

3. JAR, WAR
   Jar 및 War는 파일 압축으로 볼 수 있습니다.이 패키징은 실제로 코드와 종속 항목을 함께 압축합니다.
   Jar 패키지는 Java 패키지이고 War 패키지는 JavaWeb 패키지로 이해할 수 있습니다. Jar 패키지는 Java로 작성된 프로젝트로만 패키징되며 그 안에는 컴파일된 클래스와 일부 배포 파일만 있습니다. War 패키지에는 작성된 코드에서 컴파일된 클래스 파일, 종속 패키지, 구성 파일 및 HTML, JSP 등을 포함한 모든 웹 사이트 페이지를 포함한 모든 것이 포함되어 있습니다. War 패키지는 프로젝트의 모든 항목을 포함하는 웹 프로젝트로 이해할 수 있습니다.

4. 그레이스케일 릴리스
   그레이스케일 릴리스는 일부 사용자는 제품 기능 A를 계속 사용하고 일부 사용자는 제품 기능 B를 사용하도록 허용하는 릴리스 방법입니다. 사용자가 B에 대해 이의가 없으면 점진적으로 범위를 확장하고 모든 사용자를 B로 마이그레이션합니다. 이 접근 방식을 사용하면 전체 시스템에 영향을 주지 않고 새로운 기능이나 변경 사항을 테스트하고 검증할 수 있습니다.

5. 멀티쓰레딩과 동시성의 차이점
   먼저 쓰레드는 프로세스의 실행 단위이자 프로세스 내 스케줄링 엔터티로, 프로세스는 애플리케이션마다 격리 환경을 제공하는 것과 같다.
   동시성(concurrency)과 병렬성(parallelism)의 경우, 동시성(concurrency)은 여러 개의 작업이 같은 시간 내에 번갈아 실행되어 작업 스케줄링과 자원 관리에 중점을 두고 컴퓨팅 리소스를 공유하는 것을 의미하고, 병렬성(parallelism)은 여러 개의 처리 장치 또는 컴퓨팅 리소스, 그리고 독립적으로 작업의 분할 및 실행에 주의하십시오.
   멀티스레딩의 목적은 일반적으로 병렬 컴퓨팅을 위한 것이며 운영 체제는 이러한 스레드를 여러 CPU에 할당하여 동시에 실행할 수 있습니다. 그런 다음 단일 코어 CPU는 병렬 컴퓨팅을 달성할 수 없습니다.
   갑자기 질문이 있습니다. 왜 우리는 높은 동시성에 대해 자주 듣지만 높은 병렬 처리에 대해서는 듣지 않습니까?
   높은 동시성은 시스템이 동시에 많은 수의 요청을 처리할 수 있음을 의미하고 높은 병렬성은 시스템이 동시에 실행할 수 있는 작업 수를 의미합니다. 요청을 완료하려면 여러 작업이 필요하거나 여러 요청이 동일한 작업을 공유할 수 있습니다. 따라서 높은 병렬성은 높은 동시성을 달성하기 위한 수단일 뿐입니다.
   높은 동시성은 사용자 또는 클라이언트와 관련된 개념인 반면 높은 병렬성은 서버 또는 프로세서와 관련된 개념입니다. 사용자 또는 클라이언트가 관심을 갖는 것은 시스템이 요청에 신속하게 응답할 수 있는지 여부이며 시스템이 내부적으로 작업을 할당하고 실행하는 방법은 신경 쓰지 않습니다. 서버 또는 프로세서가 관심을 갖는 것은 작업 실행 속도를 향상시키기 위해 여러 코어 또는 여러 시스템을 사용하는 방법입니다. 따라서 높은 동시성은 시스템의 외부 서비스 품질을 더 잘 반영할 수 있는 반면 높은 병렬성은 시스템의 내부 작업 모드를 더 잘 반영할 수 있습니다.