This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Architecture

System architecture documentation and component diagrams

Kiến trúc hệ thống

Sơ đồ thành phần hệ thống

Hệ thống gồm các dịch vụ chính như:

  • Collector Service: cung cấp chức năng quản lý thu thập dữ liệu.
  • OAuth2 Server: cung cấp tính năng xác thực, phân quyền, giao diện đăng nhập, v.v..
  • Patient Medical Records (TODO: review tên): cung cấp api truy cập dữ liệu nhận từ các đơn vị y tế.

Ngoài ra, còn có các dịch vụ:

  • Identity Management Service: dịch vụ hỗ trợ mã hóa nhiều lớp và lưu trữ định danh người dùng
  • Encryption Service: dùng để tăng cường lớp mã hóa cho các dịch vụ lưu trữ dữ liệu quan trọng, hoặc cung cấp tính năng mã hóa cho các dịch vụ chưa có tính năng này
  • Event Store: hỗ trợ API nhận dữ liệu từ các dịch vụ trong hệ thống hoặc bên ngoài hệ thống như các đơn vị y tế. Dữ liệu có thể được lấy từ các cơ sở dữ liệu, API, cảm biến v.v..
  • Error Tracking Service: là một Event Store được dùng để thu thập dữ liệu lỗi từ các dịch vụ
  • API Explorer: là dịch vụ cung cấp tài liệu về API nhằm hỗ trợ các bên công tác thứ 3 có thể sử dụng API hệ thống được dễ dàng.
  • SMS Service: cung cấp chức năng gửi, nhận tin nhắn từ một số đầu số được cải đặt trước
  • Analysis Service: …. ??? (TODO: bổ sung)

Xác thực và phân quyền

Authenticate&Authorization

Khi triển khai kiến trúc Microservice thông thường sẽ có hai cách hiện thực phân quyền:

  • Cách 1: Chia các dịch vụ thành 2 loại (Micro và Edge/Backend-for-Frontend), phân quyền được thực hiện ở các service thuộc loại Edge, các Micro cung cấp API (nội bộ) không yêu cầu xác thực
  • Cách 2: Mỗi service (trừ một số service đặc biệt) sẽ tự quản lý phân quyền.

Hệ thống này được hiện thực theo cách 2 - Mỗi service tự phân quyền, do đó cần có IAM để hỗ trợ các service trong việc xác thực người dùng

IAM (Identity Access Management) nắm giữ các định danh của toàn bộ các đối tượng (user, service, command…) cùng với các bộ luật phân quyền chi tiết cho từng loại tài nguyên.

Việc mỗi service phải tự thực hiện việc xác thực, phân quyền sẽ làm tăng chi phí khi xây dựng các service, ngoài các nghiệp vụ chính thì cần thêm lớp middleware để giao tiếp với IAM.

OAuth2

oauth2_openid_code

Tài liệu tham khảo

1 - Deployment

Documentation for system deployment and configuration

Tài liệu triển khai hệ thống

Mã nguồn tất cả các dịch vụ được lưu trữ trong các project tại GitLab.com Theo mặc định các dịch vụ sẽ được đóng thành docker image lưu trữ trên GitLab Docker Registry tại mỗi Project để chờ deploy.

Phương thức triển khai

Có nhiều phương thức triển khai các dịch vụ, có thể sử dụng một hoặc nhiều phương thức triển khai tùy theo dịch vụ, một số phương thức cơ bản có thể liệt kê gồm:

  • Clone mã nguồn từ Git Repository và build theo hướng dẫn ở từng project, cách này yêu cầu người triển khai phải hiểu cách cách cấu hình build, đóng gói (nếu có), và cấu hình biến môi trường để triển khai dịch vụ
  • Sử dụng Docker để triển khai
    • Sử dụng Docker Image đã đóng gói và lưu trữ GitLab Docker Container Registry để triển khai trên các môi trường hay nền tảng hỗ trợ Docker, cách này chỉ cần cấu hình các biến môi trường để triển khai dịch vụ, đây là phương thức triển khai trên môi trường production.
    • Sử dụng Docker Compose cấu hình sẵn (DOING), đây là cách dễ thực hiện nhất, và hướng tới sử dụng cho mục đích demo.

Triển khai trên môi trường cục bộ

Môi trường triển khai này dùng cho mục đích thuyết minh (demo), phát triển (development) do đó hướng tới triển khai đơn giản, nhanh và không yêu cầu tính ổn định và khả năng chịu lỗi' Yêu cầu cần có để triển khai

  • 1 máy tính ảo/vật lý
  • Docker và Docker Compose được cài đặt sẵn

Triển khai IOH

