Spring Framework 의 기타 기능들

yml는 프로퍼티에서 계층을 나눠주는거라 생각.(트리형식)

값은 value라는 건 런타임에서 환경을 조정

개발환경이나 설정환경이냐 이럴떄 사용

이런식으로는 많이 안 씀

String.from.props

$표시 넣음으로서 많이 사용 마이바티스 쓰면 이거의 값을 가진 걸 사용하겠다.

그렇기 때문에 yml값을 읽어서 넣겠다는 의미.

nonexistence는 설정하지 않으면 뒤의 값으로 들어간다.

마지막으로 기본적인 argument 파싱

nonexistence: exists

실행 할 떄 추가적인 변경사항 있으면 변경해야.

이건 굉장히 기초적인 활용이다.

value에 들어가는 값을 정의해야 되는데

원래는 클래스의 파라미터로 선언해ㅐ서 많이 쓰는데 이건 constuctor단위에서 쓰면 null로 나옴 끼야ㅏㅏ아악

기본적인 생성자 잡히고 역할 다 끝나면 넣는게 아닐까 생각해본다.(추측)

생성자에서 사용하고 지역변수에 저장 안하면 가져와서 쓰는거라 볼수 있고

밑에서 쓰면 부분부분 나눌 수 있다.

IOC 컨테이너가 그래서 대단함.

Profile Handling

어떠한 프로필로 설정했을 떄 어떠한 파일이 실행할 지 정하는 거.

여기에서 저 위까지는 스프링에서 실행해주겠다는 거.

실행 할때 인자로서 값을 주는 건 키를 생각해서 전달하면 된다.

그리고 프로파일 default :dev은 일반적으로 스프링부트가 실행하면서 정의 안 되어 있을 떄는 dev 프로파일을 실행한다.

스프링 부트가 실행하면서 읽어들이는 파일은 하나

application.yml을 읽고 나머지는 설정갋ㅅ으로 가지고만 있음

active 들어왔을 때 어떤 게 들어왔을 떄 자신이 들어왔을 떄

dev 그룹에 dev 파일을 읽도록 설정해서 그걸 실행하게 할 수도 있다.

물론 dev대신 저기 있는 prod, dev,common등 다른거로 바꿔가며 할 수 있다.

이게 정상은 아닌데 이렇게 할 수도 있다.

지금은 설정 4개 해놨다.

prod라는 값을 주면 prod와 common 둘다 사용하게 됨.

이걸 넣으면 스프링 배너를 안 나오게 할 수 있다.

사용할 파일을 골라서 가져온다라는 뜻.

이렇게 실행하면 보여준거 그대로 뜬다.

이거는 Dspring 옵션을 자바 파일로 옵션하면 세팅을 할 수가 있다.

-D옵션을 통해 다른 부분도 많이 넣어줄 수 있다.

-Dspring.profiles.active=dev

java –help로 보면 -D 부분에 나와있듯이 시스템 설정을 할 수 있다.

환경변수 : 일반적으로 path 변수가 무엇인지 같은거나 뭐가 있다 라던가. 변수를 os가 실행되고 있는 안에 저장을 해두는 방식.

어떤식으로 사용하느냐에 따라 이렇게 사용가능하고 도커가 실행하면서 변경사항이 필요한 곳에서 그게 OS에 실행되는 내부에 직접 들어가는 거기 떄문에 자기의 OS엔 영향 주지 않고 컨테이너 내부에만 작동하게 함.

리눅스의 가장큰 특징은 멀티세션 로그인이라서

멀티세션으로 서버에 사용하기 적합한 OS가 됨.

리눅스 커널이 떠있고 들어오는 사용자들에게 서버에 대한 변경사항에 대한

윈도우

커널이라는 본질이 존재하고 서버라면 모니터 없겠지만

쉘은 OS가 커널 사용하기 위한 UI shell이 커널과 소통함. Utility가 사용자가 사용하는 프로그램 툴

멀티 유저 멀티 로그인이라 했는데 쉘을 공유함. 쉘에다 하고싶은걸 치고 커널에 들어가고 커널에 요청이 들어온 순서에 따라서 그 결과를 세션에 넘겨주기 떄문에 이렇게 작동한다.

쉘 을 해석해서 보여주는게 터미널이다.

유틸리티에서 gradlew라는 파일이 있는데 스크립트 파일임.

실제로 실행되는 파일인데 OS가 받아들일수 있는 파일이고

OS에 지정된 Path 경로들에서 명령어를 찾는게 기본적인 원리 그걸 Path에 추가해야 실행이 된다.

세션에 한정되서 이 세션(터미널 세션에) 한정되어 있다고 볼 수 있다.

