Chuyển từ JSON sang Protobuf. Nó có đáng không?


23

Chúng tôi có các dịch vụ web REST có thể phục vụ XML hoặc JSON (WCF). Tôi đang chơi với ý tưởng thực hiện Protobufs. Tại sao?

PROS

  1. Tải ít hơn trên các máy chủ.
  2. Kích thước tin nhắn nhỏ hơn - lưu lượng truy cập ít hơn.
  3. Bây giờ thì dễ dàng chuyển đổi hơn sau này.

TIÊU DÙNG

  1. Cần phải được thực hiện
  2. Sẽ khó khăn hơn để khắc phục sự cố / đánh hơi các thông báo để gỡ lỗi.
  3. Tôi có thể kích hoạt GZip trên máy chủ và JSON sẽ tiêu thụ nhiều lưu lượng truy cập

Đề xuất và / hoặc kinh nghiệm của bạn về điều này là gì?


1
Tôi đã xem trang wikipedia và thực sự có nhiều ký tự hơn cho mỗi cặp khóa-giá trị, vậy tại sao liều nó lại có thông điệp nhỏ hơn?
Ramzi Kahil

Vì tuần tự hóa. Dữ liệu nhị phân đi qua dưới dạng nhị phân (ví dụ mảng byte). Ngoài ra, nó không mang tên tài sản trong một tin nhắn. Họ đi theo chức vụ tài sản. developers.google.com/protatio-buffers/docs/encoding#structure
katit

10
Về mặt kỹ thuật, bạn đã trả lời câu hỏi của riêng mình, nén JSON và được thực hiện với nó. Quan trọng nhất là bạn không bao giờ đề cập đến một trường hợp kinh doanh thực tế để chi tiền và thời gian cho hoạt động này.

Câu trả lời:


39

Liệu giá trị kinh doanh của việc thực hiện chúng vượt quá chi phí?

Nếu bạn triển khai, bạn cần thay đổi không chỉ máy chủ của mình, mà tất cả các máy khách (mặc dù bạn có thể hỗ trợ cả hai định dạng và chỉ thay đổi máy khách khi cần). Điều đó sẽ mất thời gian và thử nghiệm, đó là một chi phí trực tiếp. Và đừng đánh giá thấp thời gian thực sự hiểu bộ đệm giao thức (đặc biệt là lý do để tạo trường bắt buộc hoặc tùy chọn) và thời gian để tích hợp trình biên dịch protobuf vào quá trình xây dựng của bạn.

Vì vậy, giá trị vượt quá đó? Bạn có phải đối mặt với lựa chọn "chi phí băng thông của chúng tôi là X% doanh thu của chúng tôi và chúng tôi không thể hỗ trợ điều đó"? Hay thậm chí "chúng ta cần chi 20.000 đô la để thêm máy chủ để hỗ trợ JSON"?

Trừ khi bạn có nhu cầu kinh doanh cấp bách, "ưu điểm" của bạn không thực sự thuận, chỉ là tối ưu hóa sớm.


23

tôi duy trì apis và ai đó trước khi tôi thêm protobuf (vì nó "nhanh hơn"). Điều duy nhất nhanh hơn là RTT vì tải trọng nhỏ hơn và có thể được sửa bằng JSON được nén.

Phần gây khó chịu cho tôi là công việc tương đối để duy trì protobuf (so với JSON). Tôi sử dụng java vì vậy chúng tôi sử dụng ánh xạ đối tượng Jackson cho JSON. Thêm vào một phản hồi có nghĩa là thêm một trường vào POJO. Nhưng đối với protobuf, tôi phải sửa đổi tệp .proto, sau đó cập nhật logic tuần tự hóa và giải tuần tự hóa để di chuyển dữ liệu vào / ra khỏi bộ đệm giao thức và vào POJO. Nó đã xảy ra hơn một lần rằng một bản phát hành đã xảy ra khi ai đó đã thêm một trường và quên đặt mã tuần tự hóa hoặc giải tuần tự hóa cho bộ đệm giao thức.

Bây giờ khách hàng đã thực hiện chống lại bộ đệm giao thức, gần như không thể thoát khỏi.

Bạn có thể đoán từ điều này, lời khuyên của tôi là không làm điều đó.


5
Nếu bạn đang viết (de) mã tuần tự hóa để di chuyển dữ liệu vào / ra khỏi POJO, bạn đã làm sai. Chỉ cần sử dụng các lớp được tạo ra protobuf trực tiếp.
Marcelo Cantos

Tôi nghĩ rằng trong trường hợp đó, tôi đã chuyển vào / ra khỏi POJO vì cơ sở mã đã hỗ trợ cả các yêu cầu / phản hồi JSON, XML và Protobuf và cho rằng tôi không thể thêm các chú thích của Jackson và / hoặc JAXB vào các lớp được tạo ra bởi protobuf và tôi muốn để sử dụng cùng các đối tượng mô hình trong suốt mã, tôi không biết rằng tôi có các tùy chọn chỉ sử dụng các lớp được tạo. Tôi có thể thấy làm thế nào điều này có thể làm được nếu tôi viết rằng các dịch vụ GRPC chỉ nói về protobuf.
Kevin
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.