Để triển khai IOH, thực hiện các bước sau theo thứ tự

  1. Mở gói phần mềm đã được cung cấp (gồm mã nguồn và cấu hình triển khai có sẵn)
  2. Gọi lệnh docker-compose để chạy
  3. Truy cập http://localhost:1000 với tài khoản được đính kèm trong gói phần mềm

Để tùy chỉnh nâng cao, xem tài liệu triển khai ở từng dịch vụ

Quy trình triển khai cho môi trường production

Môi trường production sử dụng một Kubernetes Cluster, gồm ít nhất 3 master (stacked master + etcd) nhầm đảm bảo tính sẵn sàng. Cluster được liên kết với GitLab và sử dụng quy trình triển khai Auto DevOps của GitLab là quy trình mặc định để triển khai dịch vụ. Quy trình này được kích hoạt mỗi khi có thay đổi ở GitLab project, thường là ở nhánh master. Quy trình gồm các giai đoạn sau:

  1. Build. Ở giai đoạn này, GitLab sẽ tự động kiểm tra cấu hình Dockerfile và build Docker Image từ Dockerfile trong project xác định
  2. Test. Ở giai đoạn này, GitLab sẽ kích hoạt lệnh test tương ứng với một số cấu hình, ngôn ngữ của mã nguồn.
  3. Staging. Đây là giai đoạn tùy chọn để triển khai lên môi trường staging được kích hoạt ở một số dịch vụ cần có các bước kiểm tra thêm trước khi đưa ra môi trường production
  4. Production. Đây là giai đoạn triển khai dịch vụ lên trên Kubernetes Cluster để người dùng sử dụng. Ở giai đọan này, GitLab sẽ kích hoạt triển khai Helm Chart mặc định là auto-deploy-app để triển khai Docker Image lên Kubernetes cluster kèm một số cấu hình khác như biến môi trường, cấu hình điều hướng từ Ingress, chứng chỉ TLS, Số lượng pod cần triển khai, lớp lưu trữ, v.v…

Sau khi triển khai lên môi trường production thành công, công việc còn lại của Operator là giám sát và điều khiển dịch vụ bằng giao diện điều khiển của Kubernetes.

Sơ đồ triển khai Kubernetes Cluster

Đây là sơ đồ triển khai Kubernetes Cluster với cấu hình High Available (sẵn sàng cao). Mô hình triển khai này nằm tăng tính ổn định của hệ thống, giảm thiểu khả năng tê liệt toàn bộ hệ thống khi một máy vật lý nào đó gặp lỗi hoặc máy vật lý cần tắt để thực hiện các thao tác bảo trì.

Kubernetes Cluster Hệ thống trên được triển khai trong mạng nội bộ nằm phía sau tường lửa chỉ mở port 80 và 443 để nhận kết nôi trừ bên ngoài ở địa chỉ IP xác định. Việc nhận request từ bên ngoài sẽ được đảm nhiệm bởi 02 Load Balancer cùng thay phiên nhau lắng nghe dữ liệu từ cổng công khai, 2 load balancer sẽ vận hành cơ chế health checking để kiểm tra trạng thái hiện tại lẫn nhau. Nếu Load Balancer ở chế độ Active gặp trục trặc, thì Load Balancer còn lại đang ở chế độ Passive sẽ chuyển qua chế độ Active để lắng nghe dữ liệu và vận hành thay thế cho Load Balancer gặp trục trặc có thời gian phục hồi.

Kubernetes Cluster được điều khiển bởi các node Master, để tăng tính ổn định ta cần scaling các node Master này lên, các node Master sẽ kết nối với nhau bằng port :6443 của Load Balancer.

Worker node là các node là nhiệm vụ xử lý chính, đây là nơi các service được triển khai vào cluster hoạt động. Tùy theo nhu cầu xử ý mà ta scale các worker node với số lượng phù hợp. Các worker node kết nối với master thông qua port 6443 của Load Balancer

Sơ đồ triển khai các dịch vụ (Deprecated)

TODO: Review Deployment

  • Sơ đồ thể hiện sự phân luồng dữ liệu dữ liệu đi vào hệ thống gồm loại giao thức và các thành phần tiếp nhận.

  • Sơ đồ liệt kê các thành phần khi triển khai hệ thống.

  • Các kết nối là 2 CHIỀU (request/response) chiều mũi tên là chiều request từ dịch vụ yêu cầu tài nguyên đến dịch vụ cung cấp tài nguyên, chiều ngược lại là chiều response. sơ đồ KHÔNG sử dụng kết nối 1 chiều.

  • Màu:

    • Xanh lá: các thành phần đã được triển khai
    • Vàng: các thành phần đã hiện thực nhưng chưa triển khai
    • Đỏ: Các thành phần chưa hiện thực hoặc đang thiết kế