실제로 실행될 떄 컴퓨터가 지정되는 변수는 shell 프로그램 진행하느냐에 따라 다름.

보통은 자기가 사용하는 쉘이 어떤걸 불러들이는지가 있음.

export는 변수내지 값을 출력

Profile을 어떻게 설정하고 실행하느냐에서 와서 여기까지 옴.

아무튼

1. 스프링에서 어떻게 지정해서 실행할 지 지정하는 거 하나와

2. 런타임에서 환경변수 주는거
3. 아니면 export 명령어로 실행하고 주는 거.

모르겠으면 -D옵션은 프로파일에 작성 된거처럼 작동한다.

참고로 active도 propery에 줄 수 있고 얘는 컴파일 전에 정의한다는 차이가 있고

use legacy propery 이런 거도 있는데 2.3->2.4 넘어가면서 추가된거고 include 옵션도 있다

도커 이미지 파일

1. jar 파일만 실행하면 되는거고

2. 두번쨰는 jar 파일을 뜯어서 사용하는 방법

둘 중 하나만 실행해야 되고(주석처리하든 지우든)

build image with jar

app.jar로 카피하고 바로 jar파일로 실행한다.

이런 방식 하나

argument dependcy 방식 하나

MSA

일반적으로는 하나의 애플리케이션에 다 쏟아부어서 운영했었는데 되게 커지면 작은 수정을 위해서 한번에 전체를 껐다키거나 실제로 개발하면서 얘 때문에 의존성 문제로 뭔가 오류나면 이런걸 제거하기 위해 msa라는 방식으로 시스템 아키텍쳐라는 방식으로 설계해보자는 뜻.

분명한 역할이 있는 애들을 따로 관리하자. 그리고 걔들을 따로 관리를 하자라는 뜻 아키텍쳐의 OOP라는 거로 보면됨

얘들이 각각 하나의 스프링부트 애플리케이션, 노드 장고 뭐가 되든 이런식으로 진행하고 새로운 서비스 만들고 상호소통하는 방식으로 서비스를 구성하자는 방식으로 생겨남.

Spring Cloud GateWay

보면 스프링 부트를 위한 게이트웨이 패턴을 구현하기 위한 모듈임.

똑같이 그래이들에서 implementaion 보면

이런식으로 넣어줘서 진행하면 게이트웨이 진행할 수 있다.

게이트웨이 패턴은 어떤 url이 어떤 서비스로 가야할지 정의

서비스가 서로 상호통신하는걸 정하기 위해 비동기 통신 사용

MessageQueue 사용하기 위해 워커노드

카카오 택시라는게 메시지 큐를 많이 사용 어떤 응답이 돌아오고 실행하고 이런식으로는

작은 단위에선 rabbitMq

하나의 생산자가 있으면 여러개의 contsructor가 있고

가능한 빨리 처리할 수 있으면 그 사람이 가져가서 일을 처리

반되로 publish/subscribe는 일종의 구독서비스라 생각하면 됨

일종의 신문이나 잡지가 구독하면 그게 출간되면 구독하고 있는 사람한테 전달 되어야 하는 거(모두가 똑같은 메시지를 받는 거)

모다 높은 서비스와 통신이 필요할 떄 카프카를 쓴다. 아파치 재단 밑에 있는데 많이 까다로운데

Rabiit MQ는 바로 가져와서 하면 됨.

hostname이 필요 없다. 어떤식으로 어떤 환경변수를 읽어서 사용한지 같은 부분들 이름이 뭐고 패스워드가 뭔지

RabbitMQ 는 스프링 부트에서 AMQP라는 라이브러리가 있고 별다른 이야기는 아니고

https://www.rabbitmq.com/tutorials/tutorial-one-spring-amqp.html

여러 설정도 tutorials 폴더 보면 보기 가능하다.

왜 리시버랑 센더가 한 파일에 있지? 프로파일 폴더 보고 다른걸 알면 된다.

Queue라는 걸 생성하고 리시버가 큐랑 바인드 하고 센더도 큐랑 바인드 해서 양쪽 프로그램 둘다 큐랑 소통.

리시버가 여러개가 될 수 있다.

한가한 리시버가 메시지 가져가고 센더는 어떤 리시버가 가져갈 지 생각 할 필요가 없음.(비동기로 진행)

상대방의 겨로가에 나의 작업이 영향 받지 않을 때 비동기 씀.

예로 redis

publish는

여러명이 내용을 들어야 할떄 (카카오 택시)라던가 인적사항 변동이라던가.

