만담 구조의 마이크로 서비스

프로필
서비스의 구분 은 구체 적 인 업무 에 따라 이 루어 지고 완전 자동 화 된 배치 체 제 를 통 해 독립 적 으로 배치 할 수 있다.모두 가 마이크로 서 비 스 를 이야기 하고 있 지만 언제 마이크로 서 비 스 를 사용 해 야 하 는 지,마이크로 서 비 스 를 사용 하려 면 어떤 문제 가 많은 사람들 에 게 여전히 모호 한 개념 인지 주의해 야 한다.본 고 는 여러분 과 함께 마이크로 서비스 와 관련 된 몇 가지 문 제 를 토론 할 것 입 니 다.
2.마이크로 서비스 와 단일 서비스
최초의 프로그램 체계 에 서 는 통상 적 으로 단일 서비스 이다.단일 서비스 에 있어 서 모든 서 비 스 는 하나의 프로 세 스에 있다.기업 응용 프로그램 은 보통 세 가지 주요 부분 으로 구 축 됩 니 다.클 라 이언 트 사용자 인터페이스(HTML 페이지 와 사용자 기기 에서 실행 되 는 브 라 우 저 에서 실행 되 는 자바 script 으로 구성),데이터 베이스(공공 에 삽입 되 고 관계 가 있 는 데이터 베이스 관리 중의 많은 표 로 시스템 을 구성 합 니 다)와 서버 엔 드 응용 프로그램 입 니 다.
서버 쪽 응용 프로그램 은 HTTP 요청,실행 영역 논리,데이터베이스 검색 과 데이터 업데이트,브 라 우 저 로 보 낼 HTML 보 기 를 선택 하고 채 울 것 입 니 다.이 서버 엔 드 프로그램 은 하나의 전체,즉 하나의 프로 세 스 입 니 다.시스템 의 모든 변경 사항 은 서버 쪽 프로그램의 최신 버 전 을 재 구축 하고 배치 해 야 합 니 다.
단일 서비스 에 있어 모든 처리 요청 논 리 는 하나의 프로 세 스 에서 실 행 됩 니 다.구조 화 와 코드 작성 규범 을 위해 프로 그래 밍 언어의 기본 기능 을 사용 하여 프로그램 을 클래스,함수,네 임 스페이스 등 으로 나 눕 니 다.
단일 서비스 도 부하 이퀄 라이저 뒤에서 여러 개의 인 스 턴 스 를 실행 하여 수평 으로 응용 을 확장 할 수 있 지만 서버 의 업무 가 점점 복잡 해 지면 서 서비스 에 대한 작은 변동 은 전체 서비스 에 대한 재 구축 과 배 치 를 초래 할 수 있다.또한 시간 이 지 날수 록 좋 은 모듈 화 구 조 를 유지 하고 기 존 구 조 를 확장 하기 어렵다.또한 단일 서비스 가 한 프로 세 스 에서 실행 되 기 때문에 이 프로 세 스 가 실 행 될 때 문제 가 발생 하면 모든 서 비 스 를 사용 할 수 없고 안정성 이 부족 합 니 다.
속담 에 계란 을 한 바구니 에 넣 으 면 안 된다 고 했다.
그래서 커 다란 단일 서 비 스 를 하나의 마이크로 서비스 로 나 누 는 것 이 현재 시스템 구조의 열풍 이다.
마이크로 서비스 구 조 는 하나의 응용 프로그램 을 하나의 서비스 로 나 누 는 것 이다.이런 서 비 스 는 독립 적 으로 배치 하고 확장 할 수 있 으 며 서비스 간 에 튼튼한 모듈 경계 가 있 고 서비스 간 에 주로 HTTP 협 의 를 통 해 상호작용 을 한다.서비스 간 에는 내부 결합 이 없 기 때문에 우 리 는 심지어 서로 다른 프로 그래 밍 언어 로 서로 다른 서 비 스 를 실현 할 수 있다.절차 의 유연성 을 높 였 다.

