Thiết kế hệ thống mở rộng
Bạn đã từng tự hỏi về cách thiết kế hệ thống cho một dự án? Cách thông thường mà mọi người hay làm là xác định các service cần thiết cho hệ thống và sau đó lắp ghép chúng lại với nhau. Trong bài viết này, chúng ta sẽ nhìn vào một mô hình phức tạp nhưng thú vị, và thông qua đó, bạn sẽ có thể tự thiết kế hệ thống riêng của mình.
Hình ảnh: Hướng dẫn thiết kế hệ thống (Phần 1)
Học cách thiết kế hệ thống lớn
- Học cách thiết kế các hệ thống có thể mở rộng sẽ giúp bạn trở thành một kỹ sư giỏi hơn.
- Thiết kế hệ thống là một chủ đề rộng. Có rất nhiều tài liệu chia sẻ trên các trang web về nguyên tắc thiết kế hệ thống. Chuỗi bài viết này sẽ giúp bạn học cách xây dựng hệ thống theo quy mô.
Tự thiết kế hệ thống
- Ngoài việc viết code, thiết kế hệ thống cũng là một kỹ năng quan trọng tại nhiều công ty công nghệ.
- Hãy thực hành các vấn đề và câu hỏi liên quan đến thiết kế hệ thống. Sau đó, so sánh kết quả của bạn với các giải pháp mẫu. Tiếp theo, thảo luận và trao đổi ý kiến để vẽ ra các sơ đồ.
Hình ảnh: Hướng dẫn thiết kế hệ thống (Phần 1)
Q: Bạn có cần phải biết mọi thứ ở đây không? A: Không, bạn không cần phải biết mọi thứ ở đây. Bạn sẽ phụ thuộc vào những yếu tố sau:
- Số năm kinh nghiệm của bạn.
- Nền tảng kỹ thuật mà bạn sử dụng.
- Vị trí công việc hiện tại của bạn.
- Lĩnh vực mà công ty của bạn hoạt động.
Bắt đầu bằng việc nghiên cứu sâu và hiểu rõ về từng thành phần. Điều này sẽ giúp bạn hiểu sâu hơn về các chủ đề thiết kế hệ thống quan trọng khác nhau. Hãy điều chỉnh và hoàn thiện dựa trên thời gian và kinh nghiệm sau khi thu thập đủ thông tin về dự án mà bạn tham gia.
Làm sao để tiếp cận
Bước 1: Phác thảo các trường hợp sử dụng, ràng buộc và giả định Thu thập yêu cầu và phạm vi vấn đề. Hãy đặt câu hỏi để làm rõ các trường hợp sử dụng và các ràng buộc. Sau đó, thảo luận về các giả định.
- Ai là người sử dụng?
- Họ sẽ sử dụng hệ thống như thế nào?
- Có bao nhiêu người sử dụng hệ thống đó?
- Hệ thống đó làm những gì?
- Đầu ra và đầu vào của hệ thống đó là gì?
- Bạn mong muốn xử lý được bao nhiêu dữ liệu?
- Bao nhiêu yêu cầu/s?
- Tỷ lệ đọc/ghi dự kiến?
Bước 2: Thiết kế ở mức cao hơn Phác thảo thiết kế với tất cả các thành phần quan trọng của hệ thống.
- Phác thảo các thành phần và kết nối chính.
- Giải thích ý tưởng của bạn.
Bước 3: Thiết kế các thành phần cốt lõi của hệ thống Đi sâu vào từng thành phần cốt lõi. Ví dụ: Nếu bạn được yêu cầu thiết kế dịch vụ rút ngắn URL, hãy thảo luận về những vấn đề liên quan như:
-
Tạo và lưu trữ hash của URL:
- MD5 và Base62.
- Hash.
- SQL hay NoSQL.
- Sơ đồ cơ sở dữ liệu.
-
Giải mã URL đã được chuyển đổi từ hash thành URL đầy đủ:
- Tra cứu cơ sở dữ liệu.
-
API và thiết kế hướng đối tượng.
Bước 4: Quy mô của hệ thống Xác định và giải quyết các hạn chế và nút nghẽn. Ví dụ: Bạn cần những thành phần sau để giải quyết các vấn đề về khả năng mở rộng?
- Load Balancer.
- Scale theo chiều ngang.
- Caching.
- Bảo vệ cơ sở dữ liệu, không cho phép kết nối từ bên ngoài.
Thảo luận về các giải pháp liên quan đến các nguy cơ tiềm tàng và yêu cầu kinh doanh. Tất cả đều hướng tới mục tiêu thương mại. Giải quyết các trở ngại bằng cách sử dụng nguyên tắc thiết kế hệ thống khả năng mở rộng.
Tính toán
Có lẽ bạn sẽ được yêu cầu thực hiện các ước tính bằng tay. Dưới đây là chút chia sẻ của tôi về vấn đề này. Tuy nhiên, trong các bài viết tiếp theo, tôi sẽ đi sâu hơn vào các ví dụ cụ thể.
-
Back of the envelope: Tính toán đại khái. Đây là cách để làm tính toán vội vã, ví dụ như tính toán con số trên một mảnh giấy. Chúng ta thường sử dụng tờ báo gấp lại, vì nó dễ tìm. Công việc này được một vị nghị sĩ Mỹ sử dụng khi ông muốn ước tính chi phí của chương trình chăm sóc sức khỏe mới của Hoa Kỳ. Trong cuộc sống hàng ngày, chúng ta thường nghe ví dụ về một người thợ mộc ước tính giá của một tủ chén trong nhà bếp mà bà Wood muốn ông ta làm.
-
Power of two table: Đây là một khái niệm được mượn từ toán học, có nghĩa là một số lũy thừa của 2. Bảng này sẽ giúp bạn có câu trả lời nhanh hơn trong việc tính toán.
-
Latency numbers: Các con số về thời gian trễ mà bạn nên biết để sử dụng trong tính toán.
Chúng ta có bảng sau để tham khảo các con số về thời gian trễ:
| Thời gian trễ | Giải thích |
|---|---|
| L1 cache reference | 0.5 ns |
| Branch mispredict | 5 ns |
| L2 cache reference | 7 ns |
| Mutex lock/unlock | 100 ns |
| Main memory reference | 100 ns |
| Compress 1K bytes | 10,000 ns (10 us) |
| Send 1KB over 1 Gbps | 10,000 ns (10 us) |
| Read 4KB randomly from SSD | 150,000 ns (150 us) |
| Read 1MB sequentially from memory | 250,000 ns (250 us) |
| Round trip within same datacenter | 500,000 ns (500 us) |
| Read 1MB sequentially from SSD | 1,000,000 ns (1,000 us) |
| Send packet CA->Netherlands->CA | 150,000,000 ns (150,000 us) |
Chú thích:
- 1 ns = 10^-9 giây
- 1 us = 10^-6 giây = 1,000 ns
- 1 ms = 10^-3 giây = 1,000 us = 1,000,000 ns
Bài học rút ra được
- Tính toán "back of the envelope" giúp bạn đưa ra kết quả cho các trường hợp khác nhau.
- Khi thiết kế hệ thống, hãy liên tục sử dụng phương pháp tính toán này.
- "Back of the envelope" làm nền tảng cho các phần và khối của hệ thống của bạn, nhưng không đủ để tạo ra một thiết kế hoàn chỉnh. Bạn cần phải thực hiện thêm các bài kiểm tra cho các hệ thống con nhỏ hơn.
- Bạn không thể tính toán đúng nếu bạn không biết chính xác điều gì đang xảy ra trong hệ thống của bạn.
- Theo dõi và đo lường các thành phần của hệ thống của bạn để có thể dự báo từ dữ liệu thực.
Đó chỉ là chia sẻ và kinh nghiệm cá nhân của tôi. Tôi hy vọng sẽ nhận được sự chia sẻ và thảo luận từ phía bạn để hoàn thiện. Trong phần tiếp theo, tôi sẽ trình bày một ví dụ cụ thể về dịch vụ rút ngắn URL bao gồm bài tập và giải pháp. Mong nhận được ý kiến đóng góp từ bạn.
Tham khảo:
- The Back of the Napkin của Dan Roam
- A Physicist Explains Why Parallel Universes May Exist của Brian Green
- Latency numbers every programmer should know - 1
- Latency numbers every programmer should know - 2
- Designs, lessons, and advice from building large distributed systems
- Software Engineering Advice from Building Large-Scale Distributed Systems
