API as a services P1 - Project requirement và system architect

Nếu như bài viết đầu tiên của series Microservices thực chiến - Chuyển đổi từ monolith sang microservices qua ví dụ chia sẻ về quá trình chuyển đổi từ monolith sang microservices, thì blog này giới thiệu một dự án từ giai đoạn ý tưởng/ yêu cầu, thiết kế kiến trúc, coding đến deploy xoay quanh kiến trúc microservices, từ đó nhìn nhận các khó khăn trong quá trình phát triển dự án với kiến trúc microservices và hướng khắc phục.

Project requirement

Ý tưởng ban đầu là xây dựng một trang thương mại điện tử trên nền microservices, nhưng để full flow với hệ sinh thái đầy đủ từ warehouse, product, order, khuyến mãi, shipping, accounting, shop, supplier ... sẽ là hơi over cho một sự bắt đầu.

Vậy nên mình làm một ứng dụng đơn giản hơn chút. Business của mình sẽ là application dạng API as a service - Cung cấp dịch vụ qua API. Để dễ hiểu hơn, bạn có thể nghĩ đến các dịch vụ của Google dành cho nhà phát triển như: bản đồ, notification, xác thực số điện thoại ... - một số ví dụ điển hình của API as a service.

Mô hình kinh doanh của ứng dụng đã có rồi, vậy sẽ phục vụ nhu cầu gì của thị trường bây giờ? Vài năm trước có một người em nhờ mình tư vấn về giải pháp xác định đơn vị hành chính (phường/ xã, quận/ huyện, tỉnh/ thành phố) dựa trên input là location (longtitude, latitude). Use case ở đây là các thiết bị có hỗ trợ GPS gửi location về máy chủ, từ đó máy chủ cần detect được location theo đơn vị hành chính để thực hiện những business tiếp theo. Ví dụ:

• Thiết bị thông minh/IoT có kết nối wifi/GPS cần gửi các thông số thiết bị về máy chủ, đi kèm là dữ liệu vị trí, xác định được đơn vị hành chính mới có thể phân phối thông tin đến các bộ phận chăm sóc khách hàng, bảo hành ở đúng khu vực một cách tự động.
• Các doanh nghiệp logistic cũng cần một mapping từ các văn phòng/ kho hàng của họ đến các địa điểm lấy hàng của khách đề điều chuyển resource một cách hợp lý.

Vậy là đã xác định được core business của dự án, cùng điểm qua một số specification:

• Business cung cấp khả năng xác định đơn vị hành chính (xã/phường - quận/huyện - tỉnh/ thành phố) từ vị trí GPS (*)
• Mô hình kinh doanh API as a service, khách hàng sẽ trả phí để để có một lượng request nhất định
• Hệ thống đo được lượng request của khách để giới hạn nếu đã hết quota
• Dịch vụ có khả năng tích hợp API vào hệ thống của khách hàng.

(*) Trong series bài viết này mình không đi sâu vào phần core function của sản phẩm mà trập trung vào cách triển khai và sự liên kết giữa các phần trong dự án. Phần core function của dự án mình sẽ lướt qua nhé, coi như đã có giải pháp cho phần đó rồi

Research

Cùng lượn qua thị trường một chút trước khi bắt tay vào việc. Mình đã từng tham gia một dự án về công nghệ bản đồ nên cũng có hiểu biết chút về mảng này. Một vài bên có dịch vụ tương tự mình định làm là Google Map và Mapbox, sang bên đó tham khảo xem dịch vụ họ đang cung cấp như thế nào.

Về cơ bản thì dịch vụ mình định làm khá giống geocoding của Google và Mapbox. Dịch vụ của họ hỗ trợ chuyển đổi từ Geo location sang địa chỉ dạng text hoặc ngược lại.

Đánh giá dùng thử dịch vụ

Dữ liệu của Google sát hơn với yêu cầu mà mình vừa đề ra ở trên, với các trường dữ liệu rõ ràng phân chia theo level của đơn vị hành chính (level 1 - n). Nhưng vẫn có những nhược điểm như:

• Request 1 điểm mà kết quả dữ liệu trả về 1 mảng,
• Mỗi kết quả trong mảng lại có các level về đơn vị hành chính không đồng nhất (có kết quả có phường - quận - thành phố, nhưng cũng có những kết quả chỉ có quận - thành phố, ...)
• Không có loại đơn vị hành chính mà chỉ có level
• Giới hạn request cho bản dùng thử rất thấp ở khu vực Việt Nam (3-4 request/day)

Pricing

