Dodo IS 아키텍처의 역사: 백 오피스 경로

Habr은 세상을 바꾸고 있습니다. 우리는 이제 XNUMX년 넘게 블로그를 운영하고 있습니다. 약 XNUMX개월 전에 우리는 Khabrovites로부터 완전히 논리적인 피드백을 받았습니다. 이 시스템은 무엇입니까? 피자 체인점에 왜 필요한가요?

우리는 당신이 옳다는 것을 앉아서 생각하고 깨달았습니다. 우리는 손가락으로 모든 것을 설명하려고 노력하지만 그것은 찢어진 조각으로 나오고 시스템에 대한 완전한 설명은 어디에도 없습니다. 그리하여 정보를 수집하고 저자를 찾고 Dodo IS에 대한 일련의 기사를 작성하는 긴 여정이 시작되었습니다. 갑시다!

감사의 말: 피드백을 공유해 주셔서 감사합니다. 그 덕분에 우리는 마침내 시스템을 설명하고 기술 레이더를 컴파일했으며 곧 우리 프로세스에 대한 자세한 설명을 발표할 것입니다. 당신이 없었다면 우리는 5년을 더 거기에 앉아 있었을 것입니다.

일련의 기사 "Dodo IS는 무엇입니까?" 다음에 대해 알려줍니다.

1. Dodo IS의 초기 단일체(2011-2015). (진행중...)
2. 백 오피스 경로: 별도의 기지와 버스. (당신은 여기)
3. 클라이언트 쪽 경로: 베이스 위의 정면(2016-2017). (진행중...)
4. 진정한 마이크로서비스의 역사. (2018-2019). (진행중...)
5. 모놀리스 톱질 완료 및 아키텍처 안정화. (진행중...)

다른 것을 알고 싶다면 의견을 작성하십시오.

저자의 연대순 설명에 대한 의견
저는 "시스템 아키텍처"라는 주제로 신입 사원 회의를 정기적으로 개최합니다. 우리는 이것을 "Intro to Dodo IS Architecture"라고 부르며 새로운 개발자를 위한 온보딩 프로세스의 일부입니다. 우리의 건축과 그 특징에 대해 어떤 형태로든 이야기하면서 나는 설명에 대한 특정한 역사적 접근 방식을 탄생시켰습니다.

전통적으로 우리는 시스템을 일부 목표를 달성하기 위해 서로 상호 작용하는 비즈니스 모듈인 구성 요소 집합(기술적 수준 또는 상위 수준)으로 간주합니다. 그리고 그러한 견해가 설계를 위해 정당화된다면 그것은 설명과 이해에 적합하지 않습니다. 여기에는 몇 가지 이유가 있습니다.

• 현실은 종이에 적힌 것과 다릅니다. 모든 것이 의도한 대로 되지는 않습니다. 그리고 우리는 그것이 실제로 어떻게 나타났고 작동하는지에 관심이 있습니다.
• 일관된 정보 제공. 실제로 처음부터 현재 상태까지 연대순으로 갈 수 있습니다.
• 단순한 것에서 복잡한 것까지. 보편적이지는 않지만 우리의 경우에는 그렇습니다. 아키텍처는 단순한 접근 방식에서 보다 복잡한 접근 방식으로 이동했습니다. 종종 복잡함을 통해 구현 속도 및 안정성 문제와 비기능적 요구 사항 목록의 수십 가지 다른 속성이 해결되었습니다.여기에 다른 요구 사항과 대조되는 복잡성에 대해 잘 설명되어 있음).

2011년 Dodo IS 아키텍처는 다음과 같았습니다.

2020년에는 좀 더 복잡해져서 다음과 같이 되었습니다.

이 진화는 어떻게 일어 났습니까? 시스템의 다른 부분이 필요한 이유는 무엇입니까? 어떤 아키텍처 결정이 내려졌고 그 이유는 무엇입니까? 이 기사 시리즈에서 알아봅시다.

2016년의 첫 번째 문제: 서비스가 모놀리스를 떠나야 하는 이유

주기의 첫 번째 기사는 모놀리스에서 처음으로 분리된 서비스에 관한 것입니다. 상황을 이해하기 위해 2016년 초까지 시스템에 어떤 문제가 있었고 서비스 분리를 ​​처리해야 했는지 말씀드리겠습니다.

당시 Dodo IS에 존재했던 모든 애플리케이션이 기록을 작성한 단일 MySql 데이터베이스. 결과는 다음과 같습니다.

