1. 모니터링
개별 서비스 수준이 아닌 시스템 수준에서 고려되어야 하는 서비스 전반에 걸친 시스템 상태에 대한 명확한 그림을 갖는 것이 중요합니다. 교차 서비스 문제를 진단해야 하거나 더 큰 경향을 이해하려는 경우에만 각 서비스의 상태를 알아야 하는 경우가 많습니다.
단순화를 위해 작성자는 모든 서비스가 상태 및 기타 모니터링 관련 메트릭을 동일한 방식으로 보고하도록 할 것을 권장합니다.
2. 통합 서비스 인터페이스 기술
잘 정의된 인터페이스 기술 몇 개(또는 한 개)를 선택하면 새로운 소비자의 통합이 용이해집니다.
3. 아키텍처 보안
비정상적으로 실행되는 서비스는 전체 시스템을 파괴할 수 있으며 각 서비스가 상위 서비스의 오류 응답에 대처할 수 있는지 확인해야 합니다.
이것은 일반적으로 회로 차단기를 도입해야 하며 회로 차단기는 특정 규칙에 따라 작동하므로 일부 고정된 규칙을 공식화해야 합니다. 예를 들어 회로 차단기가 HTTP 반환 코드에 따라 작동하는 경우 업스트림 서비스는 HTTP 상태 코드 상태 코드의 의미에 따라 4xx와 5xx는 혼합할 수 없습니다. 일반적으로 다음 요청을 다르게 처리해야 합니다.
- 정상적으로 응답하고 올바르게 처리됩니다.
- 정상적인 응답이지만 서비스에서 잘못된 요청으로 식별되었습니다.
- 응답 시간이 초과되어 대상 서비스가 다운되었습니다.
4. 코드 거버넌스
함께 모여 일을 처리하는 방법에 대해 합의하는 것이 좋습니다. 그러나 사람들이 이 합의에 따라 작업을 수행하도록 시간을 보내는 것은 재미가 덜합니다. 서비스 전반에 걸쳐 표준 관행을 사용하는 것이 개발자에게 부담이 되기 때문입니다. 따라서 최소한 다음을 수행해야 합니다. 예제 및 서비스 코드 템플릿 제공 .
실행 가능한 코드로 제공하든 문서로 제공하든 상관없이 예제를 제공하는 것이 유용합니다. 다른 사람들이 채택하기를 바라는 좋은 사례가 있다면 일련의 코드 예제를 제공하는 것이 큰 도움이 되지 않고 빠르게 모방하는 데 도움이 됩니다.
서비스 코드 템플릿을 제공합니다. 개발자가 새로운 서비스를 만들고자 할 때 기본 기능을 구현하기 위한 모든 코드가 미리 만들어져 있어야 하며, 개발자는 템플릿을 복사하여 빠르게 비즈니스 코드를 작성할 수 있습니다.
자신의 개발 방식에 따라 서비스 코드 템플릿을 조정하면 개발 속도를 높일 수 있을 뿐만 아니라 서비스 품질을 보장할 수 있으므로 팀은 템플릿을 최신 상태로 유지해야 합니다.
5. 팀에는 자율성도 있어야 합니다.
저자는 "모든 조직은 다르다. 그가 함께 일한 일부 회사는 회사에서 완전히 신뢰할 수 있는 고도로 자율적인 팀을 가지고 있다. 이 경우 원칙은 매우 가볍다. 그러나 일부 회사는 조직 구조가 강하고 개발자의 자유가 적습니다. 이때 규칙의 합리성을 확보하기 위해 [예외 관리]가 필요합니다.
여기서 내가 이해하는 저자의 태도는 다음과 같습니다. 건축가 또는 기술 감독은 개발자에게 너무 많은 제한을 두어서는 안 됩니다. 이는 기존 아키텍처/원칙의 합리성도 제한하기 때문입니다.
6. 중앙 집중식 거버넌스와 리더십
마이크로서비스 아키텍처의 리더(설계자 또는 기술 리더)의 역할 중 일부는 거버넌스입니다. 거버넌스란 무엇입니까?
거버넌스는 이해 관계자의 요구 사항, 현재 상태 및 다음 단계 가능성을 평가하고 우선 순위 지정 및 의사 결정을 통해 방향을 설정하여 기업 목표 달성을 보장합니다.
합의된 방향과 목표를 모니터링합니다.
리더의 책임 중 일부:
- 기술적 비전이 있는지 확인하고 거버넌스는 우리가 구축하는 시스템이 해당 비전에 부합하는지 확인하고 필요할 때 비전을 발전시키는 것입니다.
- 개발을 안내하는 원칙이 있고 이러한 지침에서 파생된 관행이 개발자에게 고통을 주지 않는지 확인하십시오.
- 새로운 기술을 지속적으로 이해하고 절충(즉, (원칙/비전) 진화)해야 할 때를 안내해야 합니다.
- 개발 동료들도 이러한 결정과 장단점을 이해하고 구현하도록 하십시오.
- 내린 결정이 팀에 어떤 영향을 미치는지 이해하려면 팀, 심지어 코드와도 협력해야 합니다.
일반적으로 거버넌스는 소규모 팀과의 비공식적인 대화에서 대규모로 논의가 가능한 본격적인 그룹과의 공식 정기 회의에 이르기까지 그룹 활동입니다. 위에서 언급한 원칙은 다음과 같은 경우에도 수정될 수 있습니다. 필요한. 물론 회의는 기술 전문가가 주도하고 일선 개발자가 참여해야 합니다. 전체 그룹은 기술적 위험을 추적하고 관리할 지속적인 책임을 져야 합니다.
때때로 리더는 그룹이 내린 결정에 동의하지 않을 수 있습니다. 이 때 해야 할 일은 무엇입니까? 저자는 집단이 보통 한 사람보다 똑똑하기 때문에 집단의 결정에 대부분 동의하고, 집단에게 결정을 내릴 수 있는 권한을 주지만 결국 이 결정을 무시하고 집단이 무의미하다.
필요한 경우 리더는 그룹에 영향력을 행사해야 하며 언제 무엇을 할 수 있고 무엇을 할 수 없는지 명시해야 합니다.
7. 팀 구성
저자의 말을 인용하자면:
시스템의 기술적 비전을 담당하는 책임자에게 비전을 실행하는 것은 기술적 결정을 내리는 것과 동일하지 않으며 함께 일하는 사람들이 자연스럽게 이러한 결정을 내릴 것입니다.
기술 리더에게 더 중요한 것은 팀원이 성장하고 비전을 이해하도록 돕고 비전의 실현과 조정에 적극적으로 참여할 수 있도록 하는 것입니다.
단일 애플리케이션 시스템에서 개발자는 특정 사항을 책임질 수 있는 기회가 매우 제한적인 반면, 마이크로서비스 아키텍처에는 각각 고유한 독립 명령문 주기가 있는 여러 자율 코드 기반이 있어 더 많은 사람에게 책임을 질 수 있는 기회를 제공합니다. 이 사람들이 단일 서비스에 대해 충분히 교육을 받으면 더 많은 책임을 부여받을 수 있으므로 점차 경력 목표를 달성하는 데 도움이 되는 동시에 책임을 분담함으로써 특정 남자가 과부하.
저는 훌륭한 소프트웨어는 훌륭한 사람들에게서 나온다고 굳게 믿습니다. 따라서 기술적인 문제만 걱정한다면 문제의 절반도 안 되는 것을 보게 될 것입니다.