Pricing của mỗi bên, khảo sát qua tí để đưa ra mức giá phù hợp

Brainstorming

Từ các spec chính đã nêu ở trên, cùng đi chi tiết hơn một chút. Nhìn từ góc độ khách hàng và hệ thống để xem mỗi bên sẽ ứng xử như thế nào để yêu cầu và đáp ứng được dịch vụ.

• Khách hàng tiếp cận dịch vụ như thế nào?
• Làm sao để dùng thử được dịch vụ trước khi quyết định mua hàng?
• Làm sao để giới hạn số lượng request của khách.
• Làm sao để khách hàng trên toàn thế giới có thể thanh toán tiền cho hệ thống?
• Trang portal của khách sẽ có những tính năng gì?

User flows:

• User sử dụng thử chức năng geo location to administrative location trên trang example
• User đăng ký tài khoản và verify account.
• User xem hướng dẫn sử dụng dịch vụ
• User tạo api key
• User tích hợp API vào hệ thống
• User nhận được mail báo lượng request usage và thanh toán cho hệ thống

System flow:

• Hệ thống đếm và lưu lại số lần request của khách hàng
• Hệ thống verify request của khách hàng
• Hệ thống xử lý request và trả về kết quả
• Hệ thống tính lượng request của khách để đưa ra bill thanh toán theo chu kỳ
• Hệ thống gửi mail thanh toán đến email của khách hàng
• Hệ thống theo dõi tình trạng hóa đơn của khách hàng để đưa ra quyết định

Phần feature sẽ có thể rất rộng, ở đây mình chỉ hình dung các flow chính để thiết kế hệ thống cho phù hợp.

System architect

Vậy là đã tạm đủ dữ liệu để hình dung ra bước tranh tổng thể của dự án này rồi. Giờ là lúc lên kiến trúc cho dự án

Logical

Microservices responsibility

• Admin site: Trang quản trị hệ thống
• Client site: Trang portal chính mà khách hàng sẽ tương tác
• Backend gateway: Gateway cho hệ thống backend phía sau
• User authentication: Service xác thực định danh của khách hàng
• Billing service: Service thực hiện việc thanh toán, các nghiệp vụ liên quan đến charge tiền khách hàng,
• CRM service: Quản lý khách hàng, Subscription, Controller chính của hệ thống backend
• Report service: Chứa log, phân tích số liệu request của hệ khách hàng
• Geo service: Core service thực hiện các functional liên quan đến geo-location
• Integration API gateway: Gateway cho Geo-service, vì đặc trưng của hệ thống là API as a service nên phải có gateway riêng cho các API dịch vụ expose ra cho khách hàng sử dụng
• API key authentication: Service riêng authenticate các API dịch vụ và trigger request event để limit số lượng request của khách hàng
• Message queue: Hệ thống microservice không thể thiếu được thành phần này, đóng vai trò là kênh giao tiếp bất đồng bộ và xử lý các nghiệp vụ bắt buộc dùng queue
• Notification: Các chức năng liên quan đến gửi thông báo, email...

Một product đưa ra kinh doanh còn phải kể đến các trang static content như branding site, documentation site, nhưng vì không giao tiếp trực tiếp với các thành phần còn lại nên mình sẽ không đề cập.

Tech stack

Architect bao gồm các thành phần Frontend, Backend, Message Queue, API Gateway, Database. Bạn có thể lựa chọn stack phù hợp với bản thân:

• Backend Services: Java Spring
• Frontend: Angular
• Message queue: Kafka
• API gateway: Spring gateway
• Database: Mysql

Database nên triển khai theo mô hình Database per service, lúc đầu có thể thấy phiền phức vì nhiều DB phải maintain, nhưng sẽ không gặp phải tình trạng bottle neck nếu một service nào đó sử dụng nhiều tài nguyên database, chưa kể đến khả năng phát triển độc lập các service, security.

Kết

Project này thể hiện được một phần các thành phần của kiến trúc micorservice, với project khác có thể triển khai kết hợp với nhiều stack, concept hơn nữa. Các service cũng có thể được tách nhỏ hơn nữa tùy điều kiện.

Bài viết sau mình sẽ triển khai break chi tiết một vài requirement để làm story và đưa vào triển khai trên phạm vi team.

Powered by Sunteco Cloud

Những bài viết trong series Microservices thực chiến:

• API as a service P1 - Project requirement and system architect
• API as a service P2 - Break story and development strategy
• API as a service P3 - Setup environment and develop flow
• API as a service P4 - Coding
• API as a service P5 - Các vấn đề thường gặp khi triển khai microservice
• API as a service P6 - Release production