ZeroFormatter/MagicOnion - Fastest C# Serializer/gRPC based C# RPC

11.491 visualizaciones

Publicado el

#kbkz_tech
https://github.com/neuecc/ZeroFormatter

Publicado en: Tecnología
0 comentarios
4 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
11.491
En SlideShare
0
De insertados
0
Número de insertados
9.491
Acciones
Compartido
0
Descargas
6
Comentarios
0
Recomendaciones
4
Insertados 0
No insertados

No hay notas en la diapositiva.

ZeroFormatter/MagicOnion - Fastest C# Serializer/gRPC based C# RPC

  1. 1. Work C# Unity Private http://neue.cc/ @neuecc https://github.com/neuecc/UniRx
  2. 2. Message Format
  3. 3. XML JSON Protocol Buffers MsgPack Thrift Avro FlatBuffers Cap’n Proto
  4. 4. パフォーマンス #とは その他
  5. 5. 遅い、(特に)(古い)Android遅い...
  6. 6. 遅い、(特に)(古い)Android遅い...
  7. 7. 秘訣は...
  8. 8. 無限大高速なシリアライザ https://github.com/neuecc/ZeroFormatter/ シリアライズも速い
  9. 9. 無限大高速なシリアライザ https://github.com/neuecc/ZeroFormatter/ シリアライズも速い
  10. 10. アクセサーとしてのオブジェクト
  11. 11. 全部は必要ない
  12. 12. C#自体をスキーマとみなす
  13. 13. 継承みたいなやつをネイティブサポート [Union(typeof(Human), typeof(Monster))] public interface ICharacter { [UnionKey] int TypeId { get; } } public class Human : ICharacter { public int TypeId => 0; } public class Monster : ICharacter { public int TypeId => 1; }
  14. 14. Welcome to contribute! Ruby https://github.com/aki017/zero_formatter Swift https://github.com/yaslab/ZeroFormatter.swift
  15. 15. RPC
  16. 16. 言語の違うREST Response型を別々 に書く APIクライアント を手書きする (ザ・マイクロ サービスみたいな 構成)
  17. 17. 言語の違うREST Response型を別々 に書く APIクライアント を手書きする (ザ・マイクロ サービスみたいな 構成) 中間IDLを書く そこからクライア ント・レスポンス 型自動生成 (←を嫌う時によ くある構成、一番 メジャー)
  18. 18. 自動生成はダルい 自動化は(必ずしも)よくない
  19. 19. 言語の違うREST Response型を別々 に書く APIクライアント を手書きする (ザ・マイクロ サービスみたいな 構成) 中間IDLを書く そこからクライア ント・レスポンス 型自動生成 (←を嫌う時によ くある構成、一番 メジャー) サービスを普通に 書く、そこからク ライアントを自動 生成、リクエス ト・レスポンス型 はC#のDLLとして 共有
  20. 20. 言語の違うREST Response型を別々 に書く APIクライアント を手書きする (ザ・マイクロ サービスみたいな 構成) 中間IDLを書く そこからクライア ント・レスポンス 型自動生成 (←を嫌う時によ くある構成、一番 メジャー) サービスを普通に 書く、そこからク ライアントを自動 生成、リクエス ト・レスポンス型 はC#のDLLとして 共有 サービスを普通に 書く、クライアン トはそのプロジェ クト参照から実行 時動的生成
  21. 21. gRPC based C# Network Framework gRPCの性能や安定性 + C#的な使いやすさ
  22. 22. public class TestService : MagicOnionService { // ふつーにpublicメソッドを定義するだけ public async Task<int> Sum(int x, int y) { return x + y; } public async Task<string> Download(string url) { // 非同期もasync/await構文で同期的にOK var result = await new HttpClient().GetStringAsync(url); return result; } } // ふつーのgRPCのコネクション var channel = new Channel("127.0.0.1:12345"); // .Service<T>でクライアントが実行時動的生成されてシームレスに呼び出し可能 var result = await new MagicOnionClient(channel).Service<TestService>().Sum(100, 200); struct ZeroFormatter$AutoGenerate$1 { public int x; public int y; }
  23. 23. gRPC IN(byte[]) gRPC OUT(byte[]) RPC Method Middleware IDL Less HandlerSelector HTTP1 Gateway Swagger SerializerSelector(ZeroFormatter, JSON)
  24. 24. 機能
  25. 25. Conclusion
  26. 26. C#で統一することの強み 言語単体で優劣を語ってもそこまで意味はない XはY言語だから出来た!という話は、大抵は別にPHPでもCでもな んでも、普通に出来る次元の話がほとんど。特に関数型言語の人に多い話な気もしますが が、システム全体で統一していくことにより、強みを乗算する 単一であることの弱みは当然ある(No Silver Bullet)が、それを遥か に勝る強みを作っていくことで最高の環境にしていきたい (Windows Serverに対するコダワリはないのでLinuxでは動かしたい!) パフォーマンスは最大の機能 ZeroFormatterもMagicOnionも、それを最も強く意識してる
  27. 27. using

×