3.마이크로 서비스의 특징
마이크로 서 비 스 는 어떤 특징 이 있 습 니까?어떤 서비스 가 마이크로 서비스 라 고 불 릴 수 있 습 니까?
사회 가 복잡 하고 단순 한 것 은 사람 이다.실제 공정 상의 문 제 는 책 에서 배 운 지식 처럼 명확 한 정 의 를 내리 지 않 는 다.사실 학 교 를 나 간 후 이 세상 일 은 이미 흑백 이 아니다.
예 를 들 어 우리 가 학교 다 닐 때 배 운 원 의 정 의 는 원 이 무엇 인지 분명하게 알려 준다.마이크로 서비스 에 있어 서 는 이러한 정의 가 없다.
마이크로 서 비 스 는 끊 임 없 는 실천 에서 모색 해 낸 구조 이기 때문이다.비록 서로 다른 사람들 이 마이크로 서비스 에 대해 서로 다른 이 해 를 가지 고 있 지만 그들 은 모두 다음 과 같은 몇 가지 공 통 된 특징 을 가지 고 있어 야 한다.
3.1 구성 요소 서비스 화
소프트웨어 가 복잡 해 진 후에 소프트웨어 개발 과 후속 적 인 확장 을 잘 하기 위해 소프트웨어 는 점점 구성 화 되 기 시작 했다.구성 요소 란 독립 적 으로 교체 하고 업그레이드 할 수 있 는 위 젯 입 니 다.
현대 프로그램 에는 자바 의 의존 jar 패키지,python 의 의존 패키지 등 구성 요소 라 고 할 수 있 는 것 이 많 습 니 다.
이 lib 들 은 실행 할 때 프로그램 에 연결 하여 메모리 의 함수 로 실행 할 수 있 습 니 다.
링크 가 있 는 lib,왜 우 리 는 이 구성 요 소 를 서비스 화하 여 단독 프로 세 스 로 실행 해 야 합 니까?
서 비 스 를 구성 요소(라 이브 러 리 가 아 닌)로 사용 하 는 주요 원인 은 서비스 가 독립 적 으로 배 치 될 수 있 기 때문이다.프로그램 이 하나의 프로 세 스 의 여러 라 이브 러 리 로 구성 되 어 있다 면 하나의 구성 요소 에 대한 변경 은 프로그램 전 체 를 재배 치 해 야 합 니 다.
단,이 앱 이 여러 서비스 로 분 해 될 경우 해당 서비스 변경 에 대해 서 는 이 서 비 스 를 재배 치 하면 된다.이것 은 절대적 인 것 이 아니 지만 일부 서비스의 변화 가 대응 하 는 호출 인터페이스의 변 화 를 초래 할 수 있 기 때문에 대응 하 는 서비스 로 수정 하고 적합 해 야 한다.그러나 좋 은 마이크로 서비스 구조의 목 표 는 서비스 계약 중의 내부 집적 서비스 경계 와 진화 체 제 를 통 해 이러한 변동 을 최소 화 하 는 것 이다.
서 비 스 를 구성 요소 로 사용 하 는 또 다른 장점 은 더욱 명확 한 구성 요소 인터페이스 이다.대부분의 언어 는 명시 적 발표 인터페이스의 좋 은 메커니즘 을 정의 하지 않 아 구성 요소 간 의 결합 이 너무 긴밀 하 다.명시 적 원 격 호출 체 제 를 사용 하면 서 비 스 는 더욱 쉽게 정의 할 수 있다.
서 비 스 를 사용 하 는 것 도 그의 단점 이 있다.서비스 간 에 원 격 호출 을 통 해 원 격 호출 이 프로 세 스 내 호출 보다 더 비 싸 기 때문에 서비스 간 의 호출 은 보통 더욱 굵 은 입자 의 호출 이기 때문에 우 리 는 서 비 스 를 정의 할 때 명확 한 직책 분 배 를 구분 해 야 한다.
3.2 조직의 구분
콘 웨 이의 법칙 에 따 르 면 조직 소통 방식 은 시스템 설 계 를 결정 한다.
일반적으로 대형 시스템 은 UI 팀,서비스 논리 팀 과 데이터 베이스 팀 으로 나 눌 수 있다.그러나 이런 조직 방식 은 한 팀 의 변 화 를 초래 할 수 있 으 므 로 다른 팀 도 변 화 를 통 해 협조 해 야 한다.
그래서 마이크로 서비스 에서 조직 은 구체 적 인 업 무 를 설치 하여 구분 해 야 조직의 유연성 을 확보 할 수 있다.
3.3 서비스 간 의 통신
단일 서비스 에 있어 의존 하 는 lib 는 내부 함수 호출 을 통 해 이 루어 집 니 다.그 장점 은 속도 가 빠 르 지만 단일 서 비 스 를 마이크로 서비스 로 전환 하려 면 서비스 간 의 상호 호출 문 제 를 고려 해 야 합 니 다.
흔히 볼 수 있 는 서비스 간 의 호출 방식 은 어떤 것들 이 있 습 니까?
가장 흔히 볼 수 있 는 것 은 HTTP/HTTPS 프로 토 콜 간 의 호출 이다.이런 방식 의 장점 은 프로 토 콜 이 간단 하고 통용 되 며 호환성 원가 가 비교적 낮 다 는 것 이다.
크로스 언어 라면 보통 Thrift 와 같은 RPC 원 격 호출 프로 토 콜 을 사용 하 는데 이런 방식 의 장점 은 HTTP 호출 보다 빠 르 지만 호출 이 복잡 하 다 는 것 이다.특정한 클 라 이언 트 를 구축 해 야 합 니 다.
위 에서 말 한 것 은 동기 호출 입 니 다.비동기 라면 MQ 체 제 를 사용 할 수 있 습 니 다.MQ 의 역할 은 하 나 는 봉 을 깎 을 수 있 고 다른 하 나 는 결합 을 풀 수 있 습 니 다.
3.4 탈 중심 화 관리
마이크로 서비스 에 있어 모든 마이크로 서 비 스 는 같은 언어,같은 구조 방식 으로 진행 하도록 요구 하지 않 는 다.일반적으로 시스템 과 코드 의 유지 가능성 을 확보 하고 모든 서비스 가 같은 프로 그래 밍 언어 와 구 조 를 사용 하도록 요구한다.
그러나 특별한 부분,예 를 들 어 성능 에 대한 요구 가 매우 높다 는 등 수요 가 있 으 면 서로 다른 프로 그래 밍 언어 를 고려 해 볼 수 있다.
전체적으로 말 하면 모든 마이크로 서비스 팀 이 그들의 서비스 에 대해 책임 을 지고 대외 적 인 서비스 와 인터페이스의 정확성 만 확보 하면 된다.
3.5 탈 중심 화 데이터 관리
단일 응용 에 있어 서 모든 데 이 터 는 하나의 데이터베이스 에 놓 여 있다.만약 에 마이크로 서비스 에 대해 탈 중심 화 관 리 를 실시 했다 면 해당 하 는 데이터 베 이 스 는 각 마이크로 서비스 팀 에 속 하기 때문에 이론 적 으로 마이크로 서비스의 데이터 도 탈 중심 화 배치 해 야 한다.
그러나 이렇게 여러 개의 데이터 베 이 스 를 찍 은 결 과 는 각 데이터 베이스 에서 데이터 의 일치 성 이다.단일 응용 에서 이 문 제 는 데이터베이스 업 무 를 통 해 해결 할 수 있다.그러나 마이크로 서비스 에 있어 분포 식 사 무 는 불가능 하거나 대가 가 너무 크다.일반적으로 마이크로 서비스 에 있어 서 우 리 는 데이터 의 최종 일치 성 을 확보 해 야 한다.
보상 메커니즘 을 통 해 데이터 의 검사 와 복 구 를 진행 하 다.
3.6 자동화 배치
자동화 배치 의 목 표 는 지속 적 인 교부 이다.마이크로 서비스 에 있어 여러 서비스의 자동 화 는 필수 적 이다.자동화 컴 파일,자동화 테스트,자동화 통합 과 자동화 배 치 를 통 해 개발 팀 과 운영 팀 의 임 무 를 크게 줄 일 수 있다.개발 효율 을 높이다.
3.7 이상 에 대한 응답
서 비 스 를 구성 요소 로 사용 한 결과 프로그램 은 서비스 실 패 를 용인 할 수 있 도록 설계 해 야 한다.모든 서비스 호출 은 네트워크 나 다른 원인 으로 인해 사용 할 수 없 게 될 수 있 으 므 로 가능 한 한 우아 하 게 응답 해 야 합 니 다.
단일 서비스 에 비해 추가 적 인 복잡성 을 도입 하여 처리 해 야 하기 때문에 마이크로 서비스의 단점 으로 볼 수 있다.개발 팀 은 극단 적 인 환경 에서 프로그램의 정확성 을 확보 하기 위해 가능 한 한 이상 테스트 를 많이 해 야 한다.
서비스 가 수시로 고장 날 수 있 기 때문에 고장 을 신속하게 감지 하고 가능 한 경우 자동 으로 서 비 스 를 회복 하 는 것 이 중요 하 다.마이크로 서비스 응용 프로그램 은 응용 프로그램의 실시 간 감 시 를 매우 중시 하고 구조 요소(데이터 베 이 스 는 초당 얼마나 많은 요 구 를 받 는 지)와 업무 관련 기준(예 를 들 어 분당 얼마나 많은 주문 을 받 는 지)을 검사 합 니 다.의미 감 시 는 잘못된 조기 경보 시스템 을 제공 하여 개발 팀 을 따라 잡 고 조사 하 게 할 수 있다.불량 을 신속히 발견 하고 복구 하 는 것 이 중요 하 다.
저 희 는 모든 단독 서비스 에 대한 복잡 한 모니터링 과 로그 기록 설정 을 보고 싶 습 니 다.예 를 들 어 시작/닫 힌 상 태 를 표시 하 는 계기판 과 각종 운영 과 업무 관련 기준,그리고 차단기 상태,현재 스루풋 과 지연 에 관 한 상세 한 정보 등 도 포함 합 니 다.
총화
이렇게 많은 마이크로 서비스의 특징 을 이야기 했다.마이크로 서 비 스 는 그의 유연성 장점 이 있 지만 마이크로 서비스의 경 계 를 어떻게 구분 하 는 지,그리고 마이크로 서비스 에 대한 감 시 는 매우 복잡 한 문제 이기 때문에 마이크로 서 비 스 를 사용 할 지 독자 에 게 생각 하 게 해 야 한다.
마지막 으로 여러분 에 게 한 가지 질문 을 드 리 겠 습 니 다.현실 적 인 프로젝트 에서 많은 사람들 이 기 존의 단일 서 비 스 를 마이크로 서비스 로 나 누 기 를 원 하지만 각 마이크로 서 비 스 는 같은 데이터 베 이 스 를 공유 하고 있 습 니 다.즉,이런 마이크로 서비스 사이 에 데이터 교차 가 존재 한 다 는 것 입 니 다.그렇다면 이런 마이크로 서 비 스 는 진정한 마이크로 서비스 라 고 할 수 있 습 니까?
이상 은 바로 로 밍 구조의 마이크로 서비스의 상세 한 내용 입 니 다.마이크로 서 비 스 를 구축 하 는 데 관 한 자 료 는 저희 의 다른 관련 글 에 관심 을 가 져 주 십시오!