msa에서 하나의 서버에서 자기 데이터 들고 있는데 다른 서버에 영향 미칠수 있는데 이걸 감지하도록 전달하는 거도 중요. 그럴떄 publish/subscribe를 쓴다. exchange로 요청 보내면 모든 큐에다 publish 하고 그게 구독자에게 돌아가는 것.

기술적으로는 그렇게 되어있따.

pan-out은 아무 상관없이 보내는 것 등등 상황에 따라 누구는 받고 안받고 이런거로 된다.

그리고 행동규칙을 만드는거라 RestAPI와는 다를 것

기본적으로 큐랑 상호소통하고 받는다 그걸 구현하면 된다.

Clouds Service

아마존 EC2나 컴퓨터 엔진이나 가상환경 제공해서 자기 사물 보여줌

자기 컴퓨터나 구축하면 서버나 구축하면 다 그걸 구축한 사람이 담당하는데 클라우드는 내부에 있는 가상환경이 진행되니까 유지보수 점검을 내부에서 대신해줌. 여러가지 규약을 책임또한 클라우드 제공자에게 있다.

버튼 몇번 클릭하면 상용에 적합한 디비가 구축한 됨.

ECR이나 Registry는 도커허브 도커 이미지 레지스트리를 구성하도록 도와줌.

실제로 인프라 스트럭쳐 구성하기 힘든 애들에게 자신들이 준비하는 .

물리 서버를 구축하는 거보다 클라우드 서버가 초기비용이 적고 대신 long term으로 감가상각을 보면 감가상각을 보면 유지보수랑 인건비가 발생하고 인건비가 발생하고 결론 은 long-term에서 어떻게 작동되는지 알아야 하지 않을 까라는 생각.

배포하고 도메인 받는건 더 나아가야된다.

HTTPS

일반적으로 암호화 /복호화 하는 방법은 2가지 있다.

일반적으로 알파벳 26글자를 대응하기 위해 0~5까지 있고 +5를 더하고 26을 넘어가면 26을 빼주고 이런식으로 아주 원시적인 복호화 암호화도 가능.

공개키로 암호화 했을떄 비공개키로 암호화 할 수 있다.

공개키만 퍼트림으로서 암호화 되서 들어오더라도 내가 가진 비공개키로만 들어갈 수 있으니까 염려가 없다.

이걸 동시에 사용하는게 Https

클라이언트가 랜덤데이터와 함께 암호화 알고리즘을 어떤거 사용할 수 있을 지 선택 권 보내줌.

랜덤 데이터 일부분 보내주면서 암호화 방식은 이런게 있다고 주면 서버가 그중에 사용할 방식을 돌려줌(2)

3에서 서버에서 SSL이라는 인증서를 이러한 사이트를 증명하는 거와 공개 키

인증서가 맞는지 확인하기 위해 브라우저 내부에서 일어나고 발근 기갑또한 언제까지 유효한지 확인하게 됨. 그리고 1과 2에 있는 랜덤데이터 합쳐서 공개키로 암호화함.

공개키로 암호화 해서 전송되는 과정에 리스닝 하고 있다 해도 서버에서 복호화를 다시 한다.

복호화를 하면 자신의 비공개키로 복호화 되고 자기도 분명하게 값을 알아볼 수 있게 됨.

이러한 과정이 handsquake하게 된다고 함.(악수한다고 함)

서로 의미없는 데이터를 주고받고 하면서 커뮤니케이션 하면서 대칭키로 사용함.

그 내용은 브라우저를 나가면 안되고 서버 밖으로 나가면 안됨.

통신데이터를 암호화 하면 서버에서도 똑같은 대칭키를 가지고 있으니까 복호화가 된다.

이게 나머지 통신이 어떻게 진행되는지

그리고 3 인증서 확인 부분에서 문제가 생기면 빨간색으로 뜨고 이런다.

아예 적용이 안되있으면 plain text 로 주고받고 하는데 그 경우를 조심해야.

앞에 있는 로드밸런싱을 해주는 경우도 있고

공부하는 과정을 넘어설 때 https 를 알아야 하는데.

명확히 말하면 프론트랑 백이 분리되가는데 백엔드 서버에서

jar파일 안에 리소스가 다지정되고 프론트에서 템플릿 엔진(리액트, 뷰.js 사용해서 rest 통신해서 백엔드 받아오고 이런 와중에 정확하게 연동이라 얘기하긴 그렇고 프론트에서 웹 또는 애플리케이션에서 백엔드를 스프링 부트로 가져가서 데이터 통신을 하게끔 만들었다. 그냥 안드로이드나 스위프트에서 작동하게 )

플러터 하시는 이유?(스프링 부트+ 플러터 연동). 백엔드 노리는 데 스프링 하고 플러터는 스프링 부트를 하든 장고를 하든 어지간한 과제에 대해 대응 할 때쯤 플러터 시작하는게 맞다.

