처음에는 데이터량이 많지 않아 시스템 성능도 꽤 좋았고, 각종 목록 쿼리, 보고서 쿼리, 엑셀 데이터 내보내기 기능 등 모두 원활하게 사용되었습니다. 그러나 회사의 사업이 발전하고 주문량이 나날이 누적되고, 이후 다양한 사업부서의 보고서 조회 및 데이터 내보내기에 대한 수요가 계속 증가함에 따라 시스템이 점점 느려지고 있다는 것을 느꼈습니다. 따라서 우리가 생각할 수 있는 첫 번째 솔루션은 시스템 병목 현상 데이터베이스를 최적화하는 것입니다. 가능한 시도 중 하나는 데이터베이스를 서버에 별도로 배치하여 데이터베이스와 애플리케이션을 분리하거나, 다양한 데이터베이스 테이블 인덱스를 구축하거나, 프로그램 코드를 최적화하는 등의 시도입니다. 이러한 연구와 최적화 후에 시스템의 일부 기능의 성능은 실제로 크게 향상될 수 있지만 여전히 일부 기능 목록의 데이터 쿼리 및 내보내기가 여전히 매우 느리거나 데이터 양이 계속 누적됨에 따라 원래 빨라진 목록 내보내기 기능도 점점 느려지고 있습니다. 다양한 방법을 시도했지만 결국 이상적인 시스템 성능 속도를 달성하지 못했습니다.
시스템 성능을 향상시키기 위해 높은 동시성, 고성능, 빅데이터, 읽기-쓰기 분리 및 기타 솔루션과 같은 일부 인터넷 회사의 기술 경험을 통해 배울 수 있지만 방법이 없다는 것을 알게 됩니다. 시작한다. 우리는 시스템의 업무 특성이 다르다고 생각합니다. ERP 시스템의 동시성은 주로 비즈니스의 복잡성으로 인해 높지 않습니다. 다양한 비즈니스의 결합 정도가 인터넷 애플리케이션보다 훨씬 높기 때문에 데이터 쿼리 로직이 훨씬 더 복잡합니다. 인터넷 시스템의 목록 페이지에서 쿼리한 데이터는 4~5개의 테이블을 연관시켜서 얻을 수 있는 경우가 많습니다. 일부 보고서에는 더 많은 내용이 있습니다. 다양한 비즈니스 운영의 트랜잭션 특성과 높은 데이터 일관성 요구 사항으로 인해 우리는 종종 방심하여 시스템을 더 이상 최적화할 수 없었습니다.
옛날에는 ERP 시스템이 매우 특별하고 치료할 수 없는 시스템이라고 생각하면서 이런저런 이유로 좌절했지만 나중에는. . .
아닌거 같은데 새로운 해결 방법이 있는 것 같네요오(∩_∩)오하하~
구체적인 계획을 설명하기에 앞서 먼저 제 생각을 말씀드리겠습니다. 우선, ERP 시스템을 구축하기 전에 오늘날의 인터넷적 사고를 갖추어야 한다고 생각합니다. 우리는 더 이상 통일된 시스템을 구축하고 싶지 않습니다. 우리는 큰 시스템을 작은 시스템으로 분할해야 합니다. 그러면 이러한 소규모 시스템은 시스템 인터페이스를 통해 서로 통신할 수 있습니다. 이는 대규모 시스템, 특히 "분산" 및 "서비스 지향" 인터넷 사고를 형성합니다. 시스템은 아키텍처 설계 측면에서 본질적으로 높은 확장성을 지원하는 시스템이 되도록 하겠습니다.
어떻게 하나요? 구체적으로는 주문관리, 상품관리, 생산 및 조달, 창고관리, 물류관리, 재무관리 등을 하나의 서브시스템으로 분리하는 것이 필요하다. 이러한 하위 시스템은 독립적으로 설계 및 개발될 수 있으며 다양한 다른 하위 시스템에 필요한 데이터 인터페이스가 외부 세계에 노출될 수 있습니다. 각 하위 시스템에는 별도의 데이터베이스가 있습니다. 이러한 하위 시스템도 다양한 기술 시스템과 데이터베이스를 사용하여 다양한 팀에서 개발하고 유지 관리할 수 있습니다. 이전과 같이 동일한 크고 포괄적인 시스템, 크고 포괄적인 데이터베이스에 통합되는 것이 아닙니다.
새로운 건축 시스템의 장점은 무엇인가요?
가장 중요한 것은 시스템 성능 문제를 해결하는 것입니다. 과거에는 데이터베이스 인스턴스가 하나뿐이어서 여러 인스턴스로 확장하는 것이 불가능했기 때문에 성능이 제한될 때 데이터베이스 인스턴스를 더 추가하여 로드 밸런싱을 이룰 수 있었습니다. 어떤 사람들은 읽기-쓰기 분리 솔루션을 사용할 수 있다고 말할 수도 있지만 ERP 시스템의 특성상 이 솔루션은 종종 비현실적입니다. 예를 들어, 인벤토리 운영 시 독서 도서관에서 인벤토리를 읽어온 후 글쓰기 도서관에 인벤토리를 쓸 수 없습니다. 마스터-슬레이브 복제는 시간에 민감하기 때문에 작성된 인벤토리를 슬레이브 데이터베이스에 즉시 쓸 수 없습니다. ERP에는 이러한 시나리오가 많이 있습니다. 게다가 글쓰기 라이브러리는 확장할 수 없으며 하나만 있을 수 있습니다. 새로운 디자인 솔루션은 쓰기 라이브러리를 분리하는 것이며 각 하위 시스템에는 자체 데이터베이스가 있습니다.
둘째, 업데이트가 매우 편리하며 각 하위 시스템이 백그라운드 마이크로서비스로 존재합니다. 프론트 엔드에는 별도의 웹 프로젝트가 있으며, 이 웹 프로젝트는 백그라운드에서 이러한 하위 시스템의 서비스 인터페이스를 호출합니다. 이 설계를 사용하면 특정 비즈니스 하위 시스템을 업데이트해야 할 때 독립적으로 업데이트할 수 있습니다. 이전 단일 프로세스 아키텍처와 달리 소규모 업데이트로 인해 전체 시스템을 다시 시작해야 했기 때문에 사용자 세션이 손실되고 사용자가 다시 로그인해야 했습니다. 현재 디자인에는 이 문제가 발생하지 않습니다.
시스템 물리적 배포 보기
애플리케이션 계층을 분할하는 것은 "마이크로서비스" 아키텍처 개념을 구현하는 것입니다. 원래의 크고 포괄적인 단일 프로세스 아키텍처를 비즈니스 모듈에 따라 독립적으로 배포 가능한 애플리케이션으로 분할하여 원활한 시스템 업데이트 및 업그레이드를 달성하고 로드 확장을 촉진합니다. 특히 기술적으로는 Restfull 스타일 인터페이스를 사용하거나 Java의 Dubbo와 같은 프레임워크를 사용하여 개발 복잡성을 단순화할 수 있습니다. ERP 웹 클라이언트 또는 기타 모바일 클라이언트도 프레젠테이션 계층 역할을 하는 별도의 애플리케이션입니다. 이는 매우 얇습니다. 단순히 매개변수를 받아들이고 표시해야 하는 데이터를 얻기 위해 백그라운드에서 다양한 다른 마이크로서비스 프로그램의 인터페이스를 호출합니다. 마이크로서비스는 비즈니스 논리 계층 역할을 하며, 각 마이크로서비스는 독립적으로 배포할 수 있고 외부 데이터 액세스 인터페이스를 제공하는 프로그램입니다.
마이크로서비스는 여러 호출 프로토콜인 Http, TCP 등을 지원할 수 있는 dubbo와 같은 다양한 인기 RPC 프레임워크를 사용할 수 있습니다. 이러한 프레임워크는 코딩을 더 쉽게 만들어 주며, 프레임워크는 기본 데이터 통신 세부 정보를 캡슐화하여 클라이언트가 마치 원격 메서드를 실행할 수 있게 해줍니다. 로컬 방법도 마찬가지로 쉬웠습니다.
Dubbo 마이크로서비스 아키텍처는 서비스 거버넌스, 로드 밸런싱 및 기타 기능도 지원합니다. 이는 시스템의 가용성을 향상시킬 뿐만 아니라 시스템 애플리케이션 계층의 성능을 동적으로 향상시킬 수도 있습니다. 예를 들어, 창고 관리에서 창고 업무는 매우 바쁘고 CPU와 메모리 리소스를 많이 차지합니다. 다른 시스템을 추가하고 별도의 창고 관리 서비스를 배포할 수 있습니다. 이를 통해 전체 시스템은 두 개의 창고 관리 서비스를 동시에 작동하여 부하 균형을 맞출 수 있습니다. 그리고 이 모든 작업은 Zookeeper와 같은 서비스 등록 센터에서 자동으로 수행됩니다.
마이크로서비스 구조는 자연스럽게 시스템 업데이트 및 업그레이드 작업을 지원합니다. 예를 들어 금융 모듈에 새로운 요구 사항이 있어 온라인으로 전환해야 하는 경우 금융 모듈의 서비스를 교체하고 다시 시작하기만 하면 됩니다. 이는 이미 시스템에 로그인한 사용자에게는 큰 영향을 미치지 않으며 시스템에 다시 로그인할 필요도 없으며 다른 모듈 서비스의 사용에도 영향을 미치지 않습니다.
데이터베이스 병목 현상은 ERP 시스템에 영구적인 손상을 입힙니다. 대량의 복잡한 데이터 쿼리 테이블 연결 로직이 전체 시스템에 넘쳐납니다. 수직적 데이터베이스 분할 성공의 열쇠는 시스템 데이터 계층에서 다양한 모듈의 상호 결합을 어떻게 재설계하느냐에 달려 있습니다. 이 문제를 해결할 수 있다면 영구적인 손상도 해결할 수 있습니다.
먼저 일반적인 데이터 계층 모듈 결합 문제를 살펴보겠습니다. 요구 사항은 자재 재고, 목록 필드를 표시하는 것입니다: 자재 번호, 자재 이름, 카테고리, 창고, 수량
자료 목록:
인벤토리 테이블:
카테고리 및 창고 테이블은 생략되었습니다. . .
분명히 기존 데이터베이스에서는 이 두 테이블을 연결하고, 카테고리와 웨어하우스 테이블을 연결하여 원하는 데이터를 쿼리하려면 간단한 조인 작업만 필요합니다. 그러나 이제 우리 아키텍처에서는 재료 테이블과 제품 테이블이 동일한 데이터베이스 인스턴스에 있지 않으며 조인 작업을 사용할 수 없습니다. 그러면 요구 사항을 어떻게 실현합니까?
새로운 아키텍처에서는 상대방의 서비스 인터페이스를 통해서만 데이터를 얻을 수 있으며 상대방 서비스의 개인 데이터베이스와 직접 연결할 수 없습니다. 적어도 아키텍처적인 관점, 서비스 지향적인 관점에서는 상대방 서비스의 데이터베이스에 직접 접근할 수 없습니다. 이 경우 웹 모듈 하위 시스템이 데이터를 얻기 위해 웨어하우스 하위 시스템을 호출한다고 가정하면 데이터를 수집하기 위해 웨어하우스 모듈에서 서비스 메서드를 만들어야 합니다. 그런 다음 웹 하위 시스템으로 반환됩니다. 아래 그림과 같이 창고 관리 방법은 먼저 로컬 재고 테이블의 자재 코드와 창고 테이블의 창고 이름 필드 정보를 획득한 후 최종적으로 20개의 데이터를 웹 모듈에 반환할 준비가 됩니다. 이 20개의 데이터에 포함된 자재 ID는 상품 모듈 하위 시스템을 요청하는 매개 변수로, 상품 하위 시스템은 이 20개의 자재 ID와 관련된 상품 정보를 창고 관리 모듈에 반환한 후 창고 관리 모듈이 두 필드 데이터를 재조립합니다. 최종 요구 사항을 달성하기 위해 상위 목록에 필요한 재료 이름 및 카테고리의 데이터가 웹 하위 시스템에 반환됩니다.
아마도 이 방법의 성능은 직접 조인만큼 높지 않으며 성능 문제를 해결할 수 없다고 말할 것입니다. 언뜻 보면 그런 것 같지만 잘 생각해보면 시스템 동시성이 낮고, 데이터의 양이 적고, 업무가 바쁘지 않은 환경에서는 실제로 성능이 그렇게 빠르지 않다. 하나의 데이터에 전통적인 조인 방식을 적용합니다. 하지만 나중에 생각해 보자! 우리의 현재 아키텍처 설계는 하나의 데이터베이스를 여러 데이터베이스로 분할하고 각 데이터베이스가 별도의 서버에서 실행될 수 있도록 하여 향후 데이터베이스에 대한 부담을 부담할 수 있도록 하는 것입니다. 전반적으로 이는 향후 비즈니스가 바쁠 때 데이터베이스가 성능 병목 현상을 일으키는 것을 방지합니다. 생각만 해도 흥미롭지 않나요?
이때, 앞으로 시스템 데이터의 양과 사업이 더 커지고, 여러 개의 데이터베이스로 분할하는 것만으로는 충분하지 않다면 어떻게 되는지 다시 묻는 분들이 계실 것입니다. 내 방법은 분할된 데이터베이스를 기반으로 하며 각 라이브러리는 읽기와 쓰기를 분리하고 캐싱 등을 사용할 수 있습니다. 하위 시스템을 계속해서 여러 하위 시스템으로 다시 분할할 수도 있습니다. 비즈니스 모듈이 얼마나 바쁜지에 따라 다릅니다.
어떤 사람들은 다시 질문할 수도 있습니다. 일부 목록 쿼리 논리는 매우 복잡하고 10개 이상의 테이블을 포함하므로 위의 방법에 따라 데이터가 분할되면 재앙이 될 것입니다! 그래 네가 맞아. 이 경우에는 보다 복잡한 보고서 수준 데이터 쿼리를 사용하여 요구 사항을 표시하고 별도의 보고서 시스템을 구축할 계획입니다. 보고서 데이터베이스 디자인은 데이터 웨어하우스 접근 방식을 채택합니다. 더 높은 읽기 성능을 위해 데이터베이스 테이블을 많은 중복 필드로 설계할 수 있는데, 이는 반 패러다임 설계이며, 결합된 인덱스를 많이 생성할 수 있습니다.
이 시스템 성공의 열쇠는 데이터와 주요 ERP 시스템 비즈니스 라이브러리의 동기화입니다. 일반적으로 예약된 동기화 프로그램을 작성하여 관련 쿼리를 단순화하기 위해 ERP 주요 업무 시스템에서 데이터의 선택, 변환 등을 통해 보고서 보기에 필요한 최종 또는 중간 데이터를 직접 생성할 수 있습니다. 보고 시스템은 마이크로서비스 아키텍처를 사용하여 설계할 수도 있습니다. 아래 그림과 같이:
보고서에 필요한 데이터에 실시간이 필요한 경우 ERP 시스템이 비즈니스 운영 중에 데이터 동기화 요청을 트리거하고 이를 보고서 라이브러리에 실시간으로 동기화하도록 할 수 있습니다.
누군가는 ERP 시스템의 많은 작업에 트랜잭션이 필요하다고 다시 질문할 수 있습니다. 시스템을 분할한 후 어떻게 트랜잭션을 달성하고 데이터 일관성을 보장합니까?
좋은 질문이고, 이 글을 쓰기로 결정하기 전 마지막으로 고민했던 질문이기도 합니다. 마이크로서비스 아키텍처에서는 효율적인 성능과 좋은 데이터 일관성을 바탕으로 적어도 로컬 데이터베이스 트랜잭션을 사용하는 로컬 애플리케이션만큼 편리하지는 않지만 서비스를 자랑하는 서비스를 구현하는 것은 쉽지 않습니다.
분산 거래라는 개념을 들어보셨을 것입니다. 두 가지 시나리오가 있습니다. 하나는 하나의 애플리케이션에서 여러 데이터베이스를 사용하는 것입니다. 데이터 일관성을 보장하려면 분산 트랜잭션을 사용해야 합니다. 우리 아키텍처와 관련된 또 다른 상황이 있습니다. 특히 마이크로서비스 환경의 분산 트랜잭션은 비유를 사용합니다. 구매 및 보관 작업은 창고 관리 서비스에서 설계됩니다. 창고에 보관한 후에는 조달 하위 시스템의 구매 오더에 있는 창고 수량을 업데이트해야 합니다. 이 프로세스에는 데이터 일관성이 필요합니다. 즉, 구매 주문이 성공적으로 창고에 들어간 후 수량이 재고 테이블에 기록되고 동시에 구매 주문 테이블에 입력된 수량을 업데이트해야 합니다. 창고 서비스에서는 조달 서비스의 데이터베이스에 직접 접근할 수 없으며, 조달 서비스에서 제공하는 서비스 인터페이스를 사용해야 합니다. 그렇다면 데이터 일관성을 어떻게 보장할 수 있을까요? 재고 테이블이 성공적으로 작성되었지만 구매 주문 데이터를 작성하기 위한 조달 서비스 호출이 실패할 가능성이 매우 높기 때문입니다. 네트워크 문제로 인해 데이터가 일치하지 않는 경우도 있습니다.
분산 트랜잭션 기술에는 최종 일관성을 달성한다는 말이 있습니다. 이는 양측의 데이터가 궁극적으로 일관성이 있다는 것을 보장할 수 있는 한 괜찮으며 트랜잭션을 사용할 필요가 없다는 의미입니다. 그래서 계획이 있습니다. 예를 들어 창고 하위 시스템이 구매 및 창고 보관을 처리할 때 창고 주문 데이터를 추가하고 재고 데이터 및 기타 테이블을 업데이트해야 합니다. 이러한 여러 테이블은 모두 웨어하우스 하위 시스템에 있습니다. 로컬 트랜잭션을 사용하여 웨어하우스 하위 시스템에서 테이블 데이터의 일관성을 보장할 수 있습니다. 그런 다음 조달 하위 시스템을 호출하여 구매 주문서의 창고 수량을 업데이트합니다. 이 프로세스가 갑자기 중단되어 호출이 실패하는 것을 방지하기 위해 ActiveMQ와 같은 메시지 큐 미들웨어를 추가하는 것을 고려합니다. 인터페이스가 반환되지 않으면 조달 하위 시스템이 정상으로 돌아온 후 MQ는 업데이트 작업을 처리하도록 조달 하위 시스템에 알립니다. 메시지가 소비된 후에는 더 이상 알림이 발생하지 않으므로 조달 하위 시스템 처리 중 예외가 발생하여 업데이트가 실패하게 되었습니다. 후속 보상을 위해 관리자에게 알리려면 해당 문제를 로컬 로그 라이브러리에 기록해야 합니다. 처리. 이러한 방식으로 데이터의 최종 일관성을 달성하기 위해 다양한 방법을 사용할 수 있습니다. 다소 혼란스럽게 들리더라도 이것이 해결책입니다. 더 좋은 것은 없습니다. 또는 업데이트가 실패한 후 창고 하위 시스템을 다시 호출하여 창고 영수증 및 재고 데이터를 롤백하여 최종 일관성을 달성하세요! 그림과 같이:
저희가 성장하고 발전할 수 있었던 것은 바로 여러분과 지식과 경험을 공유할 수 있어서 매우 영광입니다. 아무것도 쓸 시간이 없습니다. 때로는 게으르거나 모든 사람과 공유할 새로운 것이 없기 때문입니다. 마지막으로, 저의 나눔에 있어서 부족한 점을 모두가 비판하고 고쳐주어 함께 발전할 수 있기를 바랍니다!
위 내용은 유통 및 서비스 ERP 시스템 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
