마이크로 서비스 및-라인에서 발생하는 분할 몇 가지 문제

머리말

이 문서는 마이크로 서비스의 기본 이론을 설명하지 않습니다. 3. 분할, 분할 전에 1. (프로젝트는 마이크로 서비스를 필요로하는 이유는 기존 회사의 구조와) 2. 분할을 (주요 원칙 및 기술 지원 분할 과정)에 : 주로 주변에 다음과 같은 점 (온라인 서비스 발생하는 문제 및 솔루션)

본문

1. 전면 분할

회사 프로젝트는 이렇게 돈과 이익을 수집 분야에서 특정 솔루션을 제공하는 SaaS는 서비스 제품입니다. 이 회사의 조직 구조가되어 남쪽에 본사를두고, 여러 R & D 부서, 소주 내 부서가 있습니다. 전체 프로젝트는 테스트 환경 문제에 측정하지 않으면 좋은 다른 부서의 의지, 버전이 출시 될 예정 라인은 그것을 찾을 때까지 버전을 발표 공통의 고통 포인트 자식 저장소, 머리와 지역 및 그들의 고통을 컴파일한다 코드도 출시됩니다.

2. 분할

새로운 자식 저장소에 코드를 복사 한 후 외부이 서비스 코드를 잘라, grpc 통신에 의해 건설 서비스는 간단입니다

일부 기본값 1.grpc 문제, 그 구덩이

3. 후 분할

조립 라인 오프 테스트 환경 검색 서비스 라인 1. 서비스 연결 문제, 다른 서비스는에 순간의 일이 연결되지 않습니다. 우리의 현재 서비스 검색 아키텍처는 할 etcd을 기반으로합니다. 각 서비스는 시작시 연결 및지도,지도에서 서비스 이름을 기준으로 시간 RPC 요청에 저장된 정보와 같은 다른 서비스에 오프라인, IP / 포트 다른 서비스 듣고, etcd의 디렉토리에 가입 할 것 특정 정보와 서비스, 그리고 통신 연결을 가져올 수 있습니다. 어떤 문제의 특정 측면은 아직 분명하지 않다. 이 솔루션은 K8S 서비스 검색을 이동하는 것입니다.
2. 캐시 캐시는 할 레디 스 업데이트를 릴리스 가입 서비스 간의 동기화 문제를 기반으로합니다. 우리는 아키텍처의 사용을 마스터 - 슬레이브 모드 센티넬 레디 스. 때때로 변경 일 이후에 발견 서비스가 서비스 B에는 업데이트가 없다, 나는 문제가 마스터 데이터 (1) 결과가 될 redis2 메인 서비스 삭제 redis1에서 (주) 캐시, 결과 redis1 순간 실패를 스위칭에 의해 발생 의심 나는 2까지 업데이트되지 않았습니다. 그런 다음 서비스 B의 레디 스를 확인, 데이터 레디 스에 오류를 발견했습니다. 이 솔루션은 캐시 동기화를하지 않는, RPC 통신을 변경됩니다.
그들은 건강 검사는 40 대에 대해 장착되어 K8S 있도록 3. 타임 아웃과 라인에 문제 K8S는 아마 적은 30 대 이상 우리 지역의 시작의 운영 및 유지 보수를 이해합니다. 이 서비스가 다시 시작되었음을 발견 및 오류 로그했다. 운영 및 유지 보수 서비스는 개발자, 개발도 작은 문제보다는 위치에 문제가있는 말을하고, 마지막으로 조사 중 건강 문제를 확인하는 것입니다 찾을 수 있습니다.
4. 모든 원본 라우팅 문제는 A가 이제 서비스 B를 잘라 주요 서비스 경로이며, 경로 필요성의 일부 라우팅 규칙의 nginx에 비트와 함께 간단하게 계정에 워크로드 문제를 복용, 서비스 B로 이동, 결과는 구덩이이다 가. 판명 서비스는 서비스 B의 인터페이스로 라우팅 할 해결책은 통합 서비스 B 플러스 / servieB / API / XXX 프론트 엔드 인터페이스 앞에있다.

개요

이 회사는 사업이 항상 확장됩니다 수단, 코드가 점점 더 커질 것을 의미 존재한다. 사실, 우리의 이전 프로젝트 어떤 의미가 마이크로 서비스, 저장소는 서비스의 모든 코드를 관리 할 수 있다는 단점이 고려 될 수있다. 마이크로 라인 서비스는 모든 사용자를 (더 많은 돈을 수없는 혼란을 청구)에 영향을 방지하기 위해, 회색 릴리스 (에 ... 첫 번째 사용자의 작은 값을) 분할하는 것이 좋습니다합니다.

다른 많은 문제 무료 업데이트가 있습니다.