👐 티어가 올라가기 시작 ▶ 초반과 다른 난이도 초반에는 난이도가 어렵지 않았다. 논리적으로나 아니면 조금만 생각해봐도 풀 수 있는 문제로 구성이 되어있었다. 하지만 하루하루가 다르게 난이도가 급상승하는 것을 느낀다. 내일의 문제를 오늘 보는 편이 아닌데 팀 스터디 하시는 분들이 점점 어려워지는거 같다고 하셨다. 최근에 BFS 와 DFS를 이용한 코딩테스트를 공부하지 않았다면 오늘 문제는 풀지 못했을 것이다. 점점 어려워지는 난이도...점점 몸에 힘이 풀리는 중ㅋㅋ 👐 팀스터디 ▶ 다른 사람들은 안어려운가..? 다른 분들은 용캐 이리저리 잘 푸시는것 같다. 궁금한거나 풀면서 의아했던 점을 나누는걸 보면 고민이 드는 쪽은 다들 비슷비슷한거 같다. 하지만 이제 뒤로 가면 갈수록 문제를 아예 못푸는 날이 올것..
분류 전체보기
🦴 User Microservice 를 API Gateway에 등록 ▶ 연동을 위해 application.yml 파일에 등록 routes: - id: user-service uri: lb://USER-SERVICE predicates: - Path=/user-service/** 🦴 User Microservice 기능 추가(사용자 조회와 정보, 주문 내역 조회) 전체 사용자를 조회 할땐 현재 서비스에 가입된 회원 전체를 나타낸다 사용자의 Id를 통해 회원을 보려고 한다면 회원의 정보와 회원이 주문한 내역까지 함께 나타낸다. ▶ 전달 객체 1. ResponseUser @Data @JsonInclude(JsonInclude.Include.NON_NULL) public class ResponseUser { p..
💐 강의 ● 다양한 자료구조 문제가 어렵지 않다보니 조금 다양한 생각을 해볼 수 있었다. 배열을 사용할지 자료구조를 사용할지 for문의 불필요한 탐색은 없는지 등등 생각을 좀 더 여러 방면에서 해보게 될 수 있는 시간이였다. 하지만 내일은 더 어려울 예정이라고 하니 더 걱정된다 💐 오늘의 팀스터디 ● 배울게 많군 확실히 사람들이랑 코테를 같이 푸니까 성능에 대한 생각을 많이 하게 된다. 코드의 간결성과 가독성 그리고 성능까지 평소에는 풀면 장땡이였는데 팀스터디를 시작하면서 성능에 대한 고민이 많아졌다. ● 기술 매니저님 기술 매니저님에게 물어보면 답을 알려주신다기 보다 생각해봐야할 방향이나 가고있는 방향을 제대로 잡아주는 경우가 많았다. 근데 문제가 그리 어렵지 않아서 물어볼게 많지 않았는데 내일부터 문..
👽 명세서 작성 Features 신규 회원 등록 회원 로그인 상세 정보 확인 회원 정보 수정 / 삭제 상품 주문 주문 내역 확인 API 명세서 라이브러리 등록 Lombok H2 Spring Boot DevTool - 굳이 웹을 종료하지 않아도 reload 해주는 기능이 포함되어 있다. Spring Web Eureka Discovery Client JPA Model Mapper 👽 기본 설정 코드 작성 1. UserServiceApplication @SpringBootApplication @EnableDiscoveryClient public class UserServiceApplication { public static void main(String[] args) { SpringApplication.run..
- 오늘 진행된 강의에서 학습한 내용은 무엇인가요? - 이번 주 진행된 팀 스터디에서 얻은 인사이트는 무엇인가요? 💐 코테를 위한 강의 ● 1일차는 쉽다? 코테가 본격적으로 시작되었다. 그래도 풀어봤거나 오늘안으로 하기 쉬운 코드들로 이루어져 있어서 비교적 쉬웠다. 물론 딱히 알고리즘이나 자료구조를 사용해서 문제를 푸는 것이 아닌 다른 방식으로 문제를 풀기 때문에 쉬웠을것이다. 앞으로 얼마나 어려워질지 걱정이 된다 💐 정식으로 시작한 코테 팀 스터디 ● 팀 스터디 시작 역시 팀스터디는 생각보다 어렵다. 각자 본인이 작성한 코드를 올리고 사람들과 비교하는 것이 쉽지 않다. 다른 사람들의 코드를 읽는 것 그리고 자신의 코드를 리뷰하는 것은 상당히 번거롭고 어려운 일이다. 그리고 남의 코드를 선택하고 팀 코드..
🐍 Api Gateway란? 사용자가 설정한 라우팅 설정에 따라 각각의 엔드포인트로 클라이언트를 대신해서 요청하고, 해당 응답을 받으면 다시 클라이언트에게 전달하는 proxy 역할을 한다. 시스템의 내부 구조를 숨기고, 외부의 요청에 대해 적절한 형태로 가공해서 응답을 진행 할 수 있다. Gateway 의 장점 인증 및 권한 부여에 대한 단일 작업 서비스 검색 통합 응답 캐싱 정책, 회로 차단기 및 QoS 다시 시도 속도 제한 부하 분산 로깅, 추적, 상관 관계 헤더, 쿼리 문자열 및 청구 변환 IP 허용 목록에 추가 🐍 Spring Cloud 에서의 MSA 통신 Spring Cloud 에서 MSA간 통신을 하기 위해 많이 사용하는 방식이 2가지가 존재한다 RestTemplate 전통적인 하나의 어플리케..
✍️ 1주차 종료 후기 ▶ 이력서..이력서 평소에 내가 쓴 프로젝트를 더 잘 정리해놓고 그때그때 어떤 생각을 했는지 잘 기록해두어야겠다 라는 생각을 했다 ✍️ 개인적으로 보완하고 싶은 모습이나 학습 습관이 있다면 무엇인가요? ▶ 글쓰기 능력 사실 지금까지 한 내용에 대한 기록을 잘해놓았다고 생각했는데 막상 작성하고 컨펌을 받아본 결과 뭔가 하나 비어있고 아쉬운 상황이라는 것이 뼈저리게 느껴졌다. 그리고 좀 더 추가적인 경험을 겪어야 하고 그것을 더욱 견고하게 더 쌓아나가야 한다는 생각이 든다 그리고 그걸 잘 작성해야한다는 생각도 계속해서 든다 ✍️ 모습을 어떻게 개선해볼까 ▶ 개인 프로젝트 이번 코스에서 개인 프로젝트를 정말 열심히 해볼 생각이다. 5분 기록을 십분 활용하고 readme도 깔끔하게 작성하..
🍀 ServiceDiscovery Microservice 가 시작 될 때, 서비스 레지스트리에 자신을 등록하고, 다른 서비스 필요로 할 때 해당 레지스트리를 조회해서 서비스의 위치를 알아낼 수 있게 한다. 각각의 서비스를 ServiceDiscovery에 등록하고 이후 LB가 ServiceRegistry에 위치를 물어보고 나온 곳을 통해 호출하는 것이다. 왜 ServiceDiscovery 가 필요할까? API Gateway만 존재해도 해당 인스턴스의 IP를 직접 호출 할 수 있다. 하지만 어떤 서비스가 도메인을 사용하는 것이 아닌 IP를 사용한다던가 LB를 사용해 호출을 하게 된다면 그에 필요한 추가 설정이나 IP를 추가적으로 변경해주어야 하기 때문입니다 하지만 ServiceDiscovery를 사용하면 인..
✍️ 기업 분석을 진행했다 ▶ 아직 모자르다. 사실 이번주 내내 같은 말을 계속하는 것일 수 밖에 없다. 내가 괜찮다고 생각한 모든 회사의 원하는 인재상에는 MSA 가 빠지질 않았고 도커, AWS 등등 나에겐 어려운 기능을 마치 당연한것처럼 적혀있었고 그것을 사용하지 않은 나의 이력서는 지원할 용기가 도저히 나지 않았다. ▶ 행복회로 오늘 여러 회사를 보면서 든 생각은 이런 회사 들어가면 너무 행복할 거 같은데? 였다ㅋㅋㅋㅋ 뭐... 들어가면 되지? ✍️ 강조해야하고 보완해야 할 것들 ▶ 블로그에 기록하는 습관 내가 강조할 수 있는 것은 블로그에 기록하는 습관과 코드를 작성하고 그것을 테스팅하는 것에 집중해야 한다는 것이다. 이것은 뒤에 있을 개인 프로젝트를 위해 마음을 다잡는 중이다. ▶ Cloud N..
🌍 Monolith vs Microservices Microservice Architecture는 정반대되는 개념인 Monolith Architecture와 같이 설명할 때 그 이해가 훨씬 빠르다고 할 수 있다. ● monolithic 모든 업무 로직이 하나의 어플리케이션 형태로 패키지 되어 서비스를 진행한다. 어플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태를 뜻한다. 데이터 베이스 또한 하나의 데이터베이스에서 모든 데이터를 저장한다. 문제점 서비스들중 하나의 문제만 발생하더라도 그것을 수정하고 전체 어플을 다시 빌드하고 테스트에 패키징까지 하는 데 이는 시간과 비용이 너무 크다는 것이다. ● microservice 비즈니스 기능 중심 구축 / 완전히 자동화된 배포 시스템을 갖추..
