Evolution of our platform architecture

Allegro · 2015 · 4. Điều chỉnh · Độ khó: Dễ — bài gốc

Bối cảnh

Allegro (sàn thương mại điện tử Ba Lan) ra đời năm 1999: 3 developer, vài trăm user, dữ liệu lưu trong file, chưa có SQL. Đến 2015 công ty có hàng chục team, hàng trăm lập trình viên. Bài kể bốn giai đoạn, mỗi giai đoạn có ưu và nhược do chính Allegro nêu.

Thay đổi chính (4 giai đoạn)

~2005, scale bằng tự xây:
- hơn 100 web server, chuyển DB sang Oracle;
- tự viết bằng C/C++ nhiều tầng cache, connection pool, cả search engine.
Ưu: mua được vài năm mà không cần cuộc cách mạng nào, ít phụ thuộc giải pháp enterprise. Nhược: bỏ qua open source, tốn thời gian lẽ ra dùng cho tính năng.
2008–2009, framework "tự chế" trong cùng repo:
- codebase hàng triệu dòng PHP viết kiểu thủ tục; viết code mới trong thư mục framework.
Ưu: có kết quả nhanh, vẫn ra tính năng (tránh "câu chuyện Netscape"). Nhược: code mới vẫn gọi hàm cũ bên dưới, hiệu ứng "cửa sổ vỡ", hai hệ thống song song (hai hệ mail), developer không ước lượng được thời gian ("1 ngày nếu là code mới, 2 tuần nếu là code cũ"), vẫn là một monolith.
"New platform", SOA nhưng chung một backend:
- Symfony2, một app frontend + một app backend chứa mọi service (code tách riêng);
- một team dựng nền tảng, các team khác lần lượt chuyển sang;
- chỉ được gọi code cũ qua Anti-Corruption Layer.
Ưu: ranh giới mới/cũ rõ, service sở hữu dữ liệu, bỏ được nhiều logic chết. Nhược: chờ lâu, phụ thuộc một team, frontend chung buộc release đồng bộ, phụ thuộc giữa module mọc lại, phần kỹ thuật chung (job nền, cache) không ai sở hữu.
"Rubikon", microservices theo DDD:
- chia theo bounded context, mỗi team một context; giao tiếp qua event bus (ưu tiên) hoặc gọi trực tiếp qua discovery;
- mỗi context có frontend riêng (ghép trang bằng ESI);
- chấp nhận trùng dữ liệu để tách rời; chuyển từ PHP sang JVM (chủ yếu Java);
- có team kỹ thuật lo event bus, discovery, thư viện chung.
Ưu: xoá/viết lại hơn 1 triệu dòng code cũ trong một năm, release độc lập, dùng được nhiều DB (Cassandra, Mongo, MySQL, Oracle). Nhược: chi phí học Java, tốc độ quá nhanh khiến thiếu chức năng chung, khó áp chuẩn chung, độ phức tạp dời lên tầng ghép service (sinh ra vai trò "Solutions Architect"), test end-to-end khó.

Vì sao

Theo Allegro: monolith làm mọi thay đổi rủi ro, merge khó, phản ứng chậm. Kiến trúc mới cần được phía business ủng hộ; architect và product owner chọn domain nào viết lại trước theo tốc độ thay đổi, tình trạng hiện tại, tác động kinh doanh.

Bài học cho SWE

Framework mới trong cùng codebase không tạo ra ranh giới: code mới vẫn dùng được code cũ thì logic vẫn cũ. Cần rào cứng (Anti-Corruption Layer, tách app).
SOA nhưng chung frontend/backend vẫn là monolith về release. Cùng chẩn đoán với Uber (Uber 2020) và Segment (Segment 2018).
Phần kỹ thuật dùng chung cần có chủ sở hữu rõ ràng. Xem Nền tảng nội bộ cho service (đường ray chung).
Việc tiếp theo Allegro tự nêu: công cụ release/monitoring có sẵn cho mọi service mới, auto-scaling, self-healing.