Backend cho app mobile: chọn kiến trúc nào

Trả lời nhanh: Với phần lớn ứng dụng di động, kiến trúc đúng ở giai đoạn đầu là một khối duy nhất chạy trên một máy chủ, không phải nhiều dịch vụ nhỏ. Tách dịch vụ giải quyết vấn đề của đội đông người, và nếu đội bạn dưới mười người thì nó chỉ thêm việc. Bốn thứ nên làm ngay từ đầu vì sửa sau rất đắt: đánh phiên bản API, thiết kế cho mạng yếu, tách nơi lưu file khỏi máy chủ ứng dụng, và ghi nhật ký đủ để gỡ lỗi từ xa.

Ứng dụng di động đặt ra vài ràng buộc mà ứng dụng web không có: người dùng ở trên mạng di động chập chờn, phiên bản cũ tồn tại rất lâu vì không phải ai cũng cập nhật, và bạn không sửa được lỗi phía người dùng bằng một lần triển khai. Bài này nói cách thiết kế backend có tính tới ba điều đó.

Một khối hay nhiều dịch vụ

Câu trả lời cho gần hết đội ở Việt Nam: một khối. Lý do rất thực dụng.

Kiến trúc nhiều dịch vụ nhỏ giải quyết vấn đề tổ chức: nhiều đội muốn triển khai độc lập mà không chờ nhau. Nếu bạn chỉ có năm người, bạn không có vấn đề đó, nhưng bạn sẽ nhận đủ cái giá: nhiều nơi để hỏng, khó gỡ lỗi xuyên dịch vụ, và chi phí hạ tầng nhân lên.

Cách làm hợp lý là một khối nhưng có ranh giới bên trong rõ ràng: chia mô đun theo nghiệp vụ, mỗi mô đun có lớp truy cập dữ liệu riêng, không gọi thẳng vào bảng của mô đun khác. Khi thật sự cần tách sau này, ranh giới đã có sẵn và việc tách chỉ là chuyện kỹ thuật.

Ngoại lệ đáng tách sớm: những phần có đặc tính tài nguyên khác hẳn, ví dụ xử lý ảnh hoặc xuất báo cáo nặng. Tách chúng ra một tiến trình riêng chạy theo hàng đợi giúp phần phục vụ người dùng không bị ảnh hưởng, theo cách trong bài về hàng đợi.

Đánh phiên bản API, việc bắt buộc

Đây là khác biệt lớn nhất so với backend cho web. Với web, bạn triển khai bản mới là mọi người dùng bản mới ngay. Với di động, phiên bản cũ tồn tại hàng tháng, có khi hàng năm, vì người dùng không cập nhật.

Hệ quả: bạn phải hỗ trợ nhiều phiên bản API cùng lúc. Ba nguyên tắc:

• Đặt phiên bản trong đường dẫn ngay từ bản đầu tiên, theo bài thiết kế REST API.
• Thêm trường mới thì không phá vỡ tương thích, nhưng bỏ trường hoặc đổi ý nghĩa thì phải mở phiên bản mới.
• Có cơ chế buộc cập nhật. Một điểm cuối trả về phiên bản tối thiểu được hỗ trợ, ứng dụng kiểm tra khi khởi động và báo người dùng nếu quá cũ. Không có nó thì bạn phải nuôi phiên bản cũ mãi mãi.

Thiết kế cho mạng yếu

Người dùng di động ở Việt Nam thường xuyên ở trên mạng chập chờn: trong thang máy, trên xe, ở vùng sóng yếu. Bốn nguyên tắc:

• Yêu cầu nhỏ và ít. Một màn hình nên lấy dữ liệu bằng một lượt gọi, không phải năm lượt nối tiếp. Đây cũng là lý do một số đội chọn cách để bên gọi tự khai báo trường cần lấy, xem bài về GraphQL.
• Mọi thao tác ghi phải chịu được thử lại. Ứng dụng gửi đơn, mất mạng giữa chừng, gửi lại. Nếu máy chủ không nhận diện được đó là cùng một đơn, khách sẽ có hai đơn. Cách chuẩn là để ứng dụng gửi kèm một mã định danh do nó sinh ra, máy chủ bỏ qua nếu đã xử lý mã đó rồi.
• Tải ảnh theo kích thước cần dùng, đừng gửi ảnh gốc rồi để ứng dụng thu nhỏ.
• Trả về nhanh, xử lý nặng ở phía sau. Người dùng nhận phản hồi ngay, việc nặng chạy trong hàng đợi.

