Sử dụng sub domain hay sub path trong dự án thực tế như thế nào cho hợp lý? Trong các dự án thực tế không phải ai cũng biết khi nào nên sử dụng sub domain khi nào sử dụng sub path. Việc chọn không đúng sẽ ảnh hưởng rất nhiều đến việc phát triển dựa án.
Sub domain
Nếu tên miền của bạn là example.com thì sub domain sẽ là sub.example.com. Khi nào nên sử dụng sub domain?
- Khi cần phân tách hoàn toàn các ứng dụng hoặc dịch vụ. Ví dụ: Blog (blog.example.com) và cửa hàng (store.example.com) là hai ứng dụng độc lập.
- Khi chạy 2 ứng dụng với 2 source code khác nhau, source code độc lập cần dùng sub domain, dùng sub path sẽ là ác mộng khi phải control 2 source code.
- Khi cần cấu hình hệ thống hoặc cơ sở hạ tầng khác nhau. Subdomain có thể trỏ đến máy chủ hoặc dịch vụ khác mà không ảnh hưởng đến tên miền chính.
- Khi SEO cần được tối ưu hóa cho các đối tượng khác nhau. Ví dụ: us.example.com và jp.example.com cho các thị trường Mỹ và Nhật Bản.
- Khi sử dụng các nền tảng quản lý hoặc ngôn ngữ khác nhau. Ví dụ: Một phần chạy PHP (www.example.com), phần khác chạy Node.js (api.example.com).
- Khi cần chứng chỉ SSL riêng biệt. Subdomain có thể có các chứng chỉ SSL độc lập.
Sub path
Nếu tên miền của bạn là example.com thì sub domain sẽ là example.com/admin. Khi nào nên sử dụng sub path?
- Khi muốn giữ tất cả nội dung trên cùng một domain. Điều này giúp duy trì tính nhất quán và cải thiện nhận diện thương hiệu.
- Khi muốn tận dụng SEO cho domain chính. Nội dung trong subpath sẽ chia sẻ "authority" của tên miền chính, điều này giúp tăng điểm SEO tổng thể.
- Khi các dịch vụ liên quan chặt chẽ đến nhau. Ví dụ: Blog (example.com/blog) và sản phẩm (example.com/shop) là một phần của cùng một hệ thống.
- Khi cần đơn giản hóa việc quản lý chứng chỉ SSL. Chỉ cần một chứng chỉ SSL cho toàn bộ domain và subpath.
- Khi hệ thống dễ dàng mở rộng hoặc được cấu hình để xử lý subpath. Nếu bạn đang sử dụng một framework như Laravel hoặc WordPress, việc quản lý subpath thường dễ dàng hơn.
Sub domain hay sub path
Khi thế kế hệ thống cần để ý và tư vấn cho khách hàng. Nếu khách muốn phát triển theo hướng sub domain thì mỗi domain sẽ chạy một source code. Như thế sẽ rất dễ mở rộng về sau. Nếu khách muốn làm sub path thì tất cả các path sẽ chạy trên một source code. Mình đã làm dự án code chạy riêng biệt mà khách lại muốn làm theo hướng sub path phải sửa cả code base, nginx mới có thể chạy được mà còn mất rất nhiều thời gian để test lại các tính năng cho web.
Thực hiện như thế nào?
Khi sử dụng sub path, chỉ cần phát triển nó trên 1 framwork laravel, rồi chi thành các path là dự án chạy vèo vèo. Sử dụng sub domain thì mỗi domain có thể sử dụng 1 source riêng. Mỗi source chúng ta có thể config để chạy trên 1 container sau đó dùng aws loadbancer rule host header để cân bằng tài, khi user truy cập các domain khác nhau sẽ chuyển request đến dúng container.
VD: Bài toán thực tế, có 2 website chạy 2 source code khác nhau, trên 2 server khác nhau giờ muốn tiết kiệm chi phí nên muốn gộp 2 server làm 1 và code chung trên 1 source code.
Cách giải quyết vấn đề:
- Để code của 2 website chung 1 source ở 2 thư mục cùng cấp.
- Config docker chạy 3 container nginx, web1, web2.
- Web1 chạy ở container 1, map với nginx post 80 với domain chính web1.com.
- Web2 chạy ở container 2, map với nginx qua post 81, sub domain web2.web1.com.
Như vậy lúc này khi truy cập vào server với post 80 sẽ vào source code của web1 và truy cập vào server với post 81 sẽ vào source code của web2.
Tiếp theo chúng ta sẽ dùng load balancer để cân bằng tải, tạo 2 targert group cho instance với post 80 và 81, thiết lập rule, host header. Nếu host header là web2.web1.com thì chuyển request đến targert group 81, còn lại là 80.
Như vậy khi người dùng truy cập web1.com thì code web1 sẽ chạy, còn truy cập web2.web1.com thì sẽ được chuyển đến code của web2.
Tổng kết
Việc sử dụng đúng cách sub domain, sub path sẽ giúp quá trình phát triển code thuận lợi hơn. Hi vọng bài việc sẽ giúp mọi người không gặp phải yêu cầu 1 source code nhưng muốn dùng sub domain, hay 2 source code lại muốn dùng sub path. Mọi yêu cầu đều có thể làm được nhưng yêu cầu đúng thì mang lại hiệu quả cao nhất. Thanks for reading...
Author
