OSS.Core 기본 아이디어

요즘 프레임워크라는 단어가 화제가 되었습니다. xx사의 아키텍처디자인은 어디에서나 볼 수 있지만 대부분은 단지 재미를 위한 것입니다. 그리고 그들 사이의 분리의 기초는 무엇입니까.. 저는 특히 점점 인기를 얻고 있는 마이크로서비스와 파생된 마이크로서비스 게이트웨이 제품에 대해 여전히 의구심을 가지고 있다고 믿습니다. 저는 최근에 작은 오픈 소스 프레임워크인 OSS.Core를 작성할 계획이었습니다. 이 기사를 통해 가능한 한 많은 사람들이 이해할 수 있도록 돕기를 바랍니다.

1. 마이크로서비스의 기원

2. 마이크로서비스의 아이디어

3. OSS.Core 프레임워크의 설계 및 구현

이야기를 시작하기 전에 먼저 전통적인 아키텍처와 마이크로서비스 아키텍처가 마이크로서비스에 대해 독립적이거나 반대되는 것이 아니라는 점을 이해하시기 바랍니다. 동시 유지 관리와 같은 문제를 처리하기 위해 전통적인 프레임워크에서 파생된 논리적 개념입니다. 이는 프로젝트의 여러 단계에서 문제를 생각하고 해결하는 방식의 변화에 ​​관한 것입니다. 둘째, 논리적 아키텍처를 물리적 아키텍처(파일)와 구별합니다. 대부분의 경우 논리적 아키텍처는 물리적 아키텍처에 해당하지만 때로는 물리적 아키텍처에 여러 논리적 아키텍처가 포함될 수 있습니다.

1. 마이크로서비스의 기원

마이크로서비스는 주로 일부 크고 복잡한 애플리케이션을 여러 서비스 조합으로 분해하며, 각 서비스는 자율적으로 이루어지므로 더 많은 유연성과 더 쉬운 유지 관리가 가능합니다.

　더 나은 이해를 위해 먼저 동시성을 해결하는 세 가지 일반적인 방법을 살펴보겠습니다.

　1. 데이터베이스 마스터-슬레이브 분리 또는 다중 마스터 쓰기 또는 파티셔닝 메커니즘을 추가하고 이에 따라 연결 문자열을 수정하거나 액세스 추가 미들웨어 데이터베이스 처리 기능을 향상합니다.

　　2. 데이터베이스 리소스는 상대적으로 부족하고 시간이 많이 걸리기 때문에 액세스 속도를 향상시키기 위해 일반적으로 분산형 캐싱 등을 사용하여 기본 레이어에 대한 액세스를 줄입니다.

　　3. 로드 밸런싱 오프로드 처리는 많은 수의 요청이 애플리케이션에 도착하기 전에 이를 다른 시스템에 분산하여 단일 시스템 대역폭 및 성능 병목 현상 문제를 해결합니다.

물론 프런트엔드 정적 파일 압축, CDN 가속, IP 속도 제어 등 동시성을 해결하는 다른 방법도 많이 있습니다. 여기서는 건너뛰겠습니다.

많은 친구들이 위의 세 가지 방법을 보았어야 했습니다. 여기에 나열한 이유는 이 그림과 결합하면 기존 전체 서비스와 마이크로 서비스의 변경 사항을 더 쉽게 비교할 수 있기 때문입니다.

In Traditional In 전반적인 서비스 프레임워크에는 모듈 간 결합, 프로젝트 내 상호 호출 및 다양하고 복잡한 집계 작업이 있으므로 대부분의 경우 왼쪽 그림에서 전체로만 배포할 수 있습니다. 로드 밸런싱을 할 때는 여러 머신에 전체적으로 배포해야 하는데 데이터베이스도 마찬가지고 프로젝트 내 각 모듈의 요구 사항도 다릅니다. 예를 들어, 제품과 주문 모듈의 액세스 빈도와 프로세스 복잡성은 매우 다릅니다. 주문 빈도는 상대적으로 적고 복잡성은 높으며 예산 기능이 높으며 상대적으로 적은 수의 기계에서 실행하는 것을 선호합니다. 문제 해결 및 유지 관리. 오른쪽 그림에서 볼 수 있듯이 서비스를 구체화한 후 상황에 따라 더 작은 배치 단위를 사용하여 결합할 수 있습니다.