Bốn thứ nên tách ngay từ đầu

Không phải tách thành dịch vụ riêng, mà là tách khỏi máy chủ ứng dụng:

1. Nơi lưu file. Ảnh và tài liệu không nên nằm cùng ổ với mã nguồn ứng dụng. Tách ra thì bạn nhân bản máy chủ ứng dụng dễ dàng và sao lưu cũng gọn hơn.
2. Database. Ở giai đoạn đầu chạy chung máy vẫn được, nhưng hãy dùng chuỗi kết nối qua mạng ngay từ đầu để sau này tách máy không phải sửa code.
3. Hàng đợi công việc. Tiến trình xử lý nền tách khỏi tiến trình phục vụ HTTP.
4. Nhật ký. Gom về một chỗ đọc được, đừng để rải rác trong các file trên máy.

Bốn việc này làm lúc đầu tốn thêm nửa ngày, làm lại sau khi đã chạy thật thì tốn vài tuần và kèm rủi ro.

Ghi nhật ký để gỡ lỗi từ xa

Với ứng dụng di động, bạn không xem được máy người dùng. Nhật ký phía máy chủ là gần như tất cả những gì bạn có.

Ba việc làm cho nhật ký thật sự dùng được:

• Mỗi yêu cầu có một mã định danh, trả về cho ứng dụng và ghi vào nhật ký. Khi người dùng báo lỗi, bạn xin mã đó và lần ra ngay toàn bộ quá trình xử lý.
• Ghi kèm phiên bản ứng dụng và loại thiết bị. Rất nhiều lỗi chỉ xảy ra ở một phiên bản hoặc một dòng máy.
• Đừng ghi dữ liệu cá nhân vào nhật ký. Ghi mã người dùng thay vì tên và số điện thoại.

Về chỗ đặt máy chủ, với ứng dụng phục vụ người Việt thì đặt trong nước giảm độ trễ rõ rệt cho mỗi lượt gọi, và với ứng dụng gọi API liên tục thì người dùng cảm nhận được. Chủ đề này có bài riêng trong cụm.

Bảng bốn thứ phải tách sớm

Dòng đầu là thứ quan trọng nhất và hay bị bỏ qua nhất: khác với web, bạn không ép người dùng cập nhật ứng dụng được. Luôn có người dùng bản cũ trong nhiều tháng, và máy chủ phải phục vụ họ.

Giả định mạng chập chờn ngay từ đầu

• Giả định mạng chập chờn. Người dùng ở Việt Nam thường xuyên chuyển giữa mạng di động và mạng không dây.
• Ứng dụng phải thử lại được mà không tạo bản ghi trùng: mỗi yêu cầu có mã định danh riêng, máy chủ bỏ qua nếu đã xử lý.
• Trả về gọn. Đừng trả cả đối tượng khổng lồ khi ứng dụng chỉ cần vài trường.
• Cho phép làm việc khi mất mạng ở mức tối thiểu, rồi đồng bộ lại khi có mạng.
• Đặt máy chủ trong nước nếu người dùng ở Việt Nam: tiết kiệm 150 tới 250 ms mỗi lượt gọi. Xem VPS Việt Nam.

Nhật ký, thứ duy nhất nói chuyện gì đã xảy ra

# Voi ung dung di dong, ban khong ngoi truoc may cua nguoi dung.# Nhat ky la thu duy nhat cho biet chuyen gi da xay ra. # Ba thu phai ghi cho moi yeu cau:# 1. Ma dinh danh yeu cau, de noi duoc log ung dung voi log may chu# 2. Phien ban ung dung va he dieu hanh cua thiet bi# 3. Thoi gian xu ly # KHONG duoc ghi vao nhat ky:#   mat khau, the truy cap, so the thanh toan,#   va du lieu ca nhan cua nguoi dung # Kiem nhat ky co lo du lieu nhay cam khonggrep -riE "password|token|cvv|cccd" /var/log/ungdung/ | head

Về một khối hay nhiều dịch vụ: với đội dưới mười người, một khối duy nhất gần như luôn là lựa chọn đúng. Tách thành nhiều dịch vụ giải quyết vấn đề của tổ chức lớn, và với đội nhỏ thì nó chỉ thêm việc vận hành mà không đổi lại gì.