Microservice thực chiến - API as a service P1 - Project requirement and system architect

Mở đầu 

        Hi các bạn, sau khi bài viết trước nhận được khá nhiều sự quan tâm, mình quyết định sẽ tiếp tục việc chia sẻ trải nghiệm của mình với microservice cũng như mong muốn nhận được những góp ý từ phía mọi người. Nếu như bài viết trước cắt ngang vào việc chuyển đổi từ monolith sang microservice thì từ bài viết này mình sẽ bắt đầu một series về xây dựng các dự án từ mức độ ý tưởng/ requirement, thiết kế kiến trúc, coding và deploy xoay quanh kiến trúc micorservice, 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 microservice và hướng khắc phục. Các dự án có thể là các project cũ bản thân đã từng trải qua trong quá trình làm việc, các business phổ biến trên thị trường, hoặc nếu các bạn muốn mình làm về chủ đề nào thì để lại requirement dưới comment. 

Project Requirement

    Ban đầu ý tưởng của mình là làm một trang thương mại điện tử trên nền microservice, nhưng nghĩ lại thì để full flow với hệ sinh thái đầy đủ từ warehouse, product, order, khuyến mãi, shiping, accounting, shop, supplier ... sẽ là hơi over cho một sự bắt đầu. Vậy nên sau đó mình nghĩ sẽ 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 thì các bạn có thể thấy các dịch vụ của google dành cho nhà phát triển có rất nhiều dịch vụ dạng API as a service, ví dụ như các dịch vụ về bản đồ, notification, verify phone number. 

    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 sẽ 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 các business tiếp theo. Ví dụ:

- Các 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ủ để hỗ trợ quá trình chăm sóc khách hàng, bảo hành. Đi kèm với các thông số là data về location, 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 cskn, 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, đợt có làm cái dự án về công nghệ bản đồ nên mình 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.

Google Map services

                                                                     Mapbox services

     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ọ support convert 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 requirement mà mình vừa đề ra ở trên, có 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 free trial rất thấp cho 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 :))

    Google geocoding pricing

Mapbox geocoding pricing

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. Các 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

    

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