PHP에 마이크로서비스가 필요한가요?

기술계에서는 종종 새로운 유행어가 생겨나고 오해받기 쉽습니다. 가장 무서운 점은 일부 기술팀이 자신들의 기술과 유행어가 무너질까 봐 두려워하는 듯 유행어를 따르거나 이해하지 못한 채 가까이 다가가는 것입니다. 로우 레벨과 마찬가지로 관련성이 없거나 다릅니다. 기술계에서는 이러한 현상이 너무 흔하다고 생각하며 일부 사람들은 이에 대해 불만을 표시합니다.

마이크로서비스라는 유행어에 대해 말하자면, 저는 지금까지 마이크로서비스와 서비스화의 차이점을 이해하지 못했다는 점을 인정해야 합니다. 2008년 타오바오의 서비스화 전환 이후 형성된 SOA 시스템에 대해서도 잘 모르겠습니다. 같은가요? 다양한 기사에서 마이크로서비스는 단순히 기술 세계의 일부 장면의 구세주로 홍보되어 많은 학생들이 마이크로서비스 시스템을 구축하도록 직접적으로 오해하고 있습니다. (추천 학습: PHP 비디오 튜토리얼)

하지만 마이크로서비스의 사용이 필요한지, 비즈니스 발전에 도움이 되는지 방해가 되는지 신중하게 생각해 본 학생이 얼마나 되는지 모르겠습니다. 빠르게 반복되는 유형의 비즈니스에서는 비즈니스 반복 효율성이 핵심 문제입니다.

내 자신의 이해에 따르면, 서비스화에 대한 내 견해는 항상 이 구덩이에 들어가는 것을 피할 수 있다면 들어가지 않는 것이 가장 좋다는 것입니다. 단일 애플리케이션의 복잡성은 N으로 구성된 분산 시스템보다 훨씬 간단하고 빠릅니다. 글쎄, 일단 분산 피트에 들어가면 기술에 상대적으로 큰 투자를 해야 합니다.

일부 중소기업의 경우에는 전혀 필요하지 않다고 생각합니다. Google의 Jeff Dean은 Google의 서비스화에 대한 자신의 견해를 다음과 같이 공유한 적이 있습니다.

Google에서 공동 개발을 위해 수천 명의 사람들이 동시에 작업하도록 하세요. 이런 관점에서 저는 서비스화가 ​​수평적 확장성의 문제를 해결하는 데 초점을 맞추고, 그 다음에는 병렬 협업의 문제가 뒤따른다는 것을 항상 느꼈습니다.

하지만 이제 기본적으로 서비스 지향의 초점은 회사가 100명이 넘는 사람들의 병렬 공동 개발 능력을 갖도록 하는 것이라는 점에 더 동의합니다. 수십 명의 R&D 학생이 함께하는 병렬 공동 개발은 불가능할 것이라고 생각합니다. 병렬 협업에 대한 일부 투자는 서비스화에 들어간 이후의 투자보다 훨씬 적을 것입니다.

그래서 몇몇 친구들이 회사를 서비스 중심으로 바꿔야 하는지 물을 때 저는 항상 두 가지 질문을 했습니다.

현재 회사 R&D팀에는 몇 명이 있나요?

현재 수평 확장 병목 현상은 무엇입니까?

이 두 가지 문제에서 서비타이제이션이 핵심 병목 현상이 아니거나, 적은 인력이나 기계 비용만으로 해결할 수 있는 경우라면 서비타이제이션을 하지 않는 것을 강력히 권해드리니, 마이크로서비스라는 유행어에 현혹되는 학생들에게 부탁드립니다. 친구 여러분, 그러한 아키텍처를 채택하기 전에 신중하게 생각하시기 바랍니다. 비용과 문제가 그다지 크지 않다면 사용하지 않는 것이 전략입니다.

부득이한 경우를 제외하고는 서비스 중심의 서비스가 제대로 구현될 수 있도록 조직과 팀 인력 등을 잘 마련해 주시고, 이것이 결국 사업 발전에 걸림돌이 되지 않도록 해주시기 바랍니다.

위 내용은 PHP에 마이크로서비스가 필요한가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!