퍼블릭 클라우드 SAAS 제품은 기존 소프트웨어 패키지 제품과 다릅니다. 소프트웨어 R & D뿐만 아니라 제품 운영 및 유지 관리도 책임 져야합니다. 많은 사용자가 직면 한 상황에서 제품 7X24, 고객의 중단없는 운영을 보장해야합니다. 비즈니스는 지속적으로 변화하고 있으며 제품 요구 사항은 고객 비즈니스의 끊임없이 변화하는 요구 사항을 충족하기 위해 지속적인 운영 중에 지속적으로 업그레이드됩니다. 기존 소프트웨어 패키지 제품에 비해 퍼블릭 클라우드 제품의 업그레이드는 스포츠카의 타이어를 교체하는 것과 유사하게 더 복잡하고 위험합니다.
디자인의 본질은 제품 변경을 더 쉽게 만드는 것입니다. 마이크로 서비스 아키텍처는 급격한 비즈니스 변화에 적응하기 위해 인터넷 시대에 등장한 아키텍처 모델이며 변경을 쉽게 할 수있는 기반을 제공합니다. 2014 년부터 업계의 많은 관심을 받고 있으며, 최근 DevOps 기술의 성숙과 함께 마이크로 서비스 아키텍처 모델은 점점 더 많은 기업에서 실행되고 적용되고 있습니다. 마이크로 서비스 아키텍처는 독립 개발, 독립 배포, 독립 확장, 독립 운영 및 유지 보수가 특징입니다. 기술적으로 공짜 점심이 없습니다. 마이크로 서비스는 많은 이점을 제공하지만 DevOps 복잡성, 분산 시스템 복잡성을 포함한 많은 복잡성을 가져옵니다. 등 제품 설계 아키텍처를 개선하고, DevOps를 자동화하고, 고품질 도메인 모델을 구축하는 등 적절한 분석 및 설계 방법, 도구 및 프로세스를 채택하여 마이크로 서비스 아키텍처의 이점을 극대화하고 마이크로 서비스 아키텍처의 부정적인 영향을 줄여야합니다.
제품을 연구하고 개발할 때 먼저 시장 수요 배경을 조사하고 전국에 많은 중소기업이 있습니다. 전형적인 특징은 대규모, 단일 기업의 상대적으로 소규모 비즈니스 볼륨, 시스템 관리 및 유지 보수를 담당하는 특별한 사람이 없으며 전반적인 IT 수준이 낮아 특히 SAAS 서비스 모드의 적용에 적합합니다. 최근 몇 년 동안 클라우드 컴퓨팅 기술의 발달로 사회에서 수많은 상업 비즈니스 혁신이 등장했으며 전자 결제, 전자 클라우드 창고 및 전자 송장과 같은 상업 인프라가 상업 애플리케이션으로 이동했습니다. 중소기업에서 사용하기 위해 사회에 나타나는 일부 상업 인프라를 통합하는 방법은 무엇입니까? 따라서 SaaS 서비스는 많은 소규모 및 소규모 기업을위한 유일한 선택이되었습니다.
문제 분석시 고객군을 명확히하고 다수의 중소기업, 산업 및 상사, 상사 및 제조업체를 대상으로하는 것이 필요하다. 단일 기업의 사업은 복잡하지 않지만 복잡한 문제이다. 동시에 여러 기업을 만족시키는 제품을 만들 수 있습니다. 또한 클라우드 제품으로서 제품이 항상 7x24 시간 내에 실행되는지 확인해야하며, 항상 실행되는 제품을 업그레이드하고 유지 관리하는 것도 고위험 활동입니다.
위의 문제점과 배경을 바탕으로 대규모 동시 사용자의 니즈를 지원하는 제품 아키텍처, 지속적이고 빠른 진화를 지원하는 모델 및 아키텍처, 제품 개발을 통해 기업의 기본 비즈니스 역량을 축적하는 등 몇 가지 설계 목표를 제안합니다. , 그리고 미래의 새로운 제품의 빠른 개발을 위해 축적됩니다.
디자인 목표를 바탕으로 다음과 같은 일반적인 아이디어를 명확히했습니다.
첫 번째는 디자인을 중시하는 것, 디자인은 제품의 미래이며, 좋은 디자인 만이 고객의 비즈니스 성장의 길로 나아갈 수 있습니다. 두 번째는 타사 기술을 최대한 활용하고 자체 전문 분야에 집중하는 것입니다. 세 번째는 시간과 자원이 제한되어있을 때, 향후 자원을 사용할 수있을 때 시스템이 발전 할 수 있도록 단순히 우려 사항을 분리하고 구현하는 것입니다. 네 번째는 도메인 세분화 및 분리를 위해 DDD 방법을 사용하는 것이며, 마이크로 서비스는 비즈니스의 통합을 완전히 보장합니다. 마지막으로 가장 비즈니스 시스템 인 도메인 모델은 핵심이자 유전자이며 향후 비즈니스 진화를 지원하는 기반이되며 도메인 모델의 품질이 향상되고 모델 디자인이 적절하게 발전합니다.
SAAS 제품은 전문적으로 개발되었으며 많은 기술 스택과 기능을 포함합니다. 프런트 엔드와 백 엔드는 독립적으로 개발 된 완전히 다른 기술 스택을 사용합니다. 또한 많은 사용자의 요구에 부응하는 제품으로서 커스터마이징이 기본 기능이고 프론트 엔드 및 백엔드 플랫폼이 제품의 기본 기능입니다. 이에 따라 R & D 조직은 제품, UI / UE, 프런트 엔드, 백 엔드, 테스트, 운영 및 유지 관리, 비즈니스 운영과 같은 여러 소규모 팀으로 나뉩니다.
R & D 팀은 여러 그룹으로 나뉘며 각 그룹은 서로 협력합니다. 서로 다른 팀 간의 효율적인 협력을 보장하는 방법, 완전한 사양 및 표준은 필수 불가결하며 전체 R & D 라이프 사이클의 사양을 구현하면 작업 품질과 협업 효율성을 효과적으로 제공 할 수 있습니다.
마이크로 서비스 아키텍처 모델은 이점을 제공하지만 DevOps의 복잡성도 가져옵니다. 자동화 된 운영 및 유지 관리 프로세스의 설정은 마이크로 서비스 아키텍처를 사용하기위한 필수 조건입니다. 회사의 제품 개발 및 출시 프로세스를 기반으로 적절한 지점 계획, 제품 관리 계획, 지속적 통합 계획 및 환경 관리 계획을 개발합니다.
-
분기는 개발, 테스트 및 릴리스 분기로 구분되며 개발, 테스트 및 릴리스를 공간적으로 분리합니다.
-
개발자는 개발 브랜치에서 최신 버전을 다운로드하고 빌드가 성공한 후 Nexus에 릴리스하고, Nexus의 스냅 샷 패키지를 자동 작업을 통해 "자동 테스트"환경에 게시 한 다음 환경에서 자동 통합 테스트를 수행합니다.
-
자동 테스트가 성공하면 빌드 된 패키지를 개발 환경에 게시합니다.
-
개발 환경에서 개발자는 수동 확인 및 확인을 완료합니다.
-
수동 확인이 완료되면 자동 작업이 구동되어 개발의 콘텐츠를 테스트 분기로 병합 / 리베이스하고 테스터는 수동으로 jenkins 작업을 실행하여 통합 테스트 환경에 릴리스 패키지를 릴리스하는 프로세스를 완료합니다.
- 운영 및 유지 관리 담당자는 그레이 스케일 배포를 지원하고 새 버전 제공의 위험을 줄이는 프로덕션 환경을 유지 관리 할 책임이 있습니다.
마이크로 서비스 아키텍처의 사용은 새로운 기술적 접근 방식 일뿐만 아니라 해당 분석 및 설계 방법의 지원을받지 않으면 득보다 해를 끼칠 것이며 한 화재 구덩이에서 다른 구덩이로 뛰어 오르는 당황 스러울 것입니다. 비즈니스 모델링, 시스템 모델링, 도메인 모델링 및 물리적 모델링에서 단계별 설계를 수행하여 마이크로 서비스 설계의 품질을 향상시키고 제품이 향후에도 계속 발전 할 수 있도록해야합니다.
분석 및 설계에는 도구, 방법 및 프로세스가 포함됩니다. 도구의 제조 및 사용은 인간 사회를 다른 동물과 구별하는 특징이며 적절한 도구를 사용하면 분석 및 설계의 효율성과 품질을 크게 향상시킬 수 있습니다. 분석 및 설계 도구는 EA를 사용하고 DB 모델링 도구는 ERWin을 사용합니다. 그 방법은 업계의 모범 사례를 모으는 것이고, 영역 중심의 디자인 방법은 객체 지향적 사고의 복귀와 승화입니다. 영역 중심의 디자인을 올바르게 습득한다는 전제는 객체 지향 디자인 기술입니다. DDD는 객체 지향 설계의 가장 중요한 원리이며 소프트웨어 구조는 문제의 구조를 반영합니다. DDD 분석 방법은 비즈니스를 분석 및 설계하는 데 사용되며 분석 및 설계 프로세스에는 비즈니스 모델링, 시스템 모델링, 도메인 모델링 및 물리적 모델이 포함됩니다.
복잡한 시스템의 경우 시스템의 외관은 상상하기 어렵고, 시스템의 외관을 얻기 위해서는 공학적 방법 분석, 즉 비즈니스 모델링 방법의 분석을 통해 얻어야합니다. 비즈니스 모델링은 전체 조직을 연구 대상으로 삼고, 일반적인 비즈니스 시나리오를 선택하고, 조직에 포함 된 역할과 시스템을 식별하고, 시스템을 블랙 박스로 취급하고, 조직의 역할과 시스템이 어떻게 협력하여 완료되는지 분석하는 것입니다. 비즈니스 가치를 외부로 내 보냅니다.
비즈니스 모델링 후 시스템의 외관을 파악한 다음 시스템 모델링을 사용하여 시스템에서 구성되는 구성 요소 또는 모듈을 분석합니다. 세분화 모듈의 목적은 문제를 분리하고 시스템 복잡성을 줄이는 것입니다. 시스템은 모듈로 분해되며, 이러한 모듈이 서로 협력하여 시스템 외관에 필요한 기능을 충족시키는 방법, 이것이 시스템 시리즈 다이어그램입니다. 복잡한 시스템의 경우 모듈 간의 협력을 분석하여 각 모듈의 모양을 얻을 수 있습니다.
비즈니스 세계는 겉으로는 복잡하고 내면의 본질은 비교적 안정적이며, 도메인 모델링의 목적은 복잡한 현상과 외형을 통해 사물의 본질에 대한 통찰력을 얻는 것입니다. 도메인 모델은 또한 기업이 비즈니스에 포함 된 개념과 제품을 설계 할 때 이들 간의 관계를 명확히하는 데 도움이되는 비즈니스 세계를 보는 방법이기도합니다. 도메인 모델은 비즈니스 기능 (외관)이면의 비즈니스 본질을 표현한 모델이며, 도메인 모델은 안정성이 높은 지식 수준 모델로 온라인 시스템 비즈니스 변화를 지원합니다.
물리적 모델은 도메인 모델의 관계식 표현이며 물리적 테이블을 지향합니다. 테이블을 구축하고 변환 도구를 사용하여 테이블을 기반으로 코드를 생성하여 디자인 된 모델이 단순히 종이에 표시되거나 벽에 걸려있는 것이 아니라 진정으로 개발을 주도 할 수 있도록합니다.
SaaS 제품 구현 계획에 따라 테넌트 모드, 계층화 된 설계, 애플리케이션 아키텍처, 전체 기술 아키텍처, 모듈의 기술 아키텍처, 마이크로 서비스 아키텍처 및 분산 형 제품에 대한 일관된 솔루션과 같은 여러 가지 중요한 기술 옵션이 포함됩니다. 환경.
테넌트 모델은 무엇입니까? SaaS 제품은 애플리케이션, 가상 머신 및 DB의 세 가지 리소스 리소스를 사용해야합니다. 가상 머신, 어플리케이션, DB의 용도에 따라 서로 다른 모드로 나뉩니다. 가상 머신 모델은 각 테넌트에 독립 가상 머신, 독립 애플리케이션 및 독립 DB가 있고 테넌트 리소스가 공유되지 않고 테넌트 간의 격리가 양호하지만 리소스 사용률이 낮음을 의미합니다. 테넌트 독립 DB 모드에서는 각 테넌트가 가상 머신과 애플리케이션을 공유하고 DB는 각 테넌트 전용으로 사용됩니다. 가상 머신 및 애플리케이션 리소스의 활용률은 높지만 DB 리소스 활용률은 낮습니다.
세 번째 모드는 테넌트 공유 DB 모드입니다. 가상 머신, 애플리케이션 및 DB는 모든 테넌트가 공유하며 높은 리소스 사용률, 테넌트 간 소프트 격리 및 열악한 격리를 제공합니다.
테넌트 수가 많고 부하가 고르지 않고 개별화 요구 사항이 높지 않은 중소기업의 경우 테넌트 공유 DB 모델을 채택하기로 결정했습니다.
복잡한 시스템의 경우 계층화 된 설계는 복잡성 문제를 해결하는 중요한 수단 중 하나입니다. DDD 방식을 채택하여 비즈니스 관점에 따라 시스템을 계층 적으로 설계합니다. 동일한 레이어간에, 상위 레이어와 하위 레이어간에 호출 할 수 있으며,주기 호출을 엄격하게 제어하고, 종속성의 복잡성을 제어 할 수 있습니다.
프런트 엔드와 백 엔드는 서로 다른 기술 스택을 채택하고 프런트 엔드와 백 엔드는 개별적으로 설계되고 독립적 인 부서에서 개발합니다. 백엔드는 애플리케이션 서비스 계층과 도메인 계층으로 나뉩니다. 애플리케이션 서비스 계층은 도메인 지식이 제공하는 서비스 기능을 사용하여 비즈니스 기능을 제공하고 특정 비즈니스 문제를 해결하는 것입니다. 도메인 계층에는 핵심 도메인 계층, 지원 하위 도메인 계층 및 일반 하위 도메인 계층이 포함되어 도메인 지식 서비스 기능을 제공합니다.
-
핵심 도메인 계층-고객의 핵심 비즈니스에 서비스를 제공합니다.
-
지원 하위 도메인 계층-비즈니스의 특정 측면을 지원하는 하위 도메인
- 공통 하위 도메인-전체 시스템에 사용되는 하위 도메인
기술적 관점에서 기능 계층 (일반 하위 도메인 서비스 포함, 하위 도메인 서비스 및 핵심 하위 도메인 서비스 지원)은 RPC를 통해 마이크로 서비스간에 호출합니다. 애플리케이션 서비스 계층은 RPC를 통해 도메인 서비스 계층을 호출합니다. 애플리케이션 서비스 계층은 프런트 엔드 NodeJS 인터페이스 서버에서 호출하는 REST를 통해 외부에 서비스를 게시합니다. 프런트 엔드 애플리케이션은 HTTP / HTTPS를 통해 NodeJS 서비스에 액세스합니다.
물리적 모델이 생성 된 후 물리적 모델과 플러그인을 기반으로 Repository 계층, 도메인 계층 및 Persistence 계층이 생성됩니다. 모델은 더 이상 벽의 장식이 아니며 모델을 만드는 코드에 의해 구동됩니다. 모델이 정말 떨어집니다. 지식 바인딩 방법은 빈혈 개체를 지식 조각에 바인딩하는 데 사용되며 빈혈 개체는 스마트 개체 (Smart Object)가됩니다. 실제로이 솔루션은 자동 코드 생성과 빈혈 및 혼잡 모델 간의 절충안입니다.
기존의 모 놀리 식 시스템과 달리 XA 트랜잭션은 분산 리소스 데이터 일관성 문제를 해결하는 데 사용할 수 있습니다. 분산 시스템 운영 시나리오에서 각 서비스는 서로 다른 프로세스에서 실행되고 각 프로세스는 독립적으로 실행됩니다. 비즈니스 일관성 유지는 복잡한 문제입니다. 이 시스템은 TCC의 강력한 일관성과 메시지 + TCC 호출에 기반한 최종 일관성이라는 두 가지 일관성 메커니즘을 제공합니다. 두 가지 일관성 메커니즘은 서로 다른 시나리오에 적용됩니다.
많은 비즈니스 시나리오에서 시스템은 고객 요청 후 일련의 복잡한 작업을 수행해야합니다. 이러한 작업 중 일부 작업은 즉시 실행 및 응답해야하며, 일부 작업은 높은 실시간 성능이 필요하지 않으며 응답 요청 후 처리를 위해 시스템으로 넘길 수 있습니다. 메시지 + TCC 기반의 최종 일관성 방법은이 시나리오의 일관성 메커니즘을 적용하는 것입니다. 시스템은 메시지를 통해 분리되고 비동기 작업이 수행되며 동시에 피크 셰이빙 및 밸리 필링 역할을하며 시스템 부하의 균형을 맞 춥니 다.
기존 소프트웨어 패키지 제품에 비해 클라우드 제품 업그레이드는 위험이 높은 활동입니다. 고품질 도메인 아키텍처와 유연한 도메인 모델을 설계하는 것은 클라우드 제품이 비즈니스 변화에 차분하게 대응할 수있는 기반입니다. 클라우드 제품 연구 개발 시스템을 구축 할 때 핵심 비즈니스 서비스 역량, 지원 비즈니스 서비스 역량, 일반 비즈니스 서비스 역량을 포함한 기본적인 기업 비즈니스 서비스 역량을 구축하면 후기 제품 개발주기를 크게 단축 할 수 있습니다. 이러한 기본 서비스 역량은 회사의 빠른 비즈니스입니다. 혁신.