• 로드가 많습니다(요청의 85%가 읽기를 차지함).
• 기반이 성장했습니다. 이 때문에 비용과 지원이 문제가 됐다.
• 단일 실패 지점. 데이터베이스에 쓰는 한 응용 프로그램이 갑자기 더 적극적으로 작업을 시작하면 다른 응용 프로그램이 스스로 그것을 느꼈습니다.
• 스토리지 및 쿼리의 비효율성. 종종 데이터는 일부 시나리오에는 편리하지만 다른 시나리오에는 적합하지 않은 구조로 저장되었습니다. 인덱스는 일부 작업의 속도를 높이지만 다른 작업의 속도를 늦출 수 있습니다.
• 급하게 만든 캐시와 읽기 전용 복제본을 기지에 설치하여 일부 문제를 제거했지만(별도의 기사가 될 것임) 시간을 벌 수만 있었고 근본적으로 문제를 해결하지 못했습니다.

문제는 모놀리스 자체의 존재였다.. 결과는 다음과 같습니다.

• 단일 및 희귀 릴리스.
• 다수의 인원이 공동으로 개발하기 어려움.
• 새로운 기술, 새로운 프레임워크 및 라이브러리를 가져올 수 없습니다.

예를 들어 2018년 초 충돌의 맥락에서 베이스와 모놀리스의 문제가 여러 번 설명되었습니다.Munch처럼 되십시오. 또는 기술 부채에 대한 몇 마디, Dodo IS가 멈춘 날. 비동기 스크립트 и 불사조 가족의 Dodo 새 이야기. Dodo IS의 대몰락), 그래서 나는 너무 많이 머 무르지 않을 것입니다. 서비스를 개발할 때 더 많은 유연성을 제공하고 싶었습니다. 우선, 이것은 전체 시스템에서 가장 많이 로드되고 루트인 Auth 및 Tracker에 관한 것입니다.

백오피스 경로: 베이스와 버스 분리

장 탐색

1. 모놀리식 방식 2016
2. 모노리스 언로드 시작: 인증 및 추적기 분리
   
3. 인증은 무엇을 합니까?
4. 짐은 어디에서 왔습니까?
5. 승인 언로드
6. 트래커는 무엇을 하나요?
7. 짐은 어디에서 왔습니까?
8. 언로드 트래커

모놀리식 방식 2016

다음은 Dodo IS 2016 모노리스의 주요 블록이며, 바로 아래는 주요 작업에 대한 기록입니다.

출납원 배달. 택배 회계, 택배 주문 발행.
컨택 센터. 운영자를 통한 주문 수락.
사이트. 당사 웹사이트(dodopizza.ru, dodopizza.co.uk, dodopizza.by 등).
인증. 백 오피스에 대한 권한 및 인증 서비스입니다.
추적기. 부엌에서 주문 추적기. 주문을 준비할 때 준비 상태를 표시하는 서비스입니다.
레스토랑의 계산대. 레스토랑, 출납원 인터페이스에서 주문을 받습니다.
수출. 회계를 위해 1C로 보고서 업로드.
알림 및 송장. 주방의 음성 명령(예: "새 피자 도착") + 택배를 위한 송장 인쇄.
교대조 관리인. 교대 근무 관리자의 작업 인터페이스: 주문 목록, 성과 그래프, 직원을 교대 근무로 이동.
사무실 관리자. 가맹점주와 관리자의 작업을 위한 인터페이스: 직원 접수, 피자가게 작업 보고.
레스토랑 스코어보드. 피자가게의 TV에 메뉴가 표시됩니다.
관리자. 특정 피자 가게의 설정: 메뉴, 가격, 회계, 프로모션 코드, 프로모션, 웹사이트 배너 등
직원의 개인 계정. 직원의 작업 일정, 직원에 대한 정보.
주방 동기 부여 보드. 주방에 걸려있는 별도의 화면으로 피자 메이커의 속도를 표시합니다.
의사 소통. SMS 및 이메일 보내기.
파일저장. 정적 파일 수신 및 발행을 위한 자체 서비스.

문제를 해결하려는 첫 번째 시도는 우리에게 도움이 되었지만 일시적인 유예에 불과했습니다. 그것들은 시스템 솔루션이 되지 않았기 때문에 기지에서 무언가를 해야 한다는 것이 분명했습니다. 예를 들어, 일반 데이터베이스를 몇 가지 더 전문화된 데이터베이스로 나누기 위해.

