#169 - Tectonic: Hệ thống tập tin phân tán của Facebook
Nhằm tìm hiểu tâm tư, mong đợi của các bạn đang làm về phần mềm nói riêng và IT nói chung về công ty hiện tại / tương lai, một đối tác của Grokking muốn mời các bạn trong cộng đồng thực hiện khảo sát nhỏ này. Mong các bạn có thể dành vài phút để chia sẻ vài suy nghĩ. 40 bạn may mắn sẽ được chọn ngẫu nhiên và nhận được voucher GOT IT 200.000đ từ nhà tài trợ.
Những bài viết hay
22 Best Practices to Take Your API Design Skills to the Next Level — betterprogramming.pub
Bạn đã bao giờ cảm thấy khó chịu khi làm việc với một API, nơi mọi thứ đều như một trò chơi đoán mò? Design một API tưởng chừng đơn giản, nhưng bạn có chắc cách bạn làm bấy lâu nay có theo một quy chuẩn nào không?
Nếu ứng dụng của bạn chỉ đơn giản bao gồm một web page gọi đến một backend service để lấy dữ liêu, việc thiết kế API một cách xấu xí có lẽ cũng không phải vấn đề lớn. Tuy nhiên, trong một thiết kế microservices phức tạp với nhiều team khác nhau, thiết kế và duy trì nhiều services tương tác với nhau qua các API call, một thiết kế nhất quán và tuân thủ theo các nguyên tắc nhất định cho API của một service là điều không thể thiếu.
Trong bài viết, tác giả có nêu ra 22 nguyên tắc giúp chúng ta design API cho 1 backend service một cách nhất quán, hiệu quả, và thân thiện cho người dùng.
Một số kĩ thuật được tác giả nêu ra như:
Sử dụng kebab-case cho endpoints: /system-orders thay vì /system_orders hay /systemOrders
Sử dụng camelCase cho các parameters
Không sử dụng các động từ để thể hiện ý định của bạn trong URL. Thay vào đó, hãy sử dụng các phương thức HTTP thích hợp để mô tả hoạt động: PUT /user/{userId} thay vì POST /updateuser/{userId} hay GET /getusers
Sử dụng camelCase cho JSON property
Implement các endpoints như /health, /metrics, /version cho mục đích monitoring
Sử dụng API Design Tools như Swagger, giúp cung cấp documentation và trải nghiệm thân thiện cho người dùng API của bạn.
Hãy versioning API của bạn
Sử dụng các biến limit and offset
Không pass Authentication Tokens trong URL
Cách thức hỗ trợ CORS (Cross-Origin Resource Sharing)
Các nguyên tắc vàng bạn cần biết
Design Mistakes You’re Making with Your Mobile Forms (and How to Fix Them) — www.telerik.com
Do thị trường smartphone ngày càng gia tăng và người tiêu dùng bắt đầu sử dụng điện thoại của họ ngày càng nhiều cho việc lướt web, cách thiết kế Progressive Web App (PWA) trở nên phổ biến hơn khi mà bạn cần website của bạn có thể hỗ trợ được trên smartphones. Các công ty lớn đa phần sẽ có một nhóm designers để giúp các bạn lập trình viên thiết kế giao diện cho PWA trên mobile. Tuy nhiên, với các công ty nhỏ hay các team thiếu nhân lực thì việc các lập trình viên như chúng ta gánh luôn mảng thiết kế là điều khó thể tránh khỏi.
Bài viết sau đây được tác giả. Suzanne Scacca, nói cụ thể hơn về những lỗi thiết kế hay mắc phải khi chúng ta cần lập forms trên mobile. Một vài ví dụ điển hình như là:
Thiết kế form như thế nào để người dùng dễ dàng tìm thấy
Củng cố phần thẩm định lỗi trên form
Đơn giản hóa cho cách thành phần tự động như là autofill
[Design Pattern] Liệu bạn có thực sự hiểu về Singleton pattern? — batnamv.medium.com
Singleton Pattern là một trong những design patterns phổ biến khi bạn chỉ cần duy nhất một object instance của một class tồn tại trong suốt quá trình vận hành của một application đó. Chắc hẳn chúng ta cũng không mấy xa lạ gì với singleton pattern và chắc cũng viết code cho singleton pattern ít nhất một lần trong đời, đặc biệt là đối với các lập trình viên về Java.
Tuy nhiên, để mà viết một singleton pattern hoàn hảo với hiệu suất tốt và không gặp phải những trường hợp đặc biệt về race conditions cho multi-threaded applications, chúng ta cần phải hiểu rõ hơn về cách bố trí và vận hành của các singleton classes trong ứng dụng của chúng ta như thế nào. Bài viết sau đây được tác giả Nam Vu nói cụ thể hơn về các vấn đề thường gặp khi thiết kế một class theo singleton pattern.
Góc Data Warehouse
Facebook’s Tectonic Filesystem: Efficiency from Exascale
Trong những năm gần qua, lượng dữ liệu ở Facebook ngày càng gia tăng từ vài trăm petabyte lên tới vài exabyte. Đa phần các lượng dữ liệu này tập trung 2 mảng chính là: BLOB cho hình ảnh hay video, và dữ liệu phân tích cho data warehouse.
Bên mảng BLOB thì Facebook có 2 hệ thống storage chính là Haystack và f4 để lưu trữ dữ liệu. Haystack được dùng để chứa hot BLOB và f4 được dùng để chứa warm BLOB. Còn bên mảng data warehouse thì Facebook tận dụng HDFS để chứa các ORC file của họ cho Hive. Tuy nhiên, với mỗi hệ thống storage đặc biệt cho mỗi use case và mỗi hệ thống có một hạn chế về lưu lượng khác nhau (như là Haystack sẽ có hạn chế về disk I/O per second do được truy vấn nhiều hơn so với f4 warm storage), các đội ngũ kỹ sư ở nhóm storage bên Facebook đã quyết định thành lập hệ thống Tectonic.
Tectonic là một hệ thống tập tin phân tán (distributed filesystem) có thể scale dữ liệu tới hàng exabyte. Mục tiêu chính của Tectonic là thay thế HDFS để scale tốt hơn và gộp Haystack, f4, và HDFS lại với nhau thay vì có 3 hệ thống storage riêng biệt.
Tectonic có 4 bộ phận chính là:
Client library: Là thư viện chính để các clients tiếp cận với Tectonic. Client sẽ có thể tạo, truy vấn, và xóa một file bằng cách giao tiếp với metadata store và chunk store
Metadata store: Là nơi chứa dữ siêu dữ liệu về các files và cung cấp client library nơi mà clients có thể viết dữ liệu trên chunk store
Chunk store: Là nơi chứa dữ liệu tập tin chính cho toàn bộ hệ thống Tectonic
Background services: Là một bộ phận bao gồm nhiều dịch vụ để quản lý Tecttonic như là: garbarge collector, rebalancer, block repair, …
Nhìn chung thì mô hình thiết kế của Tectonic khá là giống với cách hệ thống storage phân tán khác (như là HDFS, Google Filesystem, …). Tuy nhiên, Tectonic có vài điểm đặc trưng lên được nêu lên trong bài báo để giúp hệ thống hoạt động hiệu quả hơn. Một vài điển hình như là:
Metadata store được partitioned thành 3 mảng chính là: Name layer, File layer, và Block layer. Mỗi mảng này sẽ được chứa trong ZippyDB, một key-value store được thành lập bởi Facebook. Do việc partition metadata như thế này và tận dụng một remote key-value store riêng biệt, Tectonic có thể scale tốt hơn HDFS NameNode khi mà HDFS chứa tất cả metadata cho cluster lên chỉ một NameNode. Tuy nhiên, cách thiết kế như thế này sẽ làm tăng độ trễ của hệ thống Tectonic khi truy vấn metadata so với HDFS NameNode khi tất cả metadata được chứa trên memory ở máy NameNode
Tectonic chia các tenants thành nhiều nhóm và bậc khác nhau để giúp cải thiện việc chia sẻ tài nguyên hệ thống một cách hiệu quả hơn giữa các tenants, đặc biệt khi Haystack dùng lượng chứa đĩa ít nhưng cần disk I/O per second nhiều, trong khi f4 warm storage thì ngược lại.
Tectonic được các đội ngũ kỹ sư ở Facebook công bố trên hội nghị File and Storage Technologies (FAST) vào đầu năm nay. Đây là bài báo về Tectonic nếu các bạn muốn tìm hiểu thêm về hệ thống này.
Code & Tools
This Week Sponsors
LINE đang tích cực tìm kiếm nhiều nhân tố ở các vị trí chủ chốt để đáp ứng nhu cầu phát triển mạnh mẽ của hệ sinh thái LINE. Đặc biệt, trong vai trò Engineering Manager và Project Leader, các bạn sẽ có cơ hội tác động tích cực đến sự phát triển của con người, tổ chức, sản phẩm và hàng trăm triệu người dùng.
Góc Tuyển Dụng
Tham khảo các vị trí khác tại trang LINE Technology Vietnam
Quotes
What one programmer can do in one month, two programmers can do in two months.
- Fred Brooks