Protocol buffers là gì và những điều cơ bản cần biết về nó

Trước tiên có thể chúng ta đã khá quen thuộc có REST servive. REST service có thể được gọi là 1 phương pháp để trao đổi dữ liệu đơn giản giữu Consumer và Server. Kỹ thuật giao tiếp dựa trên văn bản đơn giản (JSON, XML), dễ học, dễ gỡ lỗi hơn. Hiện nay có thể nói nó khá phổ thông} và có khá nhiều công cụ như Postman, Insomnia … cũng tồn tại để giúp những Developer phát triển thành những API dễ ràng hơn. Trong bài viết này chúng ta sẽ tìm hiểu về 1 kiểu trao đổi dữ liệu ok bắt buộc là new nữa nhưng nó có thể hữu ích là Protobuf.

Protocol buffer còn được biết như protobuf là language-neutral, platform-neutral của google phiên bản nội bộ được công bố vào 5 2001 và phiên bản công khai trước tiên được giới thiệu vào 5 2008 ( Repository ), về cơ bản nó được sủ dụng để Serialized object, có vẻ nó khá giống XML hoặc JSON. Nó lưu trữ dữ liệu có cấu trúc có thể được Serialize hoặc De-Serialized tự động động bưởi nhiều ngôn ngữ khác nhau. Nó được thiết kế để trở nên language/platform impartial và có thể mở rộng. Hiện tại, protobuf có tương trợ cho C ++, C, Go, Java và Python.

Protobuf là 1 open supply dùng để encode dữ liệu có cấu trúc được phát triển thành tại google. Nó siêu hữu ích trong việc phát triển thành những chương trình để giao tiếp có nhau qua 1 wire hoặc để lưu trữ dữ liệu. Đa số những gì bạn bắt buộc khiến là chỉ định 1 thông tin cho từng cấu trúc dữ liệu mà bạn muốn Serialize (theo định dạng giống như lớp Java) bằng phương pháp dùng file đặc tả .proto.

Từ file .proto compiler của protobuf ( protoc ) tạo ra code thực hành encode tự động động và phân tách cú pháp dữ liệu protobuf có định dạng Binary hiệu quả, tùy thuộc} thuộc vào từng ngôn ngữ nó sẽ tạo ra mã tương ứng .

Dưới đây chúng ta sẽ đề cập tới ưu và nhược điểm của Protocol buffer và 1 số kiểu khác.

Xem Thêm  Chuẩn Bị Đồ Ăn Đi Picnic Cần Gì? 7 món ăn cắm trại picnic NGON, DỄ LÀM – Travelgear Weblog

Protobuf

  1. Dữ liệu siêu dày đặc, đầu ra bé.
  2. Khó decode mà ko biết schema, định dạng dữ liệu ko rõ ràng và cần schema để biết rõ.
  3. Xử lý siêu nhanh, bé hơn 3 – 10 lần so có XML hoặc JSON
  4. ko dành cho con người vì là Binary.
  5. Tạo những code truy cập dữ liệu dễ dùng hơn theo chương trình.

JSON

  1. Con người có thể có thể đọc và chỉnh sửa dễ dàng.
  2. Có thể phân tách cú pháp mà ko cần biết schema.
  3. Những browser đều tương trợ siêu phải chăng.
  4. Ít dài dòng hơn XML.

XML

  1. Con người có thể có thể đọc và chỉnh sửa dễ dàng.
  2. Có thể phân tách cú pháp mà ko cần biết schema.
  3. Tiêu chuẩn cho SOAP…
  4. Tương trợ phải chăng những công cụ như xsd, xslt, sax, dom …

Protobuf siêu nhanh nhưng nhưng nhưng có những những tình trạng chúng ta ko nên dùng nó. Thí dụ như những tình trạng dưới đây

  1. Lúc bạn cần hoặc muốn dữ liệu con người có thể đọc dễ dàng.
  2. Dữ liệu từ Service được dùng quản lý bởi Browser.
  3. Server của bạn viết bằng ngôn ngư khác như Javascript
  4. Gánh nặng hoạt động của việc vận hành 1 loại dịch vụ mạng khác là quá lớn

Phương pháp dùng.

Từng file .proto khởi đầu bằng 1 khai bundle , giúp ngăn chặn xung đột đặt tên giữa những Mission khác nhau. Về cơ bản, bạn sẽ xác định phương pháp bạn muốn dữ liệu của mình được cấu trúc, dùng 1 mesage format, trong file .proto. File này được dùng bởi protoc sẽ tạo ra 1 file được định nghĩa sẵn những phương thức để bạn có thể Serialize và Deserialize, theo ngôn ngữ mà bạn chỉ định (Java, Golang, Python, … ) Bạn có thể xác định 1 loại message trong .proto như sau. Bạn có thể hiểu xem thêm dí dụ tại developer google.

