웨이크서비스부터 시작해.마이크로 서비스부터 시작하지 마세요.

이 글의 제목은 매우 모순적이다.
나는 두 가지 이야기를 하고 싶다.하나는'웨이크서비스부터 시작하지 마라', 하나는'웨이크서비스부터 시작해라'다.나는 이 두 가지 측면에서 볼 때, 우리는 마이크로 서비스의 실제 장점을 더욱 많이 이해할 것이라고 믿는다.
그럼 시작합시다.

마이크로 서비스부터 시작하지 마세요.

상상해 보아라, 너는 대형 전자상거래 플랫폼을 위해 일하고 있다.모든 전자상거래 플랫폼과 마찬가지로 모든 제품을 표시하는 제품 목록 페이지가 있다.카트와 결제 과정을 처리하는 데 사용되는 결제 페이지도 있다.


오래 전에, 이 회사의 수석 기술관인 존은 마이크로 서비스에 관한 책을 읽었다.존은 이것이 좋은 생각이라고 생각한다.그래서 존은 제품 목록 구역과 쇼핑 카트 구역을 담당하는 마이크로 서비스를 가지기로 결정했다.
마이크로 서비스 체계 구조는 John이 하나의 제품 목록 팀과 하나의 계산 팀을 가지도록 허용한다.이들은 모두 각자의 업무 목표, 지표, KPI, SLA 등을 가지고 있다.이 두 팀은 모두 직능을 뛰어넘는 팀으로 제품 목록 페이지와 철저한 계산 절차를 책임진다.
그들 모두는 자기가 하고 싶은 일을 마음대로 할 수 있다.예를 들어 checkout팀은 여러 개의 로컬화와 좋은 휴일 테마를 포함하는 AB 테스트를 실현할 수 있다.제품 팀은 관련 프로젝트를 제안함으로써 제품 목록 최적화에 전념할 수 있다.역간 API 통신의 향후 호환성을 유지하기만 한다면, 그들은 모두 자신의 영역에 전념할 수 있으며, 다른 분야에 대한 돌파적인 변경을 걱정할 필요가 없다.
그 밖에 우리는 시스템을 부분적으로 확장할 수 있다.만약 우리가 금요일에 판촉 활동을 한다면 고객은 더 많은 제품과 판촉 활동을 조회할 것이다.우리는 더 큰 제품 목록 백엔드와 더 큰 결제 페이지가 필요할 수도 있습니다.
완벽해. 괜찮아.생활은 아름답다.
내년에 최고경영자 제인은 판촉 활동을 한 번 하려고 한다.제인은 또 일부 연구에서 로그인 페이지와 결제 과정에서 관련 제품을 보여주면 매출을 획기적으로 높일 수 있다는 사실을 밝혀냈다.


일부 특정 가격 체계, 종속성(IT 관련 제품을 많이 구매하는 고객은 IT 제품에서 더 많은 할인을 받을 수 있음) 및 고객 특권 범주가 있습니다.이것들은 제품 리스트 팀에서 관리해야 한다. 왜냐하면 그들은 이미 관련 매력적인 제품을 어떻게 전시하는지에 대해 대량의 연구를 진행했기 때문이다.그 밖에 제품 리스트팀은 어떻게 사람을 끌어당기는 방식으로 제품을 전시하는지 정확히 알고 있다.그들은 어떤 색, 글꼴, 이미지 크기, 간격이 가장 좋은 전환율을 낼 수 있는지 정확히 알고 있다.
그러나 이런 변화는 어려울 것이다.
결제 절차와 제품 페이지의 백엔드와 전단은 서로 다른 마이크로 서비스에 속하기 때문에 우리는 두 팀 간에 코드, 디자인, 논리 등을 공유해야 한다.우리는 간단한 복사와 붙여넣기를 할 수 있고, 공유 라이브러리를 만들 수 있으며, 어떤 API를 공개할 수 있다.
이런 것들은 기술적으로 가능하지만 이런 마이크로 서비스 체계 구조에서 이런 유형의 변경을 실현하려면 전체적인 체계 구조보다 더 많은 노력을 기울여야 한다.
만약 우리가 판촉에서 디자인, 데이터, 모든 내용을 교체해야 한다면 어떻게 해야 합니까?매번 교체 중의 모든 변화는 반드시 결산 페이지와 제품 목록 페이지에 반영되어야 한다.만약 우리가 잘못하면, 우리는 모든 일을 배로 늘리거나, 이 두 팀 사이에서 API를 다시 설계해야 한다.
일단 우리가 마이크로 서비스 체계 구조를 사용한다면, 우리는 기본적으로 서비스 내의 모든 변경을 더욱 쉽게 하고, 크로스 서비스의 변경은 더욱 어렵게 할 것이다.

기왕 우리 인류가 미래를 예측하는 데 능하지 않은 이상 우리는 영원히 마이크로 서비스로부터 시작해서는 안 된다.우리는 앞으로 6~12개월 동안 우리가 어떤 업무를 하게 될지 모른다.우리가 어떻게 마이크로 서비스를 분리하든지 간에 그것은 잘못된 것일 수도 있다.
우리는 영원히 마이크로 서비스로부터 시작하지 않을 것이다.

마이크로 서비스부터 시작합니다.

일이 어떻게 달라질지 되돌아봅시다.
존, 이 회사의 수석 기술관은 마이크로 서비스에 관한 책을 읽었다.존은 이것이 재난적인 생각이라고 생각한다.마이크로 서비스 기술상 해결된 모든 문제도 Monolith를 통해 완성할 수 있는데 왜 등식에 분포식 부분을 추가해야 합니까?우리의 대다수 프로그래머들은 the fallacies of distributed computing의 고통을 겪을 것이다.
존은 전체적인 건축을 고집한다.
John은 약 30명의 개발자 팀을 가지고 있습니다.이런 규모 하에서 존은 모든 변화를 그의 거대한 돌 위에 가져다 줄 수 없다.그래서 그는 가끔 코드를 검사한다.
이 회사는 상반된 방향을 취했다. 그들은 지금 바로 구매를 실시하려고 한다!!단추는 본질적으로 한 걸음으로 서명합니다.

이것은 분명히 제품 목록 페이지에 있기 때문에 이해관계자는 제품 목록 팀에게 그것을 개발하라고 요구한다.그 중 한 명의 개발자가 수요를 조사했다.그들은 이 페이지가 모두 제품에 관한 것이기 때문에 우리는 반드시 이런 제품 유형에서 그것을 실현해야 한다고 생각한다.

class Product {
    public void CheckoutWithOneClick() {
      this.PaymentService.Pay(this.Price);
    }
}

경험이 풍부한 개발자의 입장에서 볼 때 이것은 매우 강렬한 코드 맛이다.왠지 코드 심사를 거쳐 서명을 받아 전체의 주요 부분이 됐다.
6개월 후, 결산과 관련된 모든 것이 실현되기 어려워지고 문제가 생겼다.만약 우리가 판촉 코드를 응용하기를 희망한다면, 우리는 제품 종류에서 원키 서명이 실현되었다는 것을 기억해야 한다.만약 우리가 특수한 유형의 고객에게 할인을 제공하고 싶다면, 우리도 이 점을 기억해야 한다.많은 경우, 서명팀은 복잡한 서명 방안을 실시해야 하지만, 이 단추 단추를 잘 사용할 수 없다.
기능 개발, 오류 복구 및 서명 과정과 관련된 모든 것은 단독으로 이루어진다.제품팀은 Product류를 보유하고 검사팀은 CheckoutService류를 가지고 있기 때문에 각 팀은 수요에 대한 해석이 약간 다르고 서로 다른 방식으로 업무 논리를 실현한다.하나는 판촉 코드를 먼저 검사할 수도 있고, 다른 하나는 고객 특권 등을 먼저 검사할 수도 있다.
존은 이 막을 본 지 이미 너무 늦었다.CheckoutWithOneClick와 정상적인 서명 과정 사이에는 많은 코드가 중복되고 독립된 논리적 지점이 있다.이 코드를 재구성하는 데는 상당한 투자가 필요하다.
어느 날 존은 해고되었고, 제인은 새로운 수석 기술관을 고용했다.
제인이 묻는 첫 번째 질문은 왜 우리는 계산 과정에서 어떤 일을 하든지 그렇게 어렵습니까?

New CTO: Well, there is a different logic implemented in one-click checkout and normal checkout. This makes it hard to do anything in the checkout process.

Jane: How did this happen?

Random Engineer in the team: Everyone know about this. It's started by one of the developers decide to have separate logic for one-button check-in. That's bad, but I don't know how John could do it better. He could not possibly check every piece of code.

New CTO: Well, John should have started with Microservice. That way, the product list team would never be able to come up with this design. They would be blocked by Checkout team service ownership.

마이크로 서비스의 가치

존의 처지는 매우 이상하다.만약 그가 마이크로 서비스를 사용했다면, 그것은 끝장이고, 만약 그가 없었다면 끝장이었다.
본질적으로 말하자면, 마이크로 서비스는 일종의 관리 도구이기 때문이다.
마이크로 서비스는 특정한 유형의 변경을 방지하고, 특정한 유형의 변경을 더욱 쉽게 할 수 있다.
첫 번째 예에서 마이크로 서비스 체계 구조는 이상적인 변경을 막았다.두 번째 예에서 마이크로 서비스 체계 구조가 부족하여 일련의 원하지 않는 변경을 초래했다.
이것이 바로 존이 반드시 실패할 운명인 원인이다.문제는 거석과 미서비스에 있지 않다.문제는 구조 선택이 업무 성장과 일치하지 않는다는 점이다.
두 번째 이야기에서 John은 모든 코드가 디자인 심사와 전체 감사를 거쳤는지 확인하기 위해 더욱 열심히 일할 수 있다고 말할 수 있지만 이것이 중점이다.이런 관리 솔루션은 비용이 많이 들고 개발 과정에서 대량의 비용을 증가시킬 수 있다.
마이크로 서비스는 원가를 낮출 수 있다. 왜냐하면 본질적으로 설계를 어지럽히기 어렵기 때문에 우리는 이런 복잡한 과정을 모두 필요로 하지 않는다.하지만 우리가 정말 디자인을 망치고 싶을 때, 그래...첫 번째 이야기에서 이 장면을 봤어.
마지막으로, 구조는 반드시 업무 성장과 일치해야 한다.그뿐이야.
마이크로 서비스를 사용할 때, 일부 성장을 더욱 쉽게 할 수 있고, 일부 유형의 성장을 사용하지 않는 것도 더욱 어려워질 수 있습니다.
만약 당신이 서명 마이크로 서비스를 가지고 있다면, 서명 팀은 더욱 빨리 새로운 기능을 내놓을 수 있을 것이다.그들은 스스로 석방할 수 있다.그들은 자신이 좋아하는 프로그래밍 언어를 사용할 수 있다.그들은 다른 팀에 의존하지 않는다.그들은 서비스의 신축성을 독립적으로 관리할 수 있다.
이것이 바로 내가 믿는 마이크로 서비스 구조의 핵심 장점이다.
마이크로 서비스의 모든 기술적 측면, 예를 들어 시스템의 어떤 부분을 독립적으로 확장하거나 다중 언어로 실현하면 모두Monolith로 해결할 수 있다.일부 용기의 특정 단점을 열고 시스템의 일부분을 독립적으로 확장하기 위해 구축하고 설정할 수 있습니다.운영체제 단계에서 크로스 프로세스 통신을 사용하고 바이너리 분배를 관리한 다음에 다중 언어로 실현할 수 있습니다.네트워크보다 지연이 더 좋을 수 있습니다.
Monolith가 해결할 수 없는 문제는 어떤 유형의 관리 구조를 가지고 자주성과 빈번한 독립 발표 주기를 부여함으로써 특정 분야의 성장과 창조력을 격려하고 싶을 때다.이것은 전체형 건축에서 정말 하기 어려운 것이다.
그래서 저는 마이크로 서비스 실시의 결정적인 요소는 그것이 당신의 조직이 원하는 성장 방식과 일치하는지 여부라고 말하고 싶습니다.
마찬가지로 마이크로 서비스는 본질적으로 관리 문제를 해결하는 기술적 해결 방안이기 때문이다.이것은 진정한 문제로 좋은 해결 방안이 필요하다.
만약 당신이 이것이 어리석은 관리 문제라고 생각한다면, 나는 당신에게 이 문제를 해결해 보라고 초대합니다.만약 당신이 간단한 문제를 해결할 수 있다면 어떻게 하면 프로그래머가 효과적으로 협업할 수 있습니까?확장 가능하고 반복 가능한 방식으로, 나는 네가 제프 베조스보다 더 부유할 수 있다고 믿는다.
아마존은 줄곧 노력하고 있다.구글은 줄곧 이 문제를 연구하고 있다.페이스북은 이 문제를 해결하기 위해 노력해 왔다.현존하는 모든 대형 과학 기술 회사는 이미 이 방면에서 수십 년 동안 일했고, 그들은 마이크로 서비스의 물건을 제기했다.만약 당신에게 더 좋은 답이 있다면, 나와 모든 사람이 다 알게 해 주세요.그들은 투자할 준비가 되어 있다.