Toàn bộ chạy trên một máy chủ
Ứng dụng, cơ sở dữ liệu, bộ đệm và tệp tải lên nằm chung một máy, nên không thể tăng riêng phần đang thiếu và cũng không có bản sao nào để thay thế.
HiTechCloud thiết kế và vận hành hạ tầng cho website và ứng dụng có lưu lượng biến động mạnh: tách tầng, cân bằng tải, tự động co giãn, đưa nội dung tĩnh ra biên, và đo trước bằng kiểm thử tải thay vì chờ tới ngày mở bán mới biết.
Một website bán hàng chạy êm suốt năm vẫn có thể gục trong mười phút đầu của đợt mở bán. Nguyên nhân hiếm khi là toàn bộ hệ thống thiếu sức, mà thường là một chỗ: một truy vấn cơ sở dữ liệu không có chỉ mục, một phiên đăng nhập lưu trên đĩa của đúng một máy chủ, một tiến trình gửi thư đồng bộ ngay trong luồng đặt hàng.
Vì vậy việc đầu tiên không phải là mua thêm máy chủ. Việc đầu tiên là tìm ra điểm nghẽn bằng kiểm thử tải trên chính hệ thống của doanh nghiệp, với kịch bản mô phỏng đúng hành vi người dùng thật. Sau đó mới bàn tới việc tách tầng, thêm bản sao và bật tự động co giãn.
HiTechCloud dựng lớp hạ tầng này bằng các dịch vụ đang vận hành: Load Balancer phân tải giữa các bản sao, Auto Scaling tăng giảm số máy theo tải thật, Kubernetes cho ứng dụng đóng gói theo dịch vụ, Redis cho bộ đệm và phiên đăng nhập, vCDN đưa nội dung tĩnh ra gần người dùng, Multi-AZ cho hệ thống cần chịu được sự cố ở mức vùng khả dụng, và vMonitor để nhìn thấy chuyện gì đang xảy ra.
Ứng dụng, cơ sở dữ liệu, bộ đệm và tệp tải lên nằm chung một máy, nên không thể tăng riêng phần đang thiếu và cũng không có bản sao nào để thay thế.
Người dùng bị đăng xuất mỗi khi được chuyển sang máy khác, nên hệ thống không thể thêm bản sao dù đã có cân bằng tải.
Mọi lần tải trang đều chạm cơ sở dữ liệu, không có lớp đệm, và một vài truy vấn nặng chiếm hết kết nối khi lưu lượng tăng.
Chưa từng có kiểm thử tải, nên mọi con số về sức chịu đựng đều là phỏng đoán và chỉ được kiểm chứng đúng vào lúc không mong muốn nhất.
Đọc sơ đồ hệ thống, đo mức tài nguyên thực dùng ở giờ cao điểm và xác định những chỗ chỉ có một bản duy nhất, không thay thế được.
Dựng kịch bản mô phỏng hành vi người dùng thật, tăng tải theo bậc và ghi lại điểm mà thời gian phản hồi bắt đầu xấu đi cùng nguyên nhân tương ứng.
Tách ứng dụng, cơ sở dữ liệu, bộ đệm và lưu trữ tệp thành các tầng riêng, đưa phiên đăng nhập ra Redis để ứng dụng chạy được nhiều bản sao.
Đặt Load Balancer trước tầng ứng dụng, cấu hình kiểm tra sức khoẻ, và bật Auto Scaling theo ngưỡng tài nguyên đo được từ kiểm thử tải.
Chuyển hình ảnh, tệp tải xuống và nội dung ít thay đổi sang vCDN để giảm tải cho tầng ứng dụng và rút ngắn thời gian tải trang.
Thu nhật ký và chỉ số về một chỗ, đặt cảnh báo theo ngưỡng, và đặt vWAF trước ứng dụng để lọc lưu lượng bất thường trước khi nó chạm tới máy chủ.
Mỗi thay đổi trên hạ tầng đều đi kèm một lần đo trước và một lần đo sau trên cùng kịch bản, để biết thay đổi đó thật sự có tác dụng hay chỉ làm hệ thống phức tạp hơn.
Ghi nhận kiến trúc, mức tài nguyên thực dùng và những sự cố đã từng xảy ra trong các đợt tải cao trước đây.
Chạy kịch bản trên môi trường tương đương để xác định ngưỡng chịu đựng hiện tại và danh sách điểm nghẽn theo thứ tự ưu tiên.
Đề xuất tách tầng, thêm bản sao, thêm lớp đệm và cấu hình co giãn; phần cần sửa trong mã nguồn được chuyển cho đội phát triển.
Đo lại trên cùng kịch bản để xác nhận ngưỡng mới, lặp lại vòng này cho tới khi đạt mức mà doanh nghiệp đặt ra.
Bố trí trực cùng doanh nghiệp trong khung giờ cao điểm, theo dõi chỉ số theo thời gian thực, và tổng kết sau sự kiện.
Trước mỗi đợt mở bán hoặc chiến dịch lớn, hai bên ngồi lại để thống nhất kịch bản: khi nào tăng tài nguyên, ai theo dõi chỉ số nào, và dấu hiệu nào thì dừng chiến dịch.
Không có con số trả lời trước được. Ngưỡng chịu đựng phụ thuộc vào chính mã nguồn, cấu trúc cơ sở dữ liệu và luồng nghiệp vụ của từng hệ thống, nên hai website cùng cấu hình máy chủ có thể chênh nhau nhiều lần. Cách duy nhất để có con số đáng tin là kiểm thử tải trên chính hệ thống của doanh nghiệp, và đó là bước đầu tiên trong quy trình.
Trong nhiều trường hợp là không. Nếu điểm nghẽn nằm ở một truy vấn thiếu chỉ mục hay ở việc phiên đăng nhập gắn với một máy, thì tăng cấu hình chỉ đẩy ngưỡng lên một chút rồi hệ thống vẫn gục ở cùng chỗ. Kiểm thử tải cho biết nên sửa ở đâu trước.
Tự động co giãn chỉ có tác dụng khi ứng dụng chạy được nhiều bản sao và các tầng đã được tách. Nếu ứng dụng lưu trạng thái trên đĩa cục bộ thì thêm máy cũng không giúp gì. Ngoài ra việc tạo máy mới cần thời gian, nên cần đặt ngưỡng kích hoạt sớm hơn thời điểm hệ thống đã quá tải.
Không bắt buộc. Kubernetes hợp lý khi ứng dụng đã được chia thành nhiều dịch vụ và đội phát triển có nhu cầu triển khai thường xuyên. Với ứng dụng đơn khối, mô hình nhiều máy chủ đứng sau cân bằng tải thường đơn giản hơn và vận hành nhẹ hơn. HiTechCloud đề xuất theo hiện trạng, không theo xu hướng.
Kiểm thử được chạy trên môi trường tương đương, tách khỏi hệ thống đang phục vụ. Nếu doanh nghiệp muốn kiểm thử trực tiếp trên hệ thống chạy thật để có số liệu chính xác nhất, việc đó chỉ làm trong khung giờ thấp điểm đã thống nhất trước và có phương án dừng ngay khi cần.
Gồm phần tài nguyên hạ tầng tính theo tháng và phần công rà soát, kiểm thử tải, điều chỉnh kiến trúc tính theo phạm vi. Với các đợt cao điểm ngắn ngày, tài nguyên tăng thêm chỉ tính cho khoảng thời gian thực dùng. Giá chưa bao gồm VAT.
Liên hệ để đội ngũ HiTechCloud rà soát kiến trúc hiện tại và chạy một lần kiểm thử tải, xác định ngưỡng chịu đựng thật của hệ thống trước khi lên kế hoạch nâng cấp.
























































































































































通过HiTechCloud快速开始部署
最新通知、深度分析和活动































































































































































