// Request message for creating a brand new buyer message CustomerRequest { int32 id = 1; // Distinctive ID quantity for a Buyer. string title = 2; string e mail = 3; string telephone= 4; message Handle { string avenue = 1; string metropolis = 2; string state = 3; string zip = 4; bool isShippingAddress = 5; } repeated Handle addresses = 5; } message CustomerResponse { int32 id = 1; bool success = 2; } message CustomerFilter { string key phrase = 1; }

Xem Thêm  phương pháp chơi name of obligation 2 multiplayer – AU3D.VN

Từng loại message có 1 hoặc nhiều discipline được đánh số duy nhất Những loại message lồng nhau có tập hợp những trường được đánh số duy nhất của riêng chúng. Những loại giá trị có thể là Quantity, Boolean, String, Byte,cũng có thể là Assortment và Enumeration. Bên cạnh ra, bạn có thể lồng những loại message khác, cho phép bạn cấu trúc dữ liệu theo thứ bậc theo phương pháp tương tự động như JSON cho phép bạn.

Chỉ định Subject kind

Những Subject óc thể được chỉ định là optionally available, required, hoặc repeated. Ko cho phép những Subject kind ( enum, int32, float, string … ). Những Subject kind chỉ là gợi ý để bảo vệ về phương pháp Serialize 1 giá trị Subject và tạo định dạng được mã hóa Message của Message của bạn. Định dạng được mã hóa trông giống như 1 biểu diễn phẳng và nén của đối tượng của bạn. Bạn sẽ viết đặc tả này theo cùng 1 phương pháp chính xác cho dù bạn đang dùng protobuf trong Python, Java hay C ++.

Chỉ định Tag

Từng Subject trong định nghĩa Message có 1 Tag được đánh số duy nhất. Những Tag này được dùng để xác định những Subject của bạn tại định dạng Message binary và ko nên thay đổi đổi lúc loại Message của bạn được dùng. Lưu ý rằng những Tag có giá trị trong phạm vi từ 1 tới 15 mất 1 byte để mã hóa, bao gồm số nhận dạng và Subject kind (bạn có thể tìm hiểu thêm về điều này trong Mã hóa Protobuf). Những thẻ trong phạm vi 16 tới 2047 mất 2 byte. Vì vậy, bạn nên dành những thẻ từ 1 tới 15 cho những khía cạnh thông tin xảy ra siêu thường xuyên.

Số thẻ bé nhất bạn có thể chỉ định là 1 và lớn nhất là 229 – 1 hoặc 536.870.911. Bạn cũng ko thể dùng những số 19000 dù rằng 19999 vì chúng được dành riêng cho việc triển khai Protobuf – compiler sẽ khiếu nại trường hợp bạn dùng 1 trong những số dành riêng này trong .proto của nó. Tương tự động, bạn ko thể dùng bất kỳ Tag dành riêng trước ấy.

Xem Thêm  Katarina Mùa 11: Phương pháp Chơi Katarina Prime, Bảng Ngọc Và Phương pháp Lên Đồ Katarina Construct Mùa 11 – LOL Truyền Kỳ

Chỉ định quy tắc Subject

Bạn xác định những Message discipline là 1 trong những điều sau đây

  1. required: Đối có những required discipline, giá trị ban đầu bắt buộc được phân phối, trường hợp ko discipline ko được khởi tạo.
  2. optionally available: Đối có những optionally available discipline, trường hợp ko khởi tạo, thì giá trị mặc định sẽ được gán cho discipline, tất nhiên, bạn có thể chỉ định giá trị mặc định.
  3. repeated: Subject có thể được lặp lại bất kỳ số lần, trong 1 message được hình thành phải chăng. Thứ tự động của những giá trị lặp lại sẽ được bảo tồn.

Lưu ý: những trường lặp lại của những kiểu scalar numeric ko được mã hóa hiệu quả nhất có thể. Mã new nên dùng tùy thuộc} chọn đặc biệt [pack = true] để có được mã hóa hiệu quả hơn. như dưới đây

repeated int32 samples = 4 [packed=true];

Enumerations

Lúc bạn xác định loại message, bạn có thể muốn 1 trong những discipline của nó chỉ có 1 trong danh sách giá trị được xác định trước.

enum Foo { FIRST_VALUE = 0; SECOND_VALUE = 1; }

Protocol Buffer phân phối 1 số lợi thế hấp dẫn so có JSON, XML … để gửi dữ liệu qua mạng giữa những inside service. Mặc dầu ko bắt buộc là sự thay đổi thế hoàn toàn cho JSON, XML, đặc biệt là những dịch vụ được dùng quản lý bởi trình thông qua internet, Protocol Buffer phân phối những lợi thế siêu thực tế ko chỉ tại những phương pháp được nêu tại trên, mà còn về tốc độ mã hóa và giải mã, kích thước của dữ liệu trên dây, và nhiều hơn nữa.