search

TheOpenCloudEngine / uEngine-cloud

OCE's main component includes : PaaS (Self-service) Portal, Dev-ops, Cloud orchestrator. Also includes microservices-architecture components: Identity & Access Management conforming to OAuth2 and JWT spec and Zuul-based API proxy that interacts with IAM and the service registry (Eureka).
http://uengine.org/products/pass
MIT License
31 stars 21 forks source link

Real SaaS Deployment and Operation Case #94

Open jinyoung opened 6 years ago

jinyoung commented 6 years ago

플랫폼 검증을 위한 다음의 실제 운영 사례 구축:

  1. Case
    • BPM 기반 Chatbot 서비스
  2. 대상 Microservices 및 Stack:
    • Process Service --> Definition Service
    • Process Service --> Order Service
    • Process Service --> Semantic Entity Service
    • Process Service ==> mysql
    • Process Service ==> kafka
    • Zuul Router --> Process Service
    • Zuul Router --> IAM
    • Zuul Router ==> gitlab
    • Front-end --> Zuul Router

아래는 현재 테스트 범위에서 벗어나지만 향후 이들도 Stack 으로 관리해야 함

  1. 기대하는 시나리오
    • Dev-Staging-Prod 간 무정지 재배포
    • 자동화된 테스트: Dependency Service 들을 하나씩 기동할때, 이들이 Valid한지 테스트 : 테스트 스크립트는 현재 httpie 로 되어있음:

예시:

http POST http://uengine5-router-dev.pas-mini.io/service defId="chatbotMain.xml" path="e-shop/message" correlationKey="user_key"

http POST http://uengine5-router-dev.pas-mini.io/service defId="keyboard.xml" path="e-shop/keyboard" correlationKey="user_key"

http http://uengine5-router-dev.pas-mini.io/semantic-entity/entity-value expression=="장진영입니다" entity-type=="NNP"
http http://uengine5-router-dev.pas-mini.io/services/e-shop/message content="2" user_key="a"
http localhost:8080/service defId="RPA-main.xml" correlationKey="user_key" path=“message"
http localhost:8080/services/message content="2" user_key="a"

Issues:

  1. Stack 단위 배포 : Compose.yml 호환성 작업과 관계됨
  2. 프로세스 정의 변경시 정의 파일의 배포 : 현재 도커 마운트 파일시스템이 Dev 에 붙어있음. 이것이 Prod 로 갈때에 Dev 의 프로세스 정의 파일들이 같이 배포 되어야 하는데, 두가지 방안이 있음:
    • uEngine 이 사용하는 파일 시스템을 분산파일시스템으로 전환 (S3 계열 ?)
    • 도커 기반 시스템 파일 시스템 (이름이??) 으로 (기존 Local File System 기반 Strategy 그대로 사용 (LocalFileStorage.java)
  3. Prod 인스턴스 DB 의 유지 : Dev, Prod 의 Database Connection String 주입을 통한 운영 Dev 는 주입값이 없이 H2 DB를 사용, Prod 는 MySQL 사용
  4. API Versioning : Definition Service 와 Process Service 가 분리되어있는데, 예를 들어 Process Service v2 -> Definition Service v1.1 이상 사용이라고 하면, EUREKA Service Registry 에서 알아서 Definition Service v1.1 이상을 검색하여 연결되어야 함 (Ribbon 과 Feign 의 intrinsic 한 동작)
    • 이때 어떤 Consumer 서비스 (여기서는 Process Service) 의 입장에서 참조하는 서비스의 버전을 지정하는 방법으로 활용할 수 있는 기존 방법으로 OSGi 의 참조 표현 방법과 npm 의 package.json 참조 방법을 이용할 수 있다:
    • OSGI 의 Semantic Versioning 과 Version Reference 방법 : http://blog.christianposta.com/osgi/understanding-how-osgi-bundles-get-resolved-part-i/ 
      Import-Package: com.acme.foo;version="[1.23, 2)", // foo 디펜던시는 1.23 이상 ~ 2 미만 버전을 참조
com.acme.bar;version="[4.0, 5.0)" // bar 디펜던시는 4.0 이상 5.0 미만 버전을 참조
jinyoung commented 6 years ago

이게 process service의 application.yml 라 가정하고

API 참조 방법 예시:

@FeignClient(serviceId="definition", version="[1.0,2.0)")

혹은

application.yml 에서

eureka:
   metadata:
        version:  1.1   # 나의 버전

ribbon:
    reference-versions:
         definition:        # definition service 의 참조는 1.0 이상 ~ 2.0 미만
               more-than: 1.0
               below: 2.0
         semantic-entity:       # semantic-entity service 의 참조는 정확히 1.1
               exactly: 1.1
         order:         # order service 의 참조는 1.1 이상
               more-than: 1.1
jinyoung commented 6 years ago

컴포넌트 버저닝에서나 Semantic Versioning 이 필요할듯, 그냥 모든 마이크로서비스는 설계 속성의 "자치성"에서 그 단위에서 항상 backward compatibility 를 준수하는 것이 맞느거 같고, API versioning 만 잘하면 될것 같음... 따라서 발생하는 문제는, 호출 API의 업글됐을때 새버전은 새버전끼리의 API로 놀아야 하므로... API versioning style 을 어째할것인가가 문제가 되네... 플랫폼에서 할건 없고 Application 만들때 이를 준수하여 만드는걸로 하는게 맞겠음

SeungpilPark commented 6 years ago

유엔진 클라우드2.0