모노리스 언로드 시작: 인증 및 추적기 분리

그런 다음 다른 것보다 더 많이 데이터베이스에서 기록하고 읽는 주요 서비스:

1. 인증 백 오피스에 대한 권한 및 인증 서비스입니다.
2. 트래커. 부엌에서 주문 추적기. 주문을 준비할 때 준비 상태를 표시하는 서비스입니다.

인증은 무엇을 합니까?

인증은 사용자가 백오피스에 로그인하는 서비스입니다(클라이언트 측에 별도의 독립 입구가 있음). 또한 필요한 액세스 권한이 있고 이러한 권한이 마지막 로그인 이후 변경되지 않았는지 확인하기 위해 요청 시 호출됩니다. 이를 통해 장치가 피자 가게에 들어갑니다.

예를 들어 홀에 걸려 있는 TV에 완료된 주문 상태가 있는 디스플레이를 열고 싶습니다. 그런 다음 auth.dodopizza.ru를 열고 "장치로 로그인"을 선택하면 교대 관리자 컴퓨터의 특수 페이지에 입력할 수 있는 코드가 나타나 장치 유형(장치)을 나타냅니다. TV 자체가 피자 가게의 원하는 인터페이스로 전환되고 주문이 준비된 고객의 이름을 표시하기 시작합니다.

짐은 어디에서 왔습니까?

백오피스에 로그인한 각 사용자는 데이터베이스로 이동하여 각 요청에 대한 사용자 테이블로 이동하고 SQL 쿼리를 통해 사용자를 끌어내어 이 페이지에 필요한 액세스 및 권한이 있는지 확인합니다.

각 장치는 역할과 액세스를 확인하면서 장치 테이블에 대해서만 동일한 작업을 수행합니다. 마스터 데이터베이스에 대한 많은 수의 요청은 이러한 작업을 위한 공통 데이터베이스의 로드 및 리소스 낭비로 이어집니다.

승인 언로드

인증에는 격리된 도메인이 있습니다. 즉, 사용자, 로그인 또는 장치에 대한 데이터가 서비스에 들어가고(당분간) 그대로 유지됩니다. 누군가 필요한 경우 데이터를 위해 이 서비스로 이동합니다.

였다. 원래 작업 계획은 다음과 같습니다.

작동 방식을 조금 설명하고 싶습니다.

1. 외부로부터의 요청이 백엔드(Asp.Net MVC가 있음)로 와서 Redis(1)에서 세션 데이터를 가져오는 데 사용되는 세션 쿠키를 가져옵니다. 여기에는 액세스에 대한 정보가 포함되어 있고 컨트롤러에 대한 액세스가 열려 있는지(3,4) 여부가 있습니다.
2. 접근 권한이 없을 경우 권한 부여 절차를 거쳐야 합니다. 여기서는 단순성을 위해 로그인 페이지로의 전환이지만 동일한 속성에서 경로의 일부로 표시됩니다. 긍정적인 시나리오의 경우 올바르게 완료된 세션을 받고 백오피스 컨트롤러로 이동합니다.
3. 데이터가 있는 경우 사용자 기반에서 관련성을 확인해야 합니다. 그의 역할이 바뀌었습니까? 이제 페이지에 허용되지 않아야 합니까? 이 경우 세션을 받은 후(1) 직접 데이터베이스로 이동하여 인증 논리 계층을 사용하여 사용자의 액세스를 확인해야 합니다(2). 그런 다음 로그인 페이지로 이동하거나 컨트롤러로 이동하십시오. 이러한 간단한 시스템이지만 표준은 아닙니다.
4. 모든 절차가 통과되면 컨트롤러 및 메서드의 논리에서 더 이상 건너뜁니다.

사용자 데이터는 다른 모든 데이터와 분리되어 별도의 멤버십 테이블에 저장되며 AuthService 논리 계층의 함수는 api 메서드가 될 수 있습니다. 도메인 경계는 사용자, 역할, 액세스 데이터, 액세스 권한 부여 및 취소와 같이 매우 명확하게 정의됩니다. 모든 것이 별도의 서비스로 꺼낼 수 있도록 보입니다.

이 되다. 그래서 그들은 다음과 같이 했습니다.

이 접근 방식에는 여러 가지 문제가 있습니다. 예를 들어 프로세스 내부에서 메서드를 호출하는 것은 http를 통해 외부 서비스를 호출하는 것과 다릅니다. 대기 시간, 신뢰성, 유지 보수성, 운영 투명성은 완전히 다릅니다. Andrey Morevskiy는 그의 보고서에서 이러한 문제에 대해 더 자세히 설명했습니다. "마이크로서비스의 50가지 그림자".

인증 서비스와 장치 서비스는 백오피스, 즉 프로덕션에서 사용되는 서비스 및 인터페이스에 사용됩니다. 웹사이트 또는 모바일 애플리케이션과 같은 클라이언트 서비스에 대한 인증은 Auth를 사용하지 않고 별도로 발생합니다. 분리에는 약 XNUMX년이 걸렸으며 이제 우리는 이 주제를 다시 다루면서 시스템을 새로운 인증 서비스(표준 프로토콜 사용)로 이전하고 있습니다.

이별이 왜 그렇게 오래 걸렸습니까?
그 과정에서 속도를 늦추는 많은 문제가 있었습니다.

1. 우리는 국가별 데이터베이스의 사용자, 장치 및 인증 데이터를 하나로 옮기고 싶었습니다. 이를 위해 int 식별자에서 전역 UUId 식별자로 모든 테이블과 사용법을 변환해야 했습니다(최근에 이 코드를 재작업했습니다). 로만 부킨 "Uuid - 작은 구조물의 큰 이야기" 그리고 오픈소스 프로젝트 프리미티브). 사용자 데이터(개인 정보이므로) 저장에는 한계가 있으며 일부 국가에서는 별도로 저장해야 합니다. 그러나 사용자의 전역 ID는 반드시 있어야 합니다.
2. 데이터베이스의 많은 테이블에는 작업을 수행한 사용자에 대한 감사 정보가 있습니다. 이를 위해서는 일관성을 위한 추가 메커니즘이 필요했습니다.
3. api 서비스를 만든 후 다른 시스템으로 전환하는 길고 점진적인 기간이 있었습니다. 전환은 사용자에게 매끄럽고 수작업이 필요했습니다.

피자 가게의 장치 등록 체계:

인증 및 장치 서비스 추출 후 일반 아키텍처:

주의. 2020년에는 OAuth 2.0 인증 표준을 기반으로 하는 새로운 인증 버전을 개발하고 있습니다. 이 표준은 상당히 복잡하지만 통과 인증 서비스를 개발하는 데 유용합니다. 기사에서 "인증의 미묘함: OAuth 2.0 기술 개요» 우리는 Alexey Chernyaev가 표준에 대해 가능한 한 간단하고 명확하게 설명하여 학습 시간을 절약할 수 있도록 노력했습니다.

트래커는 무엇을 하나요?

이제 로드된 서비스 중 두 번째에 대해 설명합니다. 추적기는 이중 역할을 수행합니다.

• 한편으로 그 임무는 현재 작업 중인 주문이 무엇인지, 지금 요리해야 하는 제품이 무엇인지 주방 직원들에게 보여주는 것입니다.
• 한편, 주방의 모든 프로세스를 디지털화합니다.

새 제품이 주문에 표시되면(예: 피자) 출시 추적기 스테이션으로 이동합니다. 이 스테이션에는 필요한 크기의 롤빵을 펴서 펴는 피자 메이커가 있습니다. 그 후 그는 추적기 태블릿에 자신의 작업을 완료했음을 기록하고 롤 반죽 베이스를 다음 스테이션인 "시작"으로 옮깁니다. .

그곳에서 다음 피자 메이커가 피자를 채우고 작업을 완료했다고 태블릿에 메모하고 피자를 오븐에 넣습니다(이것은 태블릿에 기록해야 하는 별도의 스테이션이기도 합니다). 이러한 시스템은 Dodo의 초기부터 Dodo IS의 존재 초기부터 있었습니다. 모든 트랜잭션을 완전히 추적하고 디지털화할 수 있습니다. 또한 트래커는 특정 제품을 요리하는 방법을 제안하고, 제조 방식에 따라 각 유형의 제품을 안내하고, 제품에 대한 최적의 조리 시간을 저장하고, 제품에 대한 모든 작업을 추적합니다.

이것은 추적기 "Raskatka"의 스테이션에서 태블릿 화면이 어떻게 보이는지입니다.

짐은 어디에서 왔습니까?

각 피자 가게에는 추적기가 있는 약 2016개의 태블릿이 있습니다. 100년에는 600개 이상의 피자 가게가 있었습니다(현재 10개 이상). 각각의 태블릿은 XNUMX초에 한 번씩 백엔드에 요청하고 주문 테이블(클라이언트 및 주소 연결), 주문 구성(제품 연결 및 수량 표시), 동기 회계 테이블( 누르는 시간이 추적됩니다). 피자 메이커가 추적기에서 제품을 클릭하면 이 모든 테이블의 항목이 업데이트됩니다. 주문 테이블은 일반적이며 주문 수락시 삽입, 시스템의 다른 부분에서 업데이트 및 피자 가게에 걸려있는 TV에서 고객에게 완료된 주문을 보여주는 것과 같은 수많은 판독 값을 포함합니다.

부하와 싸우는 기간 동안 모든 것이 캐시되고 기본의 비동기 복제본으로 전송되었을 때 추적기를 사용한 이러한 작업은 계속해서 마스터 기본으로 이동했습니다. 지연이 없어야 하고 데이터가 최신 상태여야 하며 동기화되지 않은 것은 허용되지 않습니다.

또한 자체 테이블과 인덱스가 없기 때문에 용도에 맞는 보다 구체적인 쿼리를 작성할 수 없었습니다. 예를 들어 추적기가 주문 테이블에 피자 가게에 대한 인덱스를 갖는 것이 효율적일 수 있습니다. 우리는 항상 트래커 데이터베이스에서 피자 가게 주문을 제거합니다. 동시에 주문을 받기 위해 어떤 피자 가게에 속하는지는 그다지 중요하지 않으며 어떤 고객이이 주문을했는지가 더 중요합니다. 그리고 클라이언트의 인덱스가 필요하다는 것을 의미합니다. 추적기가 주문 테이블의 주문과 관련된 인쇄된 영수증 또는 보너스 프로모션의 ID를 저장할 필요도 없습니다. 이 정보는 추적기 서비스에 관심이 없습니다. 일반적인 모놀리식 데이터베이스에서 테이블은 모든 사용자 간의 절충안일 뿐입니다. 이것은 원래 문제 중 하나였습니다.

였다. 원래 아키텍처는 다음과 같습니다.

별도의 프로세스로 분리된 후에도 대부분의 코드 기반은 서로 다른 서비스에서 공통으로 유지되었습니다. 컨트롤러 아래의 모든 것은 단일이며 동일한 리포지토리에 있습니다. 우리는 공통 테이블이 놓인 공통 기반 인 서비스, 리포지토리, 공통 기반을 사용했습니다.

언로드 트래커

트래커의 주요 문제는 데이터가 서로 다른 데이터베이스 간에 동기화되어야 한다는 것입니다. 이는 인증 서비스 분리와 주요 차이점이기도 합니다. 순서와 상태는 변경될 수 있으며 다른 서비스에 표시되어야 합니다.

레스토랑 계산대에서 주문을 수락하면(이것은 서비스입니다) 데이터베이스에 "승인됨" 상태로 저장됩니다. 그 후 그는 추적기로 이동하여 "Kitchen"에서 "Packed"로 상태를 여러 번 변경합니다. 동시에 출납원 또는 교대 근무 관리자 인터페이스의 일부 외부 영향이 주문과 함께 발생할 수 있습니다. 테이블에 설명과 함께 주문 상태를 제공합니다.

주문 상태 변경 체계는 다음과 같습니다.

상태는 서로 다른 시스템 간에 변경됩니다. 그리고 여기서 트래커는 데이터가 닫히는 최종 시스템이 아닙니다. 이러한 경우 파티셔닝에 대한 몇 가지 가능한 접근 방식을 보았습니다.

1. 우리는 모든 주문 작업을 하나의 서비스에 집중합니다. 우리의 경우 이 옵션은 주문을 처리하기 위해 너무 많은 서비스가 필요합니다. 여기서 멈추면 두 번째 모놀리스를 얻을 수 있습니다. 우리는 문제를 해결하지 않을 것입니다.
2. 한 시스템이 다른 시스템을 호출합니다. 두 번째 옵션은 이미 더 흥미 롭습니다. 그러나 이를 통해 일련의 호출이 가능합니다(계단식 실패) 구성 요소의 연결성이 높을수록 관리하기가 더 어렵습니다.
3. 우리는 이벤트를 주최하고 각 서비스는 이러한 이벤트를 통해 서로 소통합니다. 결과적으로 모든 서비스가 서로 이벤트를 교환하기 시작하는 세 번째 옵션이 선택되었습니다.

우리가 세 번째 옵션을 선택했다는 사실은 트래커가 자체 데이터베이스를 가지며 주문이 변경될 때마다 이에 대한 이벤트를 보내 다른 서비스가 구독하고 마스터 데이터베이스에도 포함된다는 것을 의미합니다. 이를 위해 서비스 간 메시지 전달을 보장하는 서비스가 필요했습니다.

그때까지 우리는 스택에 이미 RabbitMQ가 있었기 때문에 이를 메시지 브로커로 사용하기로 최종 결정했습니다. 다이어그램은 레스토랑 캐셔에서 트래커를 통한 주문 전환을 보여줍니다. 여기에서 주문 상태가 변경되고 관리자의 주문 인터페이스에 표시됩니다. 강철:

경로를 단계별로 주문
주문 경로는 주문 소스 서비스 중 하나에서 시작됩니다. 다음은 레스토랑 계산원입니다.

1. 결제 시 주문이 완전히 준비되었으며 추적기로 보낼 시간입니다. 트래커가 구독하는 이벤트가 발생합니다.
2. 자체적으로 주문을 수락하는 추적기는 이를 자체 데이터베이스에 저장하고 "추적자가 수락한 주문" 이벤트를 만들고 RMQ로 보냅니다.
3. 주문당 이벤트 버스에 이미 등록된 여러 핸들러가 있습니다. 우리에게는 모 놀리 식 기반과 동기화하는 것이 중요합니다.
4. 핸들러는 이벤트를 수신하고 이벤트에서 중요한 데이터를 선택합니다. 우리의 경우 이것은 "추적자가 수락함" 주문의 상태이며 기본 데이터베이스에서 주문 엔터티를 업데이트합니다.

누군가 모놀리식 테이블 주문의 주문이 필요한 경우 거기에서도 읽을 수 있습니다. 예를 들어 교대 근무 관리자의 주문 인터페이스에는 다음이 필요합니다.

다른 모든 서비스는 트래커의 주문 이벤트를 구독하여 자체적으로 사용할 수도 있습니다.

잠시 후 주문이 처리되면 데이터베이스(Tracker 데이터베이스)에서 상태가 먼저 변경된 다음 "OrderIn Progress" 이벤트가 즉시 생성됩니다. 또한 모놀리식 데이터베이스에서 동기화되고 다른 서비스로 전달되는 RMQ에 들어갑니다. 도중에 다양한 문제가 있을 수 있으며 이에 대한 자세한 내용은 Zhenya Peshkov의 보고서에서 확인할 수 있습니다. 추적기의 최종 일관성 구현 세부 정보에 대해.

Auth 및 Tracker 변경 후 최종 아키텍처

중간 결과 요약: 처음에는 Dodo IS 시스템의 XNUMX년 역사를 하나의 기사로 묶을 생각이었습니다. 나는 진화의 단계에 대해 빠르고 간단하게 이야기하고 싶었습니다. 그러나 자료에 앉아 모든 것이 생각보다 훨씬 복잡하고 흥미 롭다는 것을 깨달았습니다.

그러한 자료의 이점 (또는 부족함)을 반영하여 본격적인 사건 연대기, 상세한 회고 및 과거 결정 분석 없이는 지속적인 개발이 불가능하다는 결론에 도달했습니다.

우리의 길에 대해 배우는 것이 유용하고 흥미로웠기를 바랍니다. 이제 저는 다음 기사에서 설명할 Dodo IS 시스템의 일부를 선택해야 합니다. 의견을 작성하거나 투표하십시오.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

다음 기사에서 Dodo IS의 어떤 부분에 대해 알고 싶습니까?

• 24,1%Dodo IS의 초기 단일체(2011-2015)14

• 24,1%첫 번째 문제 및 해결 방법(2015-2016)14

• 20,7%클라이언트 측 경로: 기본(2016-2017)12

• 36,2%진정한 마이크로서비스의 역사(2018-2019)21

• 44,8%모놀리스의 완전한 톱질 및 아키텍처의 안정화26

• 29,3%시스템 개발을 위한 추가 계획 정보17

• 19,0%Dodo IS11에 대해 아무것도 알고 싶지 않습니다.

58명의 사용자가 투표했습니다. 6명의 사용자가 기권했습니다.

출처 : habr.com