백엔드에 대해 어케 생각하시는지. 눈에 보이는게 안 보이니까 그런데 데이터의 움직임이 보이면 그런거도 해결이 된다. 반대로 말하면 결과로 유연하고 이쁘게 만드는게 상한선?이라기에 그렇고 결과적으로 데이터를 잘 받아와서 많이 다루느냐 상세한 부분에서 조작하는 걸 시작했을떄 백엔드에서 할 수 있는 더 다양한 내용들. msa에서 할 내용이 훨씬 많다고 생각한다. 점점 가면갈수록 프론트는 이쁨에 집착함.(비교적 시간을 들이면 안될 부분이라던가)

포트폴리오는 자신이 만든 시스템을 어떤 모양새를 가졌는지 일반적으로 자신이 한 프로젝트에 대해서 아는 사람은 뭔가를 했겠구나 알아서 무엇을 했구나 어떤 상세한 걸 했구나 이런걸 다 알거라 생각합니다.

리소스 서버가 만들어지면 실제로 액션 서버를 만들고 서비스 구성하고 그 사이에 비동기 통신하게 어떻게 구현하고 이런걸 잘 써주면됨. 꾸준하게 메시지 주고받아야되서 어떤 grpc 통신을 하거나 이런걸 하고 http2 방식으로 통신 우리는 http1.2 방식 grpc는 구글에서 만든 통신. 굉장히 익숙해지면 어렵지는 않음. 입문하긴 어려움. 통신하기 위한 도구인데 전달하기위한 부분이 없게 됨.

실제로 통신이 대신하고 있는거(스프링 처럼) 스프링부트랑 grpc도 잘 조합해서 스프링부트가 꼭 웹애플리케이션을 위한건 아님 그 대표적인게 grcp로 만들 수 있는게 여러개가 있다.

여러개로 어떤 서비스에서 주고받을지 프로토 버스라는 메시지 사용해서 정의한 걸 각각 언어에 맞는 언어로 다시 만들어주고

grpc 서버라는게 있고 grpc sutb이라는게 있고

메시지 가지고 파라미터는 이런게 있다.

이제 얘를 주고받기 위한거로 주고받는 방법으로 이런 것들. 서비스고 한개의 rpc를 가지고있다(rpc는 함수라 생각하면 됨) 이 요청을 받으면 이 응답을 받는다. 이 응답을 사용하면서 실제 구현물이 나오게 된다.

클라이언트에서 stub이란걸 정의해서 주면 됨 왜냐면 객체 안에 다 구현이 되어있기 때문 pom에다 빌드를 해달라. 잠깐 타고 들어간 코드들이 자동 생성됨.

터미널은 자기 컴퓨터에 정의된 소프트웨어.(gui 소프트웨어) 쉘은 커널 쓰기 위한 소프트웨어

유틸리티는 쉘에서 커널과 소통하는 도구

쉘이라 부르는 건 타이핑에 대한 사람의 입력에 대한 반응을 결정하는게 쉘이라는 프로그램이고 쉘과 소통을 해서 입력이 들어가는게 터미널이다.

일련의 프로그래밍과 같은 행동을 할 수 있어 몇번 실행해서 차이 진행해도

서버에서 돌아다닐때 어떤 행동을 하는지 명확히 알게 되면 명령어 쳤을 때 어떤걸 하는지 잘 알면 유연하게 서버 돌아다니면서 파인더를 돌아다니면서 한다는 gui에 의존하는데 gui가 없는 서버환경에서도 유사하게 작업을 한다는 말이였다.

서버에서 CLI를 통해서 원하는 걸 찾는걸 잘해야 한다. 쉘 스크립트는 devops에

https 에 관련 되고

• 보안도 https 말하셨는데 보안도 많이 알아야 하는지. 아까 10월쯤에 구현 해보라 하셨는데 구현이 뭔지

스프링부트에 웹페이지 띄우게 되는데 그걸 로컬호스트로 뜨는 해준거에 http로 진행이 됨. https 로 통신을 할 수 있게 해봐라.

스프링 부트로 https 로 구현하기 nginx 로 https 로 ssl 이런식으로 찾으면 됨.

방법이 워낙 많아서 찾아보자. 대신 면접으로 https로 들어는거 설명해보세요 이런게 많이 나온다고 한다.

본질은 안 어려움, 자기가 맞는게 확신을 못하니까. 아까 맞다 틀리다를 확신을 못하니까 힘들고 지루함

파일을 주고받고 돌려준다.

도커로 디비를 서버에 올리면 그대로 올리면