Dự án của bạn chạy qua những gì, mất bao lâu ở từng chặng
Số đo dưới đây lấy trực tiếp từ log thật trên app.ebig.co — không phải ước lượng.
/api/bootstrap?tier=shell, app.ebig.co.Ebig thật sự chạy trên gì
Từng lớp chạy ở đâu, và lớp nào giữ việc gì.
ebig-crm-raw, tách khỏi luồng chung. Đây là CRM Ebig dùng để quản lý khách hàng của chính mình. Không phải module bán cho khách hàng dùng nền tảng.data:<pid>:<Module>, dùng chung cụm.Bốn chặng, không có chặng thứ năm. Thời gian thật của từng chặng nằm ở mô phỏng ngay bên dưới.
Tầng này không có "node" hay "vCPU". worker ở biên không cấp máy cố định — mở rộng theo request, không theo cấu hình trước.
Microservice là một lựa chọn, không phải một chuẩn mực
Hệ thống hiện đại thì phải chẻ nhỏ thành microservice. Mỗi chức năng một service riêng, càng nhiều càng "chuẩn". Đây là ngộ nhận, không phải quy luật kỹ thuật.
Ebig OS đi theo nguyên tắc "1 Table = 1 Module". Mỗi module sinh ra là một khối gọn, đầy đủ, không bị chẻ vụn thành nhiều service con.
Bên trái là tám mảnh phải điều phối với nhau. Bên phải là một khối, cộng đúng hai worker tách ra có lý do.
Ebig chỉ tách worker khi có lý do thật
Bốn worker, bốn lý do — và lý do nào cũng là một ràng buộc thật của hệ thống.
| Worker tách riêng | Lý do |
|---|---|
| CRM nội bộ Ebig | Bảo mật. Cô lập vật lý riêng, không chung hạ tầng với dữ liệu khách hàng. |
| SSO | Ranh giới trách nhiệm rõ. SSO giữ định danh. |
| Local | Ranh giới trách nhiệm rõ. Local giữ kết nối CSDL trong bộ nhớ. |
| Gateway | Một cửa vào duy nhất. Xác thực và định tuyến nằm gọn một chỗ. |
Không dòng nào tách ra chỉ vì kiến trúc nghe hợp thời.
Thị trường cũng đang tự sửa sai điều này
Năm 2023, đội Prime Video của Amazon công bố một lần chuyển kiến trúc ngược chiều.
Kết luận của chính đội đó: microservice là công cụ, không phải mục tiêu. Dùng khi hợp bài toán, không dùng theo mặc định.
Case Amazon Prime Video 2023 là sự kiện có thật, được nhiều nguồn kỹ thuật độc lập xác nhận. Cách Ebig áp dụng nguyên tắc tương tự cho kiến trúc riêng của mình là lựa chọn thiết kế của Ebig, không phải một quy luật chung cho mọi hệ thống.
(đã đăng nhập)
(worker ở biên)
(worker ở biên)
(TCP/TLS)
Trình duyệt đã có phiên đăng nhập (cookie), nên bước xác thực gần như tức thời — không phải chặng tốn thời gian.
Đây là chặng chờ lớn nhất ngoài CSDL trong bộ nhớ. Gateway gộp 4 lệnh gọi (đếm mail, đếm hội thoại, thông báo, hồ sơ) qua liên kết worker nội bộ trước khi chuyển tiếp xuống Local.
18ms là chi phí bắt tay TCP/TLS. Chi phí này giảm được nếu tái sử dụng kết nối thay vì mở mới mỗi lượt. Đây là điểm đã ghi nhận cần tối ưu, không phải giới hạn cứng của CSDL trong bộ nhớ.
3 lệnh FT.SEARCH (mail, chat, thông báo) chỉ tốn 8ms tổng cộng ở phía CSDL trong bộ nhớ — đúng việc CSDL trong bộ nhớ làm nhanh nhất. CSDL trong bộ nhớ không phải nơi mất thời gian.
Ba đường chạy song song nên tính theo đường dài nhất: mail 207ms, chat 309ms, thông báo 325ms. Trong 325ms đó, chỉ 8ms là lệnh CSDL trong bộ nhớ thật. Phần lớn còn lại là hàng đợi liên kết worker nội bộ và bắt tay kết nối — đúng chỗ đội kỹ thuật Ebig đang tối ưu tiếp.
Người dùng thấy 325ms, không phải tổng ba con số cộng lại. Đó là đường thông báo — đường chậm nhất.
Nguồn: log đo thật trên /api/bootstrap?tier=shell, app.ebig.co — không phải số dựng cho trang này.
"Không dùng chung" đúng cho tầng nào
| SaaS dùng chung | On-premise / Private Cloud | |
|---|---|---|
| Dành cho ai | Mặc định — gói $15/người dùng SME, doanh nghiệp vừa và lớn dùng mô hình SaaS chuẩn. |
Riêng — Chính phủ / BigTech Cơ quan nhà nước cần chủ quyền dữ liệu. Doanh nghiệp lớn thay hệ thống lõi cũ theo mô hình Zero Downtime. |
| Chạy trên gì | worker ở biên + kho khoá–giá trị + CSDL trong bộ nhớ. Hạ tầng chung cho toàn bộ khách hàng. | 100% on-premise hoặc private cloud. Hạ tầng Kubernetes (K8s) auto-scaling riêng biệt. |
| Cô lập bằng | Logic. Mỗi dự án một tiền tố khoá riêng (data:<projectId>), cộng cờ kiểm soát quyền truy cập. |
Vật lý. Cụm K8s riêng, không dùng chung máy với khách hàng khác. |
| "Không dùng chung" đúng chưa | Một nửa — chung máy, riêng khoá. | Đúng nghĩa — đây mới là tầng dự án của bạn không dùng chung với ai. |
Bốn dòng đối chiếu cho thấy "không dùng chung" chỉ đúng ở cột phải. Cột trái chung máy, riêng khoá.
Bấm "Tạo dự án" thì chuyện gì xảy ra
Không có việc cấp máy chủ riêng hay dựng hạ tầng mới — đây là một lượt ghi dữ liệu, gần như tức thời.
"Tạo dự án"
xác thực phiên
ghi kho khoá–giá trị
project + secret
Workplace gửi tên dự án lên Gateway. Chưa có gì được tạo ở bước này.
Gateway không đọc bất kỳ thông tin "tôi là ai" nào do chính request gửi lên. Đây là điểm bản cũ từng có lỗ hổng nghiêm trọng nhất: ai gọi API cũng tự xưng được là bất kỳ ai.
(a) bản ghi thành viên owner trước, (b) bản ghi project sau. Nếu đứt giữa chừng, chỉ để lại một membership mồ côi — không bao giờ để lại một project không ai sở hữu, không ai xoá được.
Secret chỉ hiện đúng một lần. kho khoá–giá trị chỉ giữ salt + SHA-256, không lưu lại nguyên văn.
Dữ liệu nghiệp vụ (Mail, Chat, Document…) chưa có gì ở bước này. Nó chỉ xuất hiện trên CSDL trong bộ nhớ khi khách thật sự bắt đầu dùng module, theo tiền tố data:<projectId>:<Module>.
Việc chặn người ngoài dự án đọc dữ liệu (tenantEnforce) mặc định TẮT. Chỉ bật khi khách bắt đầu dùng dữ liệu thật, đúng như trong mã nguồn.
Nguồn: Api/SSO/store/projects.js, hàm createProject.
Một dự án hạ tầng lớn tự xây thường trông như thế này
Số lấy từ hồ sơ triển khai của một dự án viễn thông có thật ở Việt Nam, đã ẩn tên — trích để đối chiếu quy mô, không phải kiến trúc của Ebig.
Sáu ô trên là sáu cụm máy riêng biệt, mỗi cụm một công nghệ khác nhau. Đó là thứ phải tuyển người biết vận hành.
Đây là độ phức tạp mà Ebig OS gánh thay khách hàng ở tầng hạ tầng mặc định. Không phải vì Ebig không cần hạ tầng tương đương. Mà vì đội ngũ Ebig là người vận hành nó, còn khách hàng chỉ thấy 7 module qua Workplace.
Không phải ai cũng ngồi ở trung tâm điều hành
Cùng dự án tham chiếu ở trên — lần này là quy mô con người, không phải hạ tầng.
Người dùng đồng thời (tức thời)
Giờ cao điểm, tại trung tâm điều hành (NOC) — màn hình lớn, mạng ổn định, phiên làm việc dài.
Tổng nhân sự kỹ thuật tiềm năng
900 điểm × 25–40 nhân sự/điểm, rải khắp cả nước. Thiết bị di động, mạng yếu/chập chờn, thời gian thao tác ngắn.
Đây là hai lớp số đo khác nhau — đồng thời và tổng. Chúng không mâu thuẫn nhau. Nhưng chúng kéo theo hai yêu cầu thiết kế khác hẳn.
| Điều kiện làm việc | Nhóm NOC | Nhóm hiện trường |
|---|---|---|
| Thiết bị | Màn hình lớn | Thiết bị di động |
| Mạng | Ổn định | Yếu, chập chờn |
| Phiên làm việc | Dài | Thao tác ngắn |
Ba dòng khác nhau ở cả ba dòng. Không thể dùng chung một thiết kế màn hình cho hai nhóm này.
Về giá ở quy mô này: giá $15/người/tháng tính đúng cho người dùng thường xuyên, dùng đủ 7 module. Với hàng chục nghìn nhân sự hiện trường chỉ thao tác vài phút mỗi ca, áp thẳng công thức đó chưa chắc là mô hình tính phí hợp lý. Đây là bài toán cần trao đổi trực tiếp theo đúng cách tổ chức của bạn dùng hệ thống, không phải con số áp sẵn.
Domain, hạ tầng, vận hành — Ebig lo hết, bạn không cần tuyển người biết làm
Đăng ký domain, trỏ DNS, chứng chỉ SSL, dựng máy chủ, giám sát, vá bảo mật — toàn bộ chuỗi việc này Ebig làm sẵn phía sau. Khách hàng không cần tuyển ai biết những việc đó tồn tại để bắt đầu dùng.
Nếu công ty bạn có đầu tư đội kỹ thuật riêng, họ không bị gạt ra ngoài — họ có thể tự tìm hiểu, xem log, cùng vận hành với đội Ebig. Đây đúng là mối quan hệ mà chính Ebig đang có với các nền tảng mình dùng:
· Dịch vụ dữ liệu ·
Cùng một tầng quan hệ, chỉ khác vị trí đứng — không ai phải hiểu hết lớp bên dưới mới dùng được lớp bên trên.
Hạ tầng K8s riêng, và dự án của bạn nằm ở đâu trong đó
SỐ LIỆU GIẢ LẬP — minh hoạ cách tính cho 1 dự án quy mô lớn, không phải một triển khai đã đo thật.
(2.000 đồng thời)
Dự án của khách hàng nằm ở đâu: vẫn đúng cơ chế "1 Table = 1 Module" như tầng SaaS dùng chung. Khác ở chỗ toàn bộ pod, CSDL trong bộ nhớ, storage của dự án này chạy trong namespace K8s riêng, có ResourceQuota và NetworkPolicy chặn khách hàng khác, thay vì chỉ cô lập bằng tiền tố khoá như tầng mặc định.
Cách tính phỏng theo đúng phương pháp trong tài liệu tham chiếu triển khai vật lý nội bộ của Ebig. Số liệu ở đây được giả lập cho một kịch bản minh hoạ, chưa phải cấu hình đã đo cho một khách hàng cụ thể.
Cụm K8s không phải nơi hứng toàn bộ lưu lượng
1. Lọc tấn công và bot ngay tại biên, trước khi tới K8s
Nghĩa là cụm chỉ cần tính sức cho lưu lượng nghiệp vụ thật, không phải cho kịch bản bị tấn công nặng nhất. Đó là khác biệt giữa một con số tính được và một con số phải đoán.
2. Đường hầm TLS — cụm K8s không cần lộ IP công khai
tiến trình đường hầm chạy như một Deployment trong chính cụm K8s, tự mở đường hầm TLS ra nền tảng biên — không cần mở cổng, không cần địa chỉ IP công khai cho cụm. Toàn bộ traffic vào cụm đã đi qua DDoS protection, WAF và health check của nền tảng biên trước đó.
3. Mở rộng bằng nhiều cụm, không phải một cụm khổng lồ
Cân tải toàn cầu kiểm tra sức khoẻ từng cụm từ 3 trung tâm dữ liệu mỗi vùng, tự định tuyến sang cụm gần nhất còn khoẻ, tự ngắt cụm quá tải. Điều này đổi hẳn cách trả lời câu "2 triệu người dùng thì sao". Không phải dựng một cụm K8s 9 VM đủ sức gánh hết. Mà là nhiều cụm, mỗi cụm quy mô như mô hình dự án lớn ở trên, đặt ở nhiều vùng. Tất cả đứng sau cùng một cân tải toàn cầu. Mở rộng gần như tuyến tính bằng cách thêm cụm, không phải thêm máy vào một cụm duy nhất.
Cách bố trí nhiều cụm ở trên là suy luận kỹ thuật từ mô hình đã chạy, chưa phải một triển khai multi-cluster đã đo.
Giá $15/người dùng đã tính cho trường hợp này
Hạ tầng phía sau (CSDL trong bộ nhớ, nền tảng biên, K8s…) mở rộng được theo mức dùng — chi phí mở rộng đó đã tính vào mức giá $15/người dùng/tháng, không phát sinh thêm khi lượng người dùng tăng. Bạn không cần tự lo phần kỹ thuật này.
Câu hỏi đáng quan tâm hơn không phải "hạ tầng có chịu được không", mà là bạn muốn đứng ở đâu trong 3 cách làm dưới đây.
Bạn muốn nhẹ đầu, hay muốn tự quyết định từng phần?
Ebig không nói cách nào tốt hơn — mỗi cách có cái giá phải trả riêng. Bạn tự nhìn và chọn.
Trả theo người dùng
$15/người/tháng, trọn 7 module. Không cần chọn công nghệ, không cần biết hạ tầng chạy ra sao.
Cái phải đánh đổi: ít quyền tuỳ biến sâu hơn 2 cách còn lại.
Tự chọn dịch vụ/module
Chọn đúng module cần, phối hợp theo ý mình. Linh hoạt hơn, nhưng tự bạn phải quyết định tổ hợp nào hợp lý.
Cái phải đánh đổi: đây là bài toán ma trận — mỗi lựa chọn thêm là một quyết định phải cân nhắc, đúng nghĩa "mua dây buộc mình".
Tự xây dựng hạ tầng riêng
Tự chọn công nghệ, tự dựng, tự vận hành — toàn quyền kiểm soát.
Cái phải đánh đổi: chỉ riêng việc chọn công nghệ đã mất nhiều công sức. Còn xây dựng và vận hành thật thì độ khó lớn hơn nhiều, xem ví dụ thực tế ở trên.