乾物|Apiアーキテクチャ共有(上)

最近、apiのデザインをしています
設計については,一方ではバックエンドサーバフレームワークの設計であり,他方ではapiシステム全体の設計である.
ここでは、私たちは考えを整理して、まず大体分けてみましょう.
スタイルはもちろん、restfulスタイルを使います.次は:

IDL、すなわちインタフェース記述言語

serverフレームワーク、apiサービス全体のコアドライバ

バージョン管理

自動化ツール、認証認証、レポートの監視、ログの記録、検索などの補助ツールもあります

そして、それぞれのデザイン開発における感触についてお話しします.
IDL
名前の通り、IDLは私たちのapiシステム全体の核心モデルであり、基本的にすべてのものは私たちのIDLに基づいており、使用の選択には多くのものがあります.例えば、Yaml、Json、xml、PBなどです.これらはインタフェースとして言語を記述することができます.
Json:Jsonは安定して広く応用されているシーケンス化フォーマットであり、ブラウザはこのフォーマットに対する原生解析能力を含み、ブラウザ内蔵デバッガもこのような内容をよく表示することができる.唯一の欠点は、Json解析器/シーケンス器を備えなければならないことです.基本的なすべての言語で提供されています.Jsonを使用する最も主要な面倒なのは、各情報が属性名を繰り返し含むため、伝送効率が低下することです.また、Jsonはapi開発中に発生する可能性のある特殊な需要に対してうまく処理できない可能性があります.例えば、フィールド間の依存関係は、簡単に描写できません.
Yaml:Yamlを使用して私たちのapiモデルを定義すると、非常に簡潔明瞭ですが、apiモデルの複雑な構造やフィールドの自己検出については、あまりサポートされていません.また、このフォーマットも開発で約束しにくく、不要なトラブルを引き起こす可能性があります.
PB:PBのフルネームはProtocol Buffersで、グーグルが作成したバイナリ接続フォーマットに基づくインタフェース記述言語です.解析とネットワーク転送の面でProtocol Buffersの方が効率的で、グーグルの高負荷環境の試練を経験しました.一部の言語のサポートがあまりよくないのは、主にC、python、javaのサポートです.そして、.protoファイルの共有とコンパイルの面では、追加の開発負担が発生します.
xml:これはみんなよく知っています.JsonとYamlに比べて、xmlは少し重いように見えますが、xmlはいろいろな特殊なシーンによく応用できます.絶えずオンラインの需要に応じてさらに拡張することができます.また、xsdを通じて直接自己検査を行うことができます.機能的には、もっと完備するかもしれません.
IDLは私たちのapiの核心なので、これからの各業務は基本的にIDLをめぐって展開しなければならないので、機能が完備して、拡張しやすくて、しかも開発の中でいくつか自動化のツールが制約を行うことができて、so、最終的には、やはりxmlの形式を採用することを決定します
serverフレームワーク
コアコードは非常に簡単で、ルート呼び出しを実現するためにrouteを書くだけでいいのですが、正常な呼び出しを支援するためには、より多くの補助機能を実現しなければなりません.
私の基本的なディレクトリ構造を見てみましょう

Framework
    │
    ├── Auth          、    
    │
    ├── Base            
    │
    ├── Client           
    │
    ├── Common          
    │
    ├── Core              
    │
    ├── Coroutine         
    │
    ├── Exception       
    │
    ├── Http            
    │
    ├── Log             ，    
    │
    ├── Pool           （   ）
    │
    └── Resource        

同时に、开発の过程の中で各モジュールの间の依存関系を下げて、例えば、newの1つの対象より、setの方式を采用して解结して、継承を予想して、组み合わせの方式を采用して、各モジュールの独立性を保证して、同时に各モジュールの间にまた1つの通信通路があります
いくつかの特殊な需要を実現するために、私たちは協程スケジューリングを採用して非ブロックIOを実現します.もちろん、ここではswooleやworkermanのように、独立したサービスプロセスを記述する個別のサービスポートの傍受を実現する必要があります.
OK、上にも言及しましたが、コアコードは1つのrouteルーティングを実現すればいいのですが、ルーティングの前後に認証、認証インタフェースを残すことを忘れないでください.
ところで、これらのserverサービス依存に加えて、データも注意してください.元のデータの上にデータインタフェース層を単独で抽出して、元のデータを直接操作しないほうがいいです.
これらのコアサービスが完了した後、残りはクライアントとサービス側のコードであり、これは実際のサービスによって自由に発揮することができ、apiに対してもクライアントコードをSDKと呼ぶことができる.
OK、前編ではここまでにしましょう.主にserverフレームワークやIDLのデザイン選択の考え方について話しました.
次は、主にapiのバージョン管理、リリース、自動化ツールについて共有します.
From:アニメが大好きな城を攻めるライオン