본문 바로가기

공부기록

 (72)
쿠버네티스 인 액션 - 1장 쿠버네티스 소개 쿠버네티스는 서버 배포를 자동으로 스케줄링하고 구성, 관리, 장애 처리를 포함하는 자동화에 대한 요구로 개발되었다. 대규모의 클라우드 환경에서 실행되는 서비스들을 추상화 시킬 수 있다. 쿠버네티스가 필요한 이유 모놀리스 애플리케이션에서 마이크로서비스로 전환 마이크로 서비스 배포의 어려움: 배포 조합의 수뿐만 아니라 구성 요소 간의 상호 종속성 수가 훨씬 더 많아지므로 배포 관련 결정이 점점 어려워진다. 실행호출을 디버그하고 추적하기 어렵다.(msa간 로그로 해결한다.) 서비스간의 라이브러리 버전 차이에서 오는 관리의 어려움 → 쿠버네티스가 관리해준다. 애플리케이션에 일관된 환경제공 운영체제, 라이브러리, 시스템 구성, 네트워킹 환경, 기타 모든 것이 동일한 환경을 만들 수 있다면 이상적일 것이다. 지속적..
ISTIO에 대한 간략한 정리 service-a, service-b 사이에 연결해줌 ( k8s, nomad, console에서 실행될 수 있음) 서로 통신하는 방법을 제어할 수 있어야함 1.로드 밸런싱 기능 -> 서비스 a와 서비스 b간의 2. 데이터 제어 기능 3. 접근 제어 4. 가시성 - 로그나 그래프 -> 모든 요소가 제대로 작동하는지 ( 모든 기능은 무료) -- Pilot - a/b테스팅, 카나리 배포, 제한시간 초과를 제어 Citadel - 서비스 메쉬의 보안 측면 - CA를 내장, 필요에 따라 서비스 A와 B의 통신 mixer - 모든 사이드카와 istio가 작동하는 방식을 중앙 집중식으로 관리하는 지점, 텔레메트리와 함께 사용(가시성, 그래프를 pilot 단계에서 표시), mixer는 장착이 기능(다른기능 추가가능), ..
mvc2편 및 고급편 이제 인프런 졸업할래.. 다음 강의는 udemy- The Git & Github Bootcamp 를 들어보자 (2022년 2월 20일 기록) git의 내부동작원리를 이해??
프록시를 사용할때 자주보는 문제 김영한 강의듣고 메모 프록시를 타도록 의도했지만, 자기 내부 함수를 호출하면 → 해당 함수는 프록시를 거치지않음 자신을 호출하는 경우 → 프록시를 거치지 않음 외부에서 호출할때만 프록시를 거쳐서 실행된다. 이런 문제를 해결하는 방법? → aspectj를 사용하면 이런 문제가 발생하지 않음 → 코드에 직접 박히기 떄문( aspectj는 실제로 코드 주입) 자기 자신을 주입하는 것? → setter 주입(생성/주입 단계가 분리되어 있어서, setter 주입을 하면좋다...) → 지연 조회 → application context로 자신을 호출함, 또는 ObjectProvider 구조 변경 → (가장 권장됨) 호출되는 클래스 분리(내부함수호출을 하지않음) ( 다양한 방법이 있을 수 있음) client →1 → ..
프록시 데코레이터 - 김영한 스프링 핵심 원리 고급편을 듣고 느낀점들 RequestMapping, ResponseBody는 인터페이스에서 사용할 수 있음. ( 컨트롤러를 인터페이스화 시켜서 사용하기) 그러나 Controller, RestController는 인터페이스에서 사용할 수 없음. config를 component scan의 대상이 안되도록 하기 위해서 Import 애노테이션 → config class 정의 SpringBootApplication에 scanBasePackage를 설정하여 config를 스캔하지 않도록 한다. 수동등록, 자동등록 → 둘다 많이 사용함 원본 코드를 전혀 수정하지 않고, 부가 기능을 추가할 수 있을까? ⇒ 프록시, 또는 AOP 프록시 요청을 앞서 처리해주는 레이어? 네트워크 프록시, 프록시..
템플릿 메서드 패턴과 전략, 콜백 스프링에서 자주 사용되는 패턴들 김영한 스프링 핵심 원리 고급편을 듣고 느낀점들 핵심 기능 → 객체가 제공하는 고유의 기능 부가 기능 → 로그 추적, 트랜잭션 기능. 핵심 기능과 함께 사용됨 이 모든 것들의 핵심은... → 변하는 것과 변하지 않는 것의 분리 → 변하지 않는 코드는 중복될 수 있는데, 한번만 작성될 수 있도록 하자 좋은 설계는 변경이 일어날 때 자연스럽게 드러난다. 템플릿 메서드 패턴 프레임워크가 만들어놓은 abstact class에서 함수하나만을 구현하면 되는 경우 주로 템플릿 메서드 패턴이라고 한다. 변하는 부분 → 템플릿 메서드 나머지 부분 → 인터페이스, 또는 abstract class에 장착 상속 클래스를 사용하거나, 익명 내부 클래스를 사용한다. (또는 SAM인 경우, 람다를 ..
7가지 동시성 모델 - 1장 서문 동시성 → 교사 한명이 학생들을 다뤄야함 병렬성 → 교사 한명과 조교 한명이 학생들을 다뤄야함 동시성과 병렬성이 혼동되는 이유 → 스레드와 잠금장치는 병령성을 직접 지원하지 않기 때문 동시적인 프로그램은 깁노적으로 비결정적 → 사건이 일어나는 시점, 즉 타이밍에 따라서 결과가 달라진다. 8비트 vs 32비트 컴퓨터로 32비트 문자열 → 8비트 컴퓨터로는 수열을 생성하여 해결, 32비트 컴퓨터로는 한번에 해결 현대 CPU는 파이프라이닝, 비순차 실행, 추측 실행 들의 기법을 이용하며 매우 병렬적 공유 메모리 (모든 프로세스가 공유) → 각각의 프로세스는 캐시 동시성 → 독립성, 장애 감지 → 탄력성, 장애 허용을 가능하게 해야함( 버그가 있을 수 있고, 버그가 없으면 하드웨어 장애가 있을 수 있기 때문) ..
12장. 다형성 상속은 타입 계층을 구조화하기 위해 사용해야 한다. 클라이언트 관점에서 인스턴스들을 동일하게 행동하는 그룹으로 묶어야 한다. 다형성 유니버셜 다형성 - 매개변수 다형성, 포함 다형성 임시 다형성 - 오버로딩 다형성, 강제 다형성 하나의 클래스안에 동일한 이름의 메서드가 존재하는 경우 - 오버로딩 다형성 강제 다형성 - + : 숫자면 덧셈, 문자열이 있으면 concat 매개변수 다형성 - 제네릭 프로그래밍 포함 다형성 - 수신한 객체의 타입에 따라 실제로 수행하는 행동이 달라지는 능력 - 일반적으로 객체지향에서 다형성이라 불리는 것 코드 재사용이 아닌 서브타입의 구현 - is-a ⇒ 포함 다형성에 대해 다룸 상속의 양면성 업캐스팅 동적 메서드 탐색 동적 바인딩 self 참조 super 참조 부모 클래스 타..
오브젝트 11장 - 합성과 유연한 설계 합성을 이용하면 포함된 객체의 내부 구현이 변경되더라도 영향을 최소화할 수 있기 때문에 변경에 더 안정적인 코드를 얻을 수 있게 된다. 코드 작성 시점에 결정한 상속 관계는 변경이 불가능하지만 합성 관계는 실행 시점에 동적으로 변경할 수 있기 때문이다. 클래스 상속 - 화이트박스 재사용(상태를 알아야 하므로) 합성 - 블랙 박스 재사용(인터페이스를 통해서만 재사용) 상속을 합성으로 변경하기 불필요한 인터페이스 상속 문제 → 불필요한 인터페이스를 사용안해도 된다. 메서드 오버라이딩의 오작용 문제 → 포워딩을 사용하여 기존 인터페이스를 그대로 제공하면서, 구현에 결합없이 사용할 수 있다. 부모 클래스와 자식 클래스의 동시 수정문제 →합성으로 변경해도 해결되지는 않는다. 파급 효과를 캡슐화하여 그래도 더 낫다..
오브젝트 10장 - 상속과 코드 재사용 전통적인 패러다임 → 코드를 재사용하는 방법은 코드를 복사한 후 수정하는 것 객체지향 패러다임 → 상속 또는 합성 10장에서는 상속, 11장에서는 합성에 대해 설명함 상속과 중복코드 중복코드 → 혼란야기 + 동료들을 의심하게 만든다 DRY 원칙 중복 코드는 변경을 방해한다. 중복 코드는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다. DRY원칙 = Don’t Repeat Yourself ⇒ 동일한 지식을 중복하지 마라 중복과 변경 책의 예제 코드 → 요구사항 변경으로 새로운 기능이 추가됨 → 상속으로 코드 중복을 줄임 상속을 위한 경고 1 → 자식 클래스의 메서드 안에서 super 참조를 이용해 부모 클래스의 메서드를 직접 호출할 경우 두 클래스는 강하게 결합된다. super 호출을 제거할 수 있..

티스토리툴바