:)

[REST (Representational State Transfer)]     자원을 URI로 표시하고 해당 자원의 상태를 주고 받는 것     REST하지 못한 API는 ?         CRUD 기능을 전부 POST METHOD로만 처리하는 API         URI에 자원과 id외 정보가 들어가는 경우 [REST 구성 요소]     자원(Resource): URI     행위(Verb): HTTP METHOD     표현(Representations)     즉, Rest는 URI를 통해 자원을 표시하고,      HTTP METHO를 이용하여 해당 자원의 행위를 정해주며     그 결과를 받는 것 [REST 특징]     Uniform Interface (유니폼 인터페이스)         HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용하여도 사용이 가능한 인터페이스 스타일          Stateless (상태 정보 유지 안함)         서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리         이전 요청이 다음 요청 처리에 연관이 되면 안된다     Cacheable (캐시 가능)         웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용이 가능     Self-descriptiveness (자체 표현 구조)         Rest API 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조     Client-Server         Rest 서버는 API 제공         클라이언트는 사용자 인증에 관련된 일들을 직접 관리         자원이 있는 쪽을 Server라고 하고 자원을 요청하는 쪽이 Client가 됨         서로간의 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야할 내용들이 명확해짐     Layerd System (계층화)         클라이언트는 Rest API 서버만 호출         Rest 서버는 다중 계층으로 구성될수 있음         로드

MSA (Micro Service Architecture) 기본구성, 구조설계 출처 : Medium  https://medium.com/@yesesyo [요약]     - 독립적 배포 가능한      - 스스로 돌아 갈 수 있는 작은 서비스     - 물리적으로 분리된 서비스이지만, 논리적으로는 하나의 어플리케이션처럼 동작     - 서비스끼리 분리되어 있기 때문에 성능, 트랜젝션 관리, DB무결성 이슈는 가장 주의해야할 요소 [장점]     개별 배포 및 무중단 배포 가능 (독립성)     개별 배포가 가능하다는것은 요구사항을 신속하게 반영하여 빠르게 배포할수있다는 효과를 가져옴     특정 서비스에 대한 확장성이 용이함     장애가 전체 서비스로 확장될 가능성이 적음     부분적 장애에 대한 격리가 수월함     신기술의 적용 유연     서비스를 여러가지 언어로 개발/운영 가능 [단점]     전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있음     서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어남     서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 함     데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어려움     데이터의 정합성 또한 관리하기 어려움 [MSA 구축 필수요소]     1) Service Discovery         각 서비스들의 네트워크 위치 정보와 가용 상태를 관리할 수 있는 서비스 레지스트리(Service Registry)를 둠             클라이언트가 서비스 레지스트리에게 가용 상태에 있는 서비스의 네트워크 위치 정보를 질의             서버사이드 디스커버리 / 클라이언트사이드 디스커버리 로 구현방식이 나눠짐                 클라이언트사이드 디스커버리      

[개요] A서버에서 B서버에 ssh 또는 scp 명령을 사용한 원격지 접속을 할 때 실 패스워드를 사용하지 않고 ssh-key 를 사용한 공개키 로그인 인증을 통해 접속하도록 함 [환경] 출발지 : A서버 계정 : auser 계정홈 : /part1/auser 도착지 : B서버 계정 : buser 계정홈 : /part1/buser [절차] 1. 출발서버(A서버) ssk-key 생성   $ ssh-keygen -t rsa 2. 권한 체크 700 : drwx------ : /part1/auser/.ssh/ 600 : rw------- : /part1/auser/.ssh/id_rsa 600 : rw------- : /part1/auser/.ssh/id_rsa.pub 만약 위와 같은 권한으로 되어있지 않을경우 권한 변경 필요 (왜? ssh-key 인증에 필요한 환경에 소유자 외에 쓰기권한이 있을경우 처리불가) chmod 700 /part/auser/.ssh chmod 600 /part/auser/.ssh/id_rsa chmod 600 /part/auser/.ssh/id_rsa.pub 3. 도착서버(B서버) authorized_keys에 출발서버 공개키 등록 A서버 : cat /part1/auser/.ssh/id_rsa.pub B서버 :  - 열고 : vi /part1/buser/.ssh/authorized_keys  - A서버에서 확인한 키값을 맨 아랫줄에 붙여넣기  - 좀더 스마트하게 작업할수도있겠지만.. 지금 바빠서 다른 붙여넣기 방법은 다른 블로그를 확인!!!  - .ssh 폴더랑 authorized_keys 파일이 없으면 ? mkdir 이랑 touch명령으로 만들어도 됨  - B서버도 마찬가지로 .ssh 디렉토리랑 authorized_keys는 700 으로 권한 변경 해주자  - 또한! buser 계정에 홈에 해당하는 /part1/buser/ 디렉토리도 소유자 외에 쓰기권한이 없어야 한다 (7