동시에 인터넷 제품이 빠르게 반복되는 오늘날의 시대에 제품은 다양한 단말기에 대해 다양한 애플리케이션 기능을 신속하게 실행할 수 있어야 하며 동시에 비즈니스 조정을 빠르게 실행할 수 있어야 합니다. 서비스 모델로는 더 이상 충분하지 않습니다. 마이크로서비스가 여러 부분으로 나누어져 있기 때문에 각 모듈은 독립성으로 인해 빠르게 결합될 수 있으며, 각 모듈은 다양한 수요 지점에 따라 서로 다른 특성을 지닌

프로그래밍 언어

를 사용할 수 있습니다. 　

2. 마이크로서비스의 디자인 아이디어

제품마다 고유한 기준과 우선순위가 있기 때문에 서비스 단위의 디자인도 다르지만 가장 기본적인 점이 있습니다.

서비스 자율성

마이크로서비스 모듈을 설계할 때 현재 서비스의 독립성, 특히 데이터 모듈의 독립성을 보장해야 합니다. 다른 서비스는 현재 서비스에서 데이터베이스 모듈을 직접 운영할 권한이 없으며 외부 상호 작용만 완료할 수 있습니다. 서비스

인터페이스

를 통해. 모듈은 독립적이므로 적절한 프로그래밍 언어와 해당 배포 규모를 선택할 수 있습니다. 로컬의 유연한 최적화를 달성하세요. 마이크로서비스는 서로 독립적이며 위의 편리함을 제공하지만 우리가 직면해야 할 몇 가지 문제도 가져옵니다.

　우선: 현재 서비스의 경계를 정의하는 방법과 현재 서비스 거버넌스의 범위를 결정하는 방법입니다.

서비스 단위를 최소화해야 하므로 서비스의 책임 범위를 결정해야 합니다. servicelifecycleprocess, area 및 예상을 결합하는 것이 좋습니다. scale 사용자 서비스 등 이러한 점을 고려하여 방문 횟수가 적고 인원이 적은 경우 기본 사용자 정보 및 잔액 계정을 서비스 모듈에 배치하여 업무량과 방해 요소를 줄일 수 있습니다. 규모가 커지면 기본 서비스와 자산 서비스로 나눌 수 있습니다.

　두 번째: 교차 서비스 데이터 query문제

　예를 들어 클라이언트에서 제품을 search하는 방법, 사용자를 검색하거나 통계 데이터를 쿼리하는 등의 처리 방법도 있습니다. 이를 처리하는 두 가지 방법을 알려드리겠습니다:

　1. API Gateway

　 이 상황은 서비스 단위가 너무 많고 클라이언트가 다른 서비스 단위의 데이터를 쿼리해야 하는 경우에 적합합니다. 이때 우리는 타겟팅할 수 있습니다. API 서비스 게이트웨이를 구축합니다(APP 게이트웨이와 다릅니다). 이 게이트웨이를 통해 여러 서비스가 집계됩니다. 클라이언트는 현재 게이트웨이와만 상호 작용하면 되며 게이트웨이는 이를 집계하여 다른 마이크로서비스로 전달합니다. 아래와 같이

　　2. 데이터 중복 또는 백그라운드 데이터 동기화

　예를 들어 주문 정보에는 사용자 이름과 같은 몇 가지 사용자 필드가 필요합니다. 이때 이러한 필드를 완전히 중복할 수 있습니다. 모듈 아래의 주문 마이크로서비스 데이터. 또 다른 예를 들어, 통계 모듈에서 데이터 생산자와 쿼리자는 완전히 다른 객체에 속하며 실시간이 아닙니다. 그러면 다른 서비스는 event메시지를 통해 상호 작용합니다. Update 해당 통계 데이터를 조회할 때 통계 서비스 자체 데이터를 통해 완성할 수 있습니다.

　다시 한 번 말씀드립니다. 서비스 간 통신 문제를 해결하는 방법

　서비스를 서로 독립적으로 만들고 서로 다른 서비스 데이터베이스를 직접 운영할 가능성을 차단했기 때문입니다. 그렇다면 데이터 일관성을 어떻게 처리해야 할까요? 기존 서비스 모델 에서는 모두 혼합되어 있기 때문에 트랜잭션이나 저장 프로시저 를 통해 데이터 일관성을 보장할 수 있습니다. 두 가지 일반적인 방법이 있습니다:

