Lifeway의 이벤트 구동 구조

이미 2016년에 라이프웨이는 백엔드 전자상거래 플랫폼 전체를 재구축하는 거대한 도전을 맡았다.우리는 웹 Sphere 기반의 단일 시스템에서 이벤트 구동의 마이크로 서비스 방법으로 바뀌었다. Apache Kafka와 Kubernetes는 우리 기업의 지주이다.이 목표를 실현하는 길은 완벽하지 않다. 우리는 이 과정에서 많은 실수를 저질렀지만 최종 결과는 우리 개발진이 장기적으로 성공을 거두게 했다.이 글에서 우리는 우리가 실현한 체계 구조, 우리가 실현 과정에서 직면한 도전, 그것이 오늘의 개발팀에 어떻게 영향을 미쳤는지, 그리고 Lifeway가 미래를 위해 무엇을 준비하고 있는지 되돌아볼 것이다.

건축하다

이 제안의 핵심은 다음과 같습니다.

신축성

비동기적인 이벤트를 이용하여 업무 영역 간의 통합을 통해 플랫폼의 전체적인 탄력성이 현저히 높아질 것으로 예상된다.

확장성

클라우드를 포용하고 우리 자신의 데이터 센터를 이전함으로써 우리는 더욱 유연하게 업무 수요와 고객 수를 확장할 수 있기를 희망한다.

긴밀한 결합을 없애다

기능을 마이크로 서비스로 분리함으로써 사람들은 업무 영역이 더 이상 긴밀하게 결합되지 않기를 기대한다. 생산 사건이 고객에게 미치는 영향을 제한하고 더욱 우아한 용착을 허용한다.

진화 건축

통용되는 인터페이스와 디자인 범례가 있기 때문에 우리는 이 체계 구조 위에서 쉽게 교체할 수 있기를 바란다.모든 새로운 대규모 기능은 사건에서 가장 작은 단원으로 추출되고 민첩함과 최소한의 중단으로 이루어져야 한다.

그림에서 보듯이 우리는 이전에 결합된 업무 영역(집중된 인프라 시설에 위탁 관리)을 단독 관리의 논리 구성 요소로 분리한다.카프카는 그 후에 이 지역에서 통신하는 비동기적인 방식으로 도입되었다.카프카가 도입됨에 따라 우리는 기업 활동 봉투를 세웠다.본질적으로, 이것은 모든 응용 프로그램이 다른 지역에 이벤트를 발표하고 소비할 때 반드시 준수해야 하는 계약이다.

{
  "id": "4118ca5c-2d28-4ebd-90ca-66eb2ede7314",
  "timestamp": "2021-02-27T16:31:23.885Z",
  "version": 1,
  "payload": {
    "id": "b9b1b8eb-a9a5-4880-a444-fd26a8cda03e",
    "dateCreated": "2021-02-27T16:31:23.885Z",
    "dateUpdated": "2021-02-27T16:31:23.885Z",
    "firstName": "Leeroy",
    "lastName": "Jenkins",
    "gender": "MALE"
  },
  "eventType": "PersonCreated",
  "domain": "Customer"
}

위의 예시 사건은 이 사건 봉투를 보여 주었다.이런 방식을 사용하면 응용 프로그램은 헤더 단계에서 필요한 루트 정보와 통신하고 유효 부하 단계에서 특정한 응용 프로그램의 데이터와 통신할 수 있다.
이러한 "사건"의 가장 중요한 측면은 eventType과payload입니다.이로써 우리는 업무 절차에서 어떤 일이 발생할 때 충분한 통신을 해서 다른 시스템이 그 지역의 상하문을 바탕으로 소비와 처리를 할 수 있도록 할 수 있다.위의 예에서 우리는 등록이나 다른 방식으로 새로운 고객을 만들었다는 PersonCreated 이벤트가 있다.
이 범례에서 우리의 모든 해결 방안은 정보를 기업에 전파하는 표준적인 방식을 가지고 있다.

투쟁하다

이상하게도 이렇게 숭고한 목표는 상당히 심각한 성장 고통을 수반한다.가장 주목할 점은 다음과 같습니다.

마이크로 서비스의 복잡성

우리가 우리의 능력을 하나의 구성 요소로 분해할 때 시스템과 인프라 시설의 복잡성은 자연히 크게 증가할 것이다.초기 단계에 우리는 파이프라인을 구축하고 전략을 배치하기 어려웠으며, 때로는 문제를 충분히 조정하기 어려웠다.시간의 흐름에 따라 우리는 K8s, 로그 집합기, 재사용 가능한 파이프 등 도구를 사용하여 이 과정을 간소화하는 데 도움을 주었다.우리는 또한 내부 개발 문서의 중요성을 강조해야 한다.

잠복기

더 많은 구성 요소, 이중화된 API 게이트웨이 및 기능을 도입함에 따라 엔드 유저에게 불필요한 지연 시간을 제공하는 최초의 아키텍처를 알아봤습니다.우리가 알고 있는 바와 같이, 우리는 이러한 불필요한 API 게이트웨이 층을 없애고, 가능한 한 기능을 다시 설계하여 지연을 줄이고 있다.

데이터 센터 종속성

비록 우리는 대부분의 기업을 단일한 체계 구조에서 옮기지만, 우리는 여전히 남아 있는 Oracle 실현을 통해 주문, 회계, 총결산의 이행을 유지한다.따라서 Google 네트워크는 Google 클라우드 인프라에 의존하여 AWS Direct connect를 통해 Google CoLo 데이터 센터를 연결할 수 있습니다.Kafka를 사용하여 연결된 구성 요소와 특정한 페일오버 절차를 분리하고, 직접 연결에 여분을 추가함으로써 이러한 상황을 완화합니다.

수익

우리가 이러한 성장 중의 난제를 해결했을 때 이러한 구조 결정은 우리 개발팀의 문화와 능력에 커다란 영향을 미쳤을 뿐만 아니라 우리 시스템을 어떻게 개선했는지에도 큰 영향을 미쳤다.우리는 모든 해결 방안에 동질 인터페이스를 제공하여 그들이 도구를 제한하거나 제한하는 것이 아니라 독립적으로 조작하고 팀의 장점에 따라 속도를 높일 수 있도록 한다.예를 들어, JVM(Scala, Kotlin, Java)을 사용하는 팀이 있고 다른 팀은 Node를 사용합니다.js, Typescript, Javascript는 모두 전용입니다.이런 구조의 모듈화는 우리 개발팀의 다양성을 장려하고 현저한 혁신을 가져왔다.
그 밖에 Lifeway의 업무는 더욱 디지털화된 교회를 지원하기 위해 발전을 모색하고 있기 때문에 우리는 믿을 수 없는 유연성을 가지고 있다.몇 가지 예는 다음과 같습니다.

Lifeway Reader

Online Bible Studies

Buy and Share for Videos and Ebooks

미래.

우리는 미래의 발전을 위해 양호한 기초를 다졌다.그래서 라이프웨이가 앞으로 2년 동안 구조적으로 무엇을 개선하고 싶은지 물어볼 이유가 있다.우리는 혁신을 영원히 멈추고 싶지 않다. 재구성을 영원히 멈추고 싶지 않다. 라이프웨이의 신흥 기술과 구조의 맥락을 영원히 잡고 싶다.
이를 감안하여 Lifeway는 무두 내용 관리가 기업 범위 내에서의 응용을 평가하고 있다. 왜냐하면 우리는 점점 더 많은 대형 전자상거래 회사들이 이 방향으로 발전하고 MACH Alliance운동과 일치하는 것을 발견했기 때문이다.우리는 전자상거래 체험에 필요한 플랫폼을 가지고 있으며, 현재 우리는 전방에서 내용과 고객의 여정을 전달하는 방식을 강화해야 한다.