Giống như những thứ khác trong cuộc sống, việc đầu tiên bạn làm là dành thời gian để lên kế hoạch cho dịch vụ của bạn, cân nhắc những thứ bạn sẽ đạt được và những thứ đánh đổi. Một hệ thống được thiết kế lúc đầu chắc chắn sẽ phải chạy một thời gian dài, và việc thay đổi sang một cách thiết kế khác thường kéo theo rất nhiều chi phí (lớn hơn nhiều so với việc đập bỏ và xây dựng lại). Một lưu ý nữa về tầm quan trọng của giai đoạn này đó là thiết kế của bạn sẽ ảnh hưởng trực tiếp hoặc gián tiếp tới quy trình làm việc, công sức của các dev, và việc "sống chết" của dịch vụ của bạn.
 |
| Ảnh minh hoạ |
Do vậy, hãy cân nhắc kỹ và quyết định một cách thiết kế nào tối ưu nhất. Trong khuôn khổ bài viết này, tôi chỉ muốn đề cập đến các nguyên lý, dựa vào đó mà bạn có thể cân nhắc để chọn cách thiết kế nào:
- Tính sẵn sàng (Availability): Đây là tiêu chí quan trọng gần như tuyệt đối ở hầu hết các dịch vụ ngày nay: Đừng bao giờ để web của bạn bị "chết". Với những cửa hàng bán lẻ online, việc có một vài phút không truy cập được có thể khiến thiệt hại lên đến hàng nghìn, hàng triệu đô la. Việc không truy cập được có thể có nhiều nguyên nhân, có thể do lỗi server, cũng có thể do nhiều lượt truy cập quá sức chịu đựng, hoặc có thể do bị tấn công... Và "lỡ" có một lần dịch vụ bị "chết" thì bài toán đặt ra là khả năng phục hồi lại dịch vụ là trong bao lâu.
- Hiệu suất (Performance): Cũng là một tiêu chí quan trọng bậc nhất của hầu hết các website: Giảm tối đa tốc độ tải và xử lý các request. Tốc độ tải trang, tốc độ xử lý render trang,... ảnh hưởng trực tiếp tới hiệu quả sử dụng, tới sự hài lòng của user, và cả ranking của bạn trong các search engine nữa. Mà những chỉ số này lại ảnh hưởng tới doanh thu (revenue) và khả năng quay lại trang (retention).
- Độ tin cậy (Reliability): Hệ thống của bạn dù được thiết kế thế nào đi nữa nó cũng phải tin cậy được, tức là một request tới một dữ liệu nào đó là luôn lấy được dữ liệu đó, hoặc khi bạn cập nhật thì luôn lấy được dữ liệu mới được cập nhật đó. Bạn có thể nghĩ làm sao mà có thể khác đi được. Nhưng thực tế khi triển khai hệ thống web lớn với hàng chục server thì bạn sẽ thấy khác, nếu thiết kế không tốt, rất có thể xảy ra tình trạng server này có dữ liệu mới rồi mà server khác lại chưa có, mặc dù chúng cùng một cụm server cho một dịch vụ nào đó. Đứng với góc nhìn user, họ biết rằng dữ liệu của họ nhập vào sẽ "nằm yên ở đó".
- Khả năng mở rộng (Scalability): Khi hệ thống của bạn lớn lên, bạn chắc chắn sẽ phải tăng thêm dung lượng data, tăng số lượng server đáp ứng tải lớn, và rất nhiều thứ khác. Và thế là bạn sẽ lại đau đầu vì mấy câu hỏi như: Hiện tại có thể chịu tải tối đa là bao nhiêu? Việc thêm mới các resource (dung lượng data, số lượng server,...) có dễ dàng hay không? Hoặc bao nhiêu transaction mà nó có thể xử lý đồng thời được?...
- Mức độ dễ quản lý (Manageability): Việc thiết kế hệ thống cũng cần quan tâm tới việc vận hành và bảo trì hệ thống đó có dễ hay không. Điều này ảnh hưởng tới cách thức mà nhóm vận hành thực hiện, nếu quá khó sử dụng, họ có thể gặp nhiều sai lầm, và từ đó phát sinh nhiều vấn đề nghiêm trọng khác. Một điểm nữa cần chú ý là nếu họ có sai lầm thì hệ thống làm sao có thể phục hồi về trạng thái trước đó thật nhanh và chính xác.
- Chi phí (Cost): Là một hệ số quan trọng. Rõ ràng một hệ thống không thể gọi là tốt nếu ngốn nhiều chi phí cho việc setup và vận hành. Có rất nhiều loại chi phí như chi phí cho developer hiện thực, chi phí hàng tháng cho server, và thậm chí là chi phí cho việc hướng dẫn người vận hành sử dụng...
Khi bạn bắt đầu thiết kế một hệ thống web lớn, trước tiên hãy ngồi xuống và phác thảo chi tiết theo các nguyên lý trên, sau đó dựa vào business của dịch vụ mà bạn muốn cung cấp để xác định những vấn đề nào cần ưu tiên. Việc cuối cùng là chọn một giải pháp tối ưu, thông qua thiết kế hệ thống và chọn các framework hay ứng dụng.
Bạn có thể thấy điều tôi vừa nói là thừa, vì bạn luôn làm thế mà. Nhưng tôi chỉ muốn bạn chắc rằng bạn bắt đầu bằng những nguyên lý trên và business chứ không phải việc bạn thấy framework hay ứng dụng nào đó hay ho và muốn áp dụng liền để sử dụng.
Trước đây, tôi đã từng vấp phải điều tương tự. Tôi thấy một công nghệ hay, và muốn thử ngay tức thì, tôi bắt đầu cố gắng nối kết công nghệ đó với dịch vụ mà mình muốn triển khai, lên kế hoạch chọn database, chọn framework, nhanh tay chọn một cloud free nào đó để thử nghiệm, và bắt đầu mọi thứ trên đó. Mọi thứ đều ổn, database có thể scale được theo ý tôi, web server cũng scale được, việc quản lý cũng không quá phức tạp. Tất cả mọi chỉ số đều rất tốt, ngoại trừ một điểm là dần dần không có ai hiểu rõ được hệ thống ngoại trừ chính tôi. Có quá nhiều thứ bạn muốn làm, trong khi bạn không thể chia sẻ công việc và trách nhiệm với những người khác, đó là một thất bại. Phần lớn mọi người đều vấp phải sự mệt mỏi khi làm việc với một hệ thống hoàn toàn mới, không giống ai, ngôn ngữ database cũng lạ lẫm, các khái niệm trong framework cũng lạ lùng. Khó khăn khi bắt đầu đã đẩy họ vào con đường phải đầu hàng trong sự mệt mỏi. Suy cho cùng thì đây cũng là một loại chi phí, chi phí ownership.
Những nguyên lý mà tôi đề cập không phải là của tôi đưa ra, mà là tôi cóp nhặt được ở đâu đó, nhưng phải sau khi tôi "nghiền ngẫm" nó bằng một cái giá thực tế thì tôi mới hiểu ra đó là điều quan trọng. Trước đây, tôi đã từng nghĩ mấy cái nguyên lý vớ vẩn kia mình biết cả rồi, giờ mới thấy mình chả biết gì cả. Chỉ là tôi đang note lại để đề phòng mình quên... ^^
No comments:
Post a Comment