내 응용 프로그램을 마이크로 서비스 아키텍처로 이전할지 여부를 결정하는 링크를 알려주거나 공유해 주시겠습니까?마이크로 서비스로 이동하거나 이동하지 않음
시나리오 : 나는 인터넷에 직면하고 응용 프로그램을 가지고 있지만 사용자 즉의 유한 번호로 들어오는 트래픽의 급격한 스파이크을받지 않습니다. 그리고 이 애플리케이션은 어떤 비즈니스도 비판적으로 저장하지 않습니다. 데이터는 다른 애플리케이션에 의존하며 나머지 애플리케이션 또는 직접 데이터베이스 호출을 통해 다른 애플리케이션의 데이터를 사용합니다. 또한 비용 절감을 위해이 애플리케이션을 AWS로 옮기고 싶습니다.
마이크로 서비스를 이동할지 여부를 알려 주실 수 있습니까?
마이크로 서비스로 전환하기로 결정했다면 전략은 무엇이되어야합니까?
마이크로 서비스를 이동할지 여부를 알려주시겠습니까?
응용 프로그램과 조직에 대해 거의 알지 못한다면 말하기 어렵습니다.
코드 기반이 얼마나 큰 : 당신은 다음과 같은 대답하면 우리는 더 나은 답을 줄 수 있습니까?
오늘 얼마나 많은 사람들이 노력하고 있습니까?
향후 향후 얼마나 많은 사람들이 작업해야합니까?
시스템에 몇 명의 사용자가 있습니까?
그러나 일반적으로 사용자의 설명에 따르면 좋은 투자로 들리지는 않습니다. 일반적으로 마이크로 서비스 아키텍처는 대규모 응용 프로그램이 유지 관리가 가능하고 확장 가능하도록 도와줍니다. 귀하의 신청서가 그리 크지 않거나 스케일링이나 유지 보수에 문제가 없다면 투자하지 않을 것입니다. 그러나 앞으로 응용 프로그램을 많이 확장 할 예정이라면 새로운 서비스를 마이크로 서비스로 개발하고 점차 단일체에서 멀어 지도록 권장 할 것입니다.
마이크로 서비스로 전환하기로 결정했다면 전략은 무엇이되어야합니까?
우리는 이것을 stackoverflow 질문에서 대답 할 수 없습니다. 이를 위해서는 응용 프로그램과 차별화 할 수있는 다양한 서비스 (비즈니스 목적에 따라)에 대한 심층 분석이 필요합니다. 각 서비스에 대해 다른 파트와의 연결을 줄이는 방법과 이러한 상호 작용을위한 API를 정의하는 방법 또는 서비스에 대한 데이터 기반을 분리하여 관계를 파괴하는 방법을 식별해야합니다. 구현 기술을 살펴보고 각 서비스에 가장 적합한 사례별로 결정할 것입니다. 기본 인프라를 살펴보고 자동화가 가능한 옵션 (예 : kubernetes)을 결정할 수도 있습니다.
this을 읽으십시오.
마이크로 서비스로 이동하는 것에 대해 언급해야 할 것이 많지만 어쨌든 마이크로 서비스와 모노리스의 장점과 단점을 알아야합니다. 이 https://www.oreilly.com/ideas/modules-vs-microservices 또는 https://www.nginx.com/wp-content/uploads/2015/01/Building_Microservices_Nginx.pdf 또는 http : // cloudacademy를 읽으십시오. com/blog/microservices-architecture-challenge-advantage-drawback / –