　　1. 비동기 이벤트 메시지 드라이버

　 이러한 유형의 솔루션은 위의 통계 서비스 업데이트, 서비스 이벤트 트리거와 같이 실시간 데이터에 대한 요구 사항이 상대적으로 낮은 시나리오에 적합합니다. 그런 다음 응답 메시지 알림을 메시지 queue에 푸시하고 이 대기열의 서비스에 가입하여 업데이트된 데이터를 받으세요. 그림과 같이:

　　2. 직접 인터페이스 요청(HTTP, RPC)

　 일반적으로 계단식 종속성을 방지하는 것은 권장되지 않습니다. 이러한 유형의 요청은 주로 실시간 데이터 요구 사항이 높은 요청을 대상으로 합니다. 예를 들어, 플래시 판매 주문 프로세스 중에 재고 서비스 공제 성공 여부 등을 즉시 알아야 합니다. (참고: .net에서 작업에 대한 지원은 이미 매우 좋습니다. 비동기 http 요청을 사용하는 것이 좋으며 프런트 엔드는 IO 작업으로 인한 작업자 스레드 소비를 줄이기 위해 Task<ActionResult>를 반환합니다.)

마지막으로: 클라이언트 액세스 방법

서비스를 캡슐화한 후 실제 보안 규칙 및 요구 사항에 따라 서비스 및 최종 클라이언트 액세스 방법을 결정해야 합니다. 일반적으로 서비스가 비교적 작은 경우 복잡한 경우에는 그림과 같이 서비스 인터페이스가 클라이언트에 직접 노출되어 액세스할 수 있습니다.

　 또는 API 형식으로 클라이언트에 제공될 수 있습니다. 위에서 언급한 게이트웨이 물론 성숙한 마이크로서비스 게이트웨이도 많이 있습니다. 예를 들어 Azure 클라우드의 Service Fabric 또는 API Management를 모두 사용할 수 있습니다.

3. OSS.Core 프레임워크의 아이디어와 구현

　OSS.Core 프로젝트는 제가 최근에 작성하고 있는 작은 오픈 소스 제품입니다. 이를 아는 친구들은 제가 이전에 OSS.Social, OSS.PayCenter, OSS.Common, OSS.Http I와 같은 몇 가지 구성 요소를 작성했다는 것을 알아야 합니다. 이 프로젝트가 이러한 구성 요소를 함께 연결하기 위해 위에서 마이크로서비스에 대한 일반적인 사고 방식을 소개했습니다. 이를 이 제품의 논리적 아키텍처에 반영하기 위해 최선을 다하겠습니다. 먼저 프로젝트의 물리적 아키텍처 다이어그램을 보여줍니다.

　이 프로젝트에서는 AdminSite와 WebSite가 Front

Ends 폴더에 위치합니다. 두 사이트는 사용자 프런트엔드와 백그라운드 관리 프런트엔드

　 WebApi, Service, Do

mainMos( Model 사진과 인터페이스)Class 라이브러리Layers 폴더 아래에는 API

　Infrastructure(비즈니스 관련 일반 엔터티 열거 보조 클래스)와 Common(비즈니스와 무관한 엔터티 보조 클래스)의 기반을 형성합니다. 인프라 클래스 라이브러리로서 모든 레벨에서 사용할 수 있습니다.

리포지토리는 클래스 라이브러리에서 호출됩니다(일시적으로 프로젝트에서 OSS.Core.RepDapper의

Mysql 구현이며 향후 다른 데이터베이스 지원이 추가될 수 있음) ), 주로 Rep.. 인터페이스의 특정 구현입니다.

　플러그는 Common 플러그인에서 로깅, 캐싱 및 구성 인터페이스의 특정 구현을 구현하며 Common을 통해 모든 수준에서 직접 호출할 수 있습니다.

마이크로서비스 주제로 돌아가서, 이 제품에서는 각 서비스에 대한 레이어 아래에 클래스 라이브러리 구현 세트를 만들지 않을 것입니다. 이 프로젝트에서는 WebApi를 폴더 격리 형태로 분리할 수 있습니다. API 게이트웨이 내부 호출 순서는 다음과 같습니다.

현재 코드 구조 다이어그램:

위 내용은 OSS.Core 기본 아이디어의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!