約3年前、私は小さなサービスを開発するための小さなフレームワークを作成して、何らかの形で相互にやり取りし、外部でAPIを提供し、データベースなどと連携できるアイデアを思いつきました。 いくつかの作業タスクの解決中に、作業タスクの解決に近いプロジェクトのアイデアが最終的に形成されました。 約1年前、これらすべてがMIF（MetaInfo Framework）プロジェクトを形成しました。 その助けを借りて、次のような問題を解決できると想定されました。

• 軽量HTTPサービスの開発
• プロセス間で転送されるインターフェースを介したマイクロサービス通信
• さまざまな形式のデータ構造の反映に基づくシリアル化と逆シリアル化
• データベースを操作する
• サービスワイヤフレームを作成するためのいくつかのヘルパーコンポーネント

これらはすべて、Web用のバックエンドサービスの開発に焦点を当てていますが、他のシステムでも使用できます。

はじめに

新しいC ++標準のリリース、次の準備。 年が経ちますが、C ++には反映がありません。 C ++でのリフレクションの出現の可能性が議論され、次の標準に含まれるように思われました。 いいえ...たぶん反射は必要ありませんか？ たぶん...しかし、それが役立つ可能性のあるタスクがあります：プロセス間通信（IPC、RPC、REST API、マイクロサービス）、データベース（ORM）の操作、さまざまな（de）シリアライザーなど。 -一般的に、申請の余地があります。



コンパイラにはすべての型情報があり、開発者と共有してみませんか？ 私は、コンパイラ開発者がこの情報を他のソフトウェアの正直な開発者に公開すべき文書が単に存在しないと仮定しようとします。 このようなドキュメントはC ++標準であり、「マーチャンダイジング」規制は一切ありません。



多くの言語にはリフレクションがあります。 C ++は、生産性が重要なプログラムを開発するための言語と考えられており、アプリケーションの分野の1つはWeb開発です。 バックエンドサービスの開発。 この業界には、REST API、ORM、およびあらゆるものへのあらゆる種類のシリアル化があります（多くの場合jsonで）。 これらの問題を解決するには、既製のライブラリを使用するか、独自のライブラリを作成する必要があります。C++データは、C ++の構造をjson形式にマッピングするなど、他のエンティティと手動で接続します。 マクロの助けを借りて、タイプに関するメタ情報が追加されることがあります。これは、後でREST API、ORMなどの構築で使用されます。 odbなど、コンパイラ用のプラグインを使用したソリューションもあります。



外部ユーティリティによるコード生成、マクロとテンプレートの積み重ね、または手動の「マッピング」なしで、もっと自然なものにしたいと思います。 これはまだ利用できません。これらの問題を解決するには、上記のアプローチのいずれかを選択する必要があります。



提案されたソリューションは、C ++型にメタ情報を追加し、その後さまざまな問題を解決する際に使用することに基づいています。 「タイプは彼に関するメタ情報でラップする必要があります」と言うことができます。その後、彼はプロセスとデータセンターの境界を大胆に歩き、最小限の開発者の介入でさまざまな方法（バイナリ、json、xml、テキストなど）で自分自身を提示できます。



多くの場合、そのようなタスクは、コード生成、たとえばthrift 、 gSOAP 、 protobufなどを使用して解決されます。 外部コード生成を除外する独自のソリューションを取得したかったため、必要なものはすべてコンパイル時に型に追加されると同時に、既存の言語で新しい言語を作成せずに、C ++言語の自然な構文を可能な限り保持したいのです。

例のMIF

MIFプロジェクトのいくつかの機能を紹介したいと思います。 投稿へのフィードバックでは、おそらく、このソリューションまたはそのソリューションが選ばれた理由のすべてのトリック、微妙さ、および説明を含む実装に関する投稿を準備します。



投稿の冒頭にリストされているタスクは、シリアル化、オブジェクト指向のプロセス間通信、REST API実装などのC ++データ型を表示する機会があることを示唆しています。 これで私は提案して開始します...

反射

リフレクションはプロジェクト全体の基礎であり、これにより、適用された問題を解決できます。



C ++データ構造の名前、そのフィールドの数を取得し、その番号でフィールドの1つにアクセスする方法の例。

struct Data { int field1 = 0; std::string field2; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題の解決策は次のようになります。

 int main() { Data data; data.field1 = 100500; data.field2 = "Text"; using Meta = Mif::Reflection::Reflect<Data>; std::cout << "Struct name: " << Meta::Name::GetString() << std::endl; std::cout << "Field count: " << Meta::Fields::Count << std::endl; std::cout << "Field1 value: " << data.field1 << std::endl; std::cout << "Field2 value: " << data.field2 << std::endl; std::cout << "Modify fields." << std::endl; data.*Meta::Fields::Field<0>::Access() = 500100; data.*Meta::Fields::Field<1>::Access() = "New Text."; std::cout << "Field1 value: " << data.field1 << std::endl; std::cout << "Field2 value: " << data.field2 << std::endl; return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてがこのようになっていたはずです。少し異なって書かれていますが、この標準ではC ++データ型をそれほど簡単に表示することはできません。 そして、指定されたコードを機能させるには、メタ情報をデータ構造に追加する必要があります

 MIF_REFLECT_BEGIN(Data) MIF_REFLECT_FIELD(field1) MIF_REFLECT_FIELD(field2) MIF_REFLECT_END() MIF_REGISTER_REFLECTED_TYPE(Data)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

型のメタ情報を型自体に追加して、拡張できます。 コードとの干渉が不可能なタイプ（サードパーティライブラリのタイプ）を表示できるようにするために、このような決定を拒否したいと思います。 いくつかのマクロを使用すると、今後の作業に必要なすべての情報を追加できます。 継承の可能性もありますが、それについては後で詳しく説明します...





少し複雑な例：構造とその基本構造のすべてのフィールドのコンソールに一般化された出力コードを書き込もうとします。





結果

 Struct name: Base1 field1 = 1 field2 = true Struct name: Base2 field3 = Text Struct name: Data field4 = 100 field5 = String field6 = key1 Struct name: Nested field = 100 key2 Struct name: Nested field = 200
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例は、完全なシリアライザーのプロトタイプです。 追加されたメタ情報に基づいて、構造をストリーム（この例では標準出力ストリーム）にシリアル化します。 型がコンテナかどうかを判断するには、Serialization名前空間の関数が使用されます。 この名前空間には、jsonおよびboost.archives（xml、text、binary）の既製のシリアライザーが含まれています。 これらは、例で示したものに近い原則に基づいて構築されています。 シリアライザーでフレームワークを拡張する必要がない場合、そのようなコードを記述する必要はありません。



Printerクラスを使用する代わりに、jsonなどで既製のシリアライザーを使用できます。これにより、コードの量が大幅に削減されます。

 #include <mif/reflection/reflect_type.h> #include <mif/serialization/json.h> // Data and meta int main() { Data data; // Fill data auto const buffer = Mif::Serialization::Json::Serialize(data); //   json std::cout << buffer.data() << std::endl; return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更については、boost.archivesのシリアル化をxml形式で使用してみてください。







この例からわかるように、特定のシリアライザーを呼び出す以外は何も変わりません。 同じメタ情報が使用されます。 また、プロセス間通信を実装するときに他の場所で使用されます。



いくつかの形式のシリアライゼーションとデシリアライザがフレームワークに実装されています。 また、必要に応じて、Printerクラスの例を使用するか、提案されたAPIを使用してj ++形式の（de）シリアライザーを使用してC ++データ構造をバイパスすることにより、新しい形式のサポートを追加できます。 型にはいくつかの制限があります（それらがない場合）が、それについては後で詳しく説明します。



さらに、より興味深いものに進むことを提案します-プロセス間で転送されるインターフェースに基づいてプロセス間通信を実装します（純粋な仮想メソッドを使用したC ++データ構造）。

プロセス間通信

MIFプロジェクトが始まったのは、プロセス間通信の実装です。 それは優先事項でした。 このメカニズムの最初の実装の1つで、サービスの1つが開発されました。このサービスの執筆時点では、これらの行はクラッシュやリブートなしで6か月以上安定して機能していました。



インターフェイスを使用して、複数のマシン上にあるサービスの通信を行う必要がありました。 まるですべてが1つのプロセスにあるかのように、サービスを操作したかったのです。



例では、目的の結果にどれだけ近づいたかを示しています。



目的：架空の会社の従業員に関する情報を交換するためのサーバーとクライアントを開発する。



このような問題の解決策は、いくつかの同様のステップに削減されます

• コンポーネントインターフェイスを定義する
• メソッドパラメータの戻り値として、カスタムデータ構造を定義する（必要な場合）
• メタ情報を追加する
• サーバーアプリケーションを実装する
• クライアントアプリケーションを実装する

Complex_typeの例

一般部

データ構造

 // data.h namespace Service { namespace Data { using ID = std::string; struct Human { std::string name; std::string lastName; std::uint32_t age = 0; }; enum class Position { Unknown, Developer, Manager }; struct Employee : public Human { Position position = Position::Unknown; }; using Employees = std::map<ID, Employee>; } // namespace Data } // namespace Service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メタ情報

 // meta/data.h namespace Service { namespace Data { namespace Meta { using namespace ::Service::Data; MIF_REFLECT_BEGIN(Human) MIF_REFLECT_FIELD(name) MIF_REFLECT_FIELD(lastName) MIF_REFLECT_FIELD(age) MIF_REFLECT_END() MIF_REFLECT_BEGIN(Position) MIF_REFLECT_FIELD(Unknown) MIF_REFLECT_FIELD(Developer) MIF_REFLECT_FIELD(Manager) MIF_REFLECT_END() MIF_REFLECT_BEGIN(Employee, Human) MIF_REFLECT_FIELD(position) MIF_REFLECT_END() } // namespace Meta } // namespace Data } // namespace Service MIF_REGISTER_REFLECTED_TYPE(::Service::Data::Meta::Human) MIF_REGISTER_REFLECTED_TYPE(::Service::Data::Meta::Position) MIF_REGISTER_REFLECTED_TYPE(::Service::Data::Meta::Employee)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェース

 // imy_company.h namespace Service { struct IMyCompany : public Mif::Service::Inherit<Mif::Service::IService> { virtual Data::ID AddEmployee(Data::Employee const &employee) = 0; virtual void RemoveAccount(Data::ID const &id) = 0; virtual Data::Employees GetEmployees() const = 0; }; } // namespace Service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メタ情報

 // ps/imy_company.h namespace Service { namespace Meta { using namespace ::Service; MIF_REMOTE_PS_BEGIN(IMyCompany) MIF_REMOTE_METHOD(AddEmployee) MIF_REMOTE_METHOD(RemoveAccount) MIF_REMOTE_METHOD(GetEmployees) MIF_REMOTE_PS_END() } // namespace Meta } // namespace Service MIF_REMOTE_REGISTER_PS(Service::Meta::IMyCompany)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データ構造の定義とメタ情報の追加は、すべてが名前空間で区切られていることを除いて、リフレクションを使用した例と同じです。



インターフェイス定義は、純粋な仮想メソッドのみを含むデータ構造のC ++定義です。



インターフェースについては、別の要望がありました。あるインターフェースから、実装に含まれる他のインターフェースにリクエストする機能であり、単一の階層に接続されていない可能性があります。 したがって、定義されたインターフェイスは、常にMif :: Service :: IServiceまたはMif :: Service :: IServiceを継承する他のインターフェイスを継承する必要があります。 多重継承があります。 継承は、中間エンティティMif :: Service :: Inheritを介して行われます。 これは、可変数のパラメーターを持つテンプレートです。 そのパラメーターは、継承されたインターフェースまたは実装です（ 継承 ）。 これは、dynamic_castと同じですが、プロセスの外部で動作するインターフェイスを要求するメカニズムを実装するために必要です。



インターフェイスにメタ情報を追加することは、データ構造にメタ情報を追加することと特に違いはありません。 これは、異なるが類似したマクロのセットです。 ただし、おそらく後で、データ構造とインターフェイスを定義するためのすべてが単一のマクロセットに縮小されます。 違いますが。 これは、プロジェクトの開発中に発生しました。



インターフェイスにメタ情報を追加する場合、その基本的なインターフェイスは必要ありません。 階層全体はコンパイル時に検出されます。 ここで、小さな補助エンティティMif :: Service :: Inheritは、相続人および関連するメタ情報の検索で主な役割を果たします。



メタ情報をインターフェースに追加する場合、パラメーター、戻り値、およびcv修飾子を指定せずに、インターフェースとそのメソッドのみが指定されます。 ミニマリズムの精神で、インターフェースにメタ情報を追加したいという要望がありました。 過負荷の欠如がミニマリズムの代価になりました。 これは、すべてのパラメーターを一覧表示せず、各メソッドの値の型を返さず、インターフェイスを少し変更するだけで編集できないため、低価格だと考えています。



共通のエンティティを定義したら、サーバーおよびクライアントアプリケーションを実装します。



各インターフェイスには多くの実装があります。 彼らは何らかの形で区別される必要があります。 オブジェクトを作成するとき、目的の実装を明示的に指定する必要があります。 このためには、インターフェイスの実装の識別子と実装との接続が必要です。



「コード内の魔法の値」を便利に拒否するために、実装識別子は1つ以上のヘッダーファイルに配置する方が適切です。 MIFプロジェクトでは、番号が識別子として使用されます。 何らかの方法でカウンタを数えたり、すべてを単一の列挙に入れたりせずに一意にしたり、識別子を異なるファイルや名前空間に論理的に分離できるようにするために、一意にするには、文字列からcrc32を識別子として使用することをお勧めします開発者の方が少ないはずです。



IMyCompanyを実装するには識別子が必要です

 // id/service.h namespace Service { namespace Id { enum { MyCompany = Mif::Common::Crc32("MyCompany") }; } // namespace Id } // namespace Service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーアプリケーション

IMyCompanyの実装

 // service.cpp // MIF #include <mif/common/log.h> #include <mif/reflection/reflection.h> #include <mif/service/creator.h> // COMMON #include "common/id/service.h" #include "common/interface/imy_company.h" #include "common/meta/data.h" namespace Service { namespace Detail { namespace { class MyCompany : public Mif::Service::Inherit<IMyCompany> { public: // … private: // … // IMyCompany virtual Data::ID AddEmployee(Data::Employee const &employee) override final { // ... } virtual void RemoveAccount(Data::ID const &id) override final { // ... } } virtual Data::Employees GetEmployees() const override final { // ... } }; } // namespace } // namespace Detail } // namespace Service MIF_SERVICE_CREATOR ( ::Service::Id::MyCompany, ::Service::Detail::MyCompany )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注目したい点がいくつかあります。

• 実装の継承も、Mif :: Service :: Inheritを介して行われます。 これは必須ではありませんが、適切な形式と見なすことができ、以前に実装されたいくつかのインターフェイスを継承していくつかのインターフェイスを実装する場合に役立ちます。
• 実装全体は、hファイルとcppファイルに分割することなく、1つのcppファイルで実行できます。 これにより、必要なすべてのインクルード実装ファイルが実装ファイルに含まれているため、カプセル化を強化したり、大規模プロジェクトでコンパイル時間を短縮したりできます。 変更されると、再コンパイルされる依存cppファイルの数が少なくなります。
• 各実装にはエントリポイントがあります-MIF_SERVICE_CREATORは実装ファクトリです。 パラメーターは、実装クラス、識別子、および必要に応じて実装コンストラクターに渡される可変数のパラメーターです。

サーバーアプリケーションを完成させるために、メインポイントであるエントリポイントを追加します。

 // MIF #include <mif/application/tcp_service.h> // COMMON #include "common/id/service.h" #include "common/ps/imy_company.h" class Application : public Mif::Application::TcpService { public: using TcpService::TcpService; private: // Mif.Application.Application virtual void Init(Mif::Service::FactoryPtr factory) override final { factory->AddClass<::Service::Id::MyCompany>(); } }; int main(int argc, char const **argv) { return Mif::Application::Run<Application>(argc, argv); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エントリポイントを作成する場合、アプリケーションクラスを実装する必要があります。これは、基本アプリケーションクラスまたは事前定義されたアプリケーションテンプレートのいずれかの継承者です。 再定義されたInitメソッドでは、サービスがエクスポートするインターフェースのすべての既存の実装をファクトリーに追加する必要があります（factory-> AddClass）。 実装コンストラクターのパラメーターをAddClassメソッドに渡すことができます。



このサービスは、gzip圧縮を使用したバイナリ形式のboost.archiveに基づく定義済みのトランスポートtcp、シリアル化を使用して、インターフェイス、メソッド、パラメーター、返された結果、例外、およびオブジェクトインスタンスに関する情報を交換します。



別のタイプのトランスポート（たとえば、MIFでも使用できる、または独自のトランスポートを使用する）を使用して、独自の一意のデータ処理チェーンをシリアル化および収集できます（パケット境界、圧縮、暗号化、マルチスレッド処理などを決定します）。 これを行うには、アプリケーションテンプレートではなく、アプリケーションの基本クラス（Mif :: Application :: Application）を使用して、データ処理チェーンまたはトランスポートの必要な部分を個別に決定する必要があります。



MIFプロジェクトの最初のバージョンには、事前定義されたアプリケーションテンプレートはありませんでした。 例はそれほど短くは見えませんでしたが、データ処理フローを完全に制御するために必要な全パスを示しました。 チェーン全体は、プロジェクトの最初のバージョン（ MIF 1.0 ）の例に示されています。

クライアントアプリケーション

クライアント側では、共通部分で定義されているすべてのものが使用されます。

クライアントは同じアプリケーションフレームワークです（この例では定義済みのアプリケーションテンプレートを使用します）。クラス/サービスのリモートファクトリが要求され、それを通じて目的のオブジェクトが作成され、そのメソッドが呼び出されます。

 // MIF #include <mif/application/tcp_service_client.h> #include <mif/common/log.h> // COMMON #include "common/id/service.h" #include "common/ps/imy_company.h" class Application : public Mif::Application::TcpServiceClient { public: using TcpServiceClient::TcpServiceClient; private: void ShowEmployees(Service::Data::Employees const &employees) const { // ... } // Mif.Application.TcpServiceClient virtual void Init(Mif::Service::IFactoryPtr factory) override final { auto service = factory->Create<Service::IMyCompany>(Service::Id::MyCompany); { Service::Data::Employee e; e.name = "Ivan"; e.lastName = "Ivanov"; e.age = 25; e.position = Service::Data::Position::Manager; auto const eId = service->AddEmployee(e); MIF_LOG(Info) << "Employee Id: " << eId; } { Service::Data::Employee e; e.name = "Petr"; e.lastName = "Petrov"; e.age = 30; e.position = Service::Data::Position::Developer; auto const eId = service->AddEmployee(e); MIF_LOG(Info) << "Employee Id: " << eId; } auto const &employees = service->GetEmployees(); ShowEmployees(employees); if (!employees.empty()) { auto id = std::begin(employees)->first; service->RemoveAccount(id); MIF_LOG(Info) << "Removed account " << id; auto const &employees = service->GetEmployees(); ShowEmployees(employees); try { MIF_LOG(Info) << "Removed again account " << id; service->RemoveAccount(id); } catch (std::exception const &e) { MIF_LOG(Warning) << "Error: " << e.what(); } } } }; int main(int argc, char const **argv) { return Mif::Application::Run<Application>(argc, argv); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果

はい、例外もプロセスの境界を超えています...

 [WARNING]: Error: [Mif::Remote::Proxy::RemoteCall] Failed to call remote method "IMyCompany::RemoveAccount" for instance with id "411bdde0-f186-402e-a170-4f899311a33d". Error: RemoveAccount. Employee with id 0 not found.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージから、識別子0の従業員に関する情報を削除するメソッドが再度呼び出されたことがわかります。サーバーは、「id 0の従業員が見つかりません」という例外を報告して、サーバー側にそのようなレコードはありません/



この例では、クライアントとサーバーのプロセス間相互作用を示し、トランスポートに関連するすべての詳細と送信データの形式を可能な限り隠しています。



この例は、MIFプロジェクトの基礎となるベースの表示を完了します。 追加機能が含まれます

• 単一の階層に統合されていない実装からインターフェイスを要求する機能 （Mif :: Service :: IServiceからの継承はカウントしません）。
• サービス間のインターフェイスにポインターとスマートポインターを渡します。 コールバックを使用したサービスのさまざまな実装に役立つもの。 たとえば、パブリッシュ/サブスクライブに基づくサービス。 例は、 訪問者パターンの実装です。その一部は異なるプロセスにあり、tcpを介して相互作用します。

HTTP

プロセス間通信の例では、既存のTCPトランスポートをHTTPトランスポートに簡単に置き換えることができます。 curlやブラウザなど、使い慣れた手段を使用してサービスにアクセスできます。



HTTPサポートにより、JSON REST APIを使用して同時にWebサーバーになることができるサービスを構築でき、同時にC ++インターフェイスを介した以前に実証された相互作用をサポートできます。



多くの場合、快適性には制限が伴います。 HTTPトランスポートを使用する場合のこの制限は、インターフェイスに渡されたメソッドをコールバックできないことです。 HTTPトランスポートに基づくソリューションは、パブリッシュ/サブスクライブアプリケーションの構築に焦点を合わせていません。これは、HTTPを介した作業には要求と応答のアプローチが関係するためです。クライアントはサーバーに要求を送信し、応答を待ちます。



MIFで提案されているTCPトランスポートには、このような制限はありません。クライアントとサーバーの両方がメソッドを呼び出すことができます。この場合、クライアントとサーバーの区別があいまいになります。オブジェクトが相互に通信できるチャネルが表示され、両側からメソッドを呼び出します。これにより、パブリッシュ/サブスクライブアーキテクチャを構築するための双方向の対話が可能になります。これは、インタープロセスの例で実証されました訪問者。



MIF HTTPは、特に注意を払っています。最初は、Web用のバックエンドサービスの開発に焦点が当てられていました。小さなHTTP Webサービスを作成し、HTTPを介してサプライヤからデータを受信する必要があり、その後のみプロセス間でインターフェイスをマーシャリングするときにトランスポートとしてHTTPを使用する機能が追加されました。したがって、単純なWebサービス、クライアントを作成する最初の例を示し、最後に、プロセス間でインターフェースを転送することをサポートするWebサーバーの例を示します。

単純なHTTP Webサーバー

 // MIF #include <mif/application/http_server.h> #include <mif/common/log.h> #include <mif/net/http/constants.h> class Application : public Mif::Application::HttpServer { public: using HttpServer::HttpServer; private: // Mif.Application.HttpServer virtual void Init(Mif::Net::Http::ServerHandlers &handlers) override final { handlers["/"] = [] (Mif::Net::Http::IInputPack const &request, Mif::Net::Http::IOutputPack &response) { auto data = request.GetData(); MIF_LOG(Info) << "Process request \"" << request.GetPath() << request.GetQuery() << "\"\t Data: " << (data.empty() ? std::string{"null"} : std::string{std::begin(data), std::end(data)}); response.SetCode(Mif::Net::Http::Code::Ok); response.SetHeader( Mif::Net::Http::Constants::Header::Connection::GetString(), Mif::Net::Http::Constants::Value::Connection::Close::GetString()); response.SetData(std::move(data)); }; } }; int main(int argc, char const **argv) { return Mif::Application::Run<Application>(argc, argv); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作業を確認するには、次のコマンドを使用できます

 curl -iv -X POST "http://localhost:55555/" -d 'Test data'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

準備が整っているのは、約30行のコードと、MIFアプリケーションフレームワークに基づくマルチスレッドHTTPエコーサーバーのみです。バックエンドとしてlibeventが使用されます。abユーティリティを使用した簡単なテストでは、1秒あたり最大160Kクエリの平均結果が生成されます。もちろん、すべてはテストが実行されるハードウェア、オペレーティングシステム、ネットワークなどに依存します。しかし、比較のために、PythonとGoでも同様のことが行われました。Pythonサーバーの動作は2倍遅くなり、Goの場合、結果は例からのサーバー結果の10％だけ平均で良くなりました。あなたがC ++開発者であり、PythonとGoがあなたにとって異質であるか、プロジェクトのフレームワーク内の内部命令によって公式に修正されるかもしれない他の理由がある場合、C ++のみが好きで、提案されたソリューションを使用して速度と開発時間の面で良い結果を得ることができます...

HTTPクライアント

クライアント部分は、クラスMif :: Net :: Http :: Connectionで表されます。これは、MIFのC ++インターフェイスをマーシャリングするHTTPトランスポートの基盤です。しかし、これまでのところマーシャリングについてではありません...このクラスは、MIFマイクロサービスのプロセス間相互作用のインフラストラクチャ全体とは別に使用できます。たとえば、メディアコンテンツ、天気予報、株価などのサプライヤのデータをダウンロードできます。



上記のエコーサービスを実行すると、このクライアントでアクセスできます。

 // STD #include <cstdlib> #include <future> #include <iostream> #include <string> // MIF #include <mif/net/http/connection.h> #include <mif/net/http/constants.h> int main() { try { std::string const host = "localhost"; std::string const port = "55555"; std::string const resource = "/"; std::promise<std::string> promise; auto future = promise.get_future(); Mif::Net::Http::Connection connection{host, port, [&promise] (Mif::Net::Http::IInputPack const &pack) { if (pack.GetCode() == Mif::Net::Http::Code::Ok) { auto const data = pack.GetData(); promise.set_value({std::begin(data), std::end(data)}); } else { promise.set_exception(std::make_exception_ptr( std::runtime_error{ "Failed to get response from server. Error: " + pack.GetReason() })); } } }; auto request = connection.CreateRequest(); request->SetHeader(Mif::Net::Http::Constants::Header::Connection::GetString(), Mif::Net::Http::Constants::Value::Connection::Close::GetString()); std::string data = "Test data!"; request->SetData({std::begin(data), std::end(data)}); connection.MakeRequest(Mif::Net::Http::Method::Type::Post, resource, std::move(request)); std::cout << "Response from server: " << future.get() << std::endl; } catch (std::exception const &e) { std::cerr << "Error: " << e.what() << std::endl; return EXIT_FAILURE; } return EXIT_SUCCESS; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、エラー処理に焦点を当てていない基本的な例です。単純なクライアントを開発する能力を示しています。もちろん、たとえばcurlライブラリに基づいて何か他のものを使用する方が良いですが、時には簡単な場合には上記のコードで十分かもしれません。

デュアルインターフェイスHTTP Webサーバー

この例では、MIFプロジェクトでのHTTPサポートを要約しています。この例は、ブラウザーまたはcurlを使用してアクセスできるHTTP Webサーバーと、C ++インターフェイスを介して動作し、トランスポートとデータ形式について何も知りたくないクライアントを示しています。以前と同じMif :: Application :: HttpServerアプリケーションフレームワークを使用します。デモンストレーションには、次のコードスニペットが必要です。サンプル全体は、httpの例のgithubで入手できます。

一般部

インターフェース

 namespace Service { struct IAdmin : public Mif::Service::Inherit<Mif::Service::IService> { virtual void SetTitle(std::string const &title) = 0; virtual void SetBody(std::string const &body) = 0; virtual std::string GetPage() const = 0; }; } // namespace Service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェイスにメタ情報を追加すると、サービス実装の識別子はすべて、前述のプロセス間通信の例に似ています。

サーバー側

アプリケーションワイヤーフレーム

 class Application : public Mif::Application::HttpServer { //... private: // Mif.Application.HttpService virtual void Init(Mif::Net::Http::ServerHandlers &handlers) override final { std::string const adminLocation = "/admin"; std::string const viewLocation = "/view"; auto service = Mif::Service::Create<Service::Id::Service>(viewLocation); auto webService = Mif::Service::Cast<Mif::Net::Http::IWebService>(service); auto factory = Mif::Service::Make<Mif::Service::Factory, Mif::Service::Factory>(); factory->AddInstance(Service::Id::Service, service); std::chrono::microseconds const timeout{10000000}; auto clientFactory = Service::Ipc::MakeClientFactory(timeout, factory); handlers.emplace(adminLocation, Mif::Net::Http::MakeServlet(clientFactory)); handlers.emplace(viewLocation, Mif::Net::Http::MakeWebService(webService)); } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リソースハンドラは直接設定されなくなりましたが、追加のラッパーを使用して、次のことができます。

• リソースに異なるハンドラーを追加します
• リクエストボディからクエリパラメーターとデータを自動的に解析します
• 選択した形式への応答を自動的にシリアル化します
• 2つのアプローチを組み合わせます。おそらく、REST APIを介してHTTPで作業し、C ++インターフェイスをマーシャリングするサポートのあるクライアントで作業します

これらの機能はすべて、Mif :: Net :: Http :: WebServiceという基本クラスに実装されています。カスタムクラスはそれを継承する必要があります。なぜならこれは純粋な仮想メソッドを含むサービスであり、その実装はフレームワークのサービスコードに隠されているため、派生クラスのインスタンスは、ファクトリメソッドによってすべてのサービスと同様に作成する必要があります。サービスをHTTP Webサーバーハンドラーとして使用するには、Mif :: Net :: Http :: MakeServlet関数を使用してラッパーを作成する必要があります。



MIFサービスとWebサービスは異なるサービスです。MIFサービスは、HTTP要求または他のネットワーク要求の処理のみを処理する必要のないインターフェイスの実装クラスとしてのみ理解する必要があります。Webサービスはすでにより馴染みのある概念です。しかし、必要に応じて、MIFでは、これらすべてが簡単に1つの全体に結合され、所定の例で確認されています。



サービスハンドラー

 namespace Service { namespace Detail { namespace { class WebService : public Mif::Service::Inherit < IAdmin, Mif::Net::Http::WebService > { public: WebService(std::string const &pathPrefix) { AddHandler(pathPrefix + "/stat", this, &WebService::Stat); AddHandler(pathPrefix + "/main-page", this, &WebService::MainPage); } private: // … // IAdmin virtual void SetTitle(std::string const &title) override final { // ... } // … // Web hadlers Result<Mif::Net::Http::JsonSerializer> Stat() { // ... std::map<std::string, std::int64_t> resp; // Fill resp return resp; } Result<Mif::Net::Http::PlainTextSerializer> MainPage(Prm<std::string, Name("format")> const &format) { // ... } }; } // namespace } // namespace Detail } // namespace Service MIF_SERVICE_CREATOR ( ::Service::Id::Service, ::Service::Detail::WebService, std::string )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかの点に注意を喚起したいと思います。

• Mif::Service::Inherit . Mif::Service::Inherit . IAdmin , IWebService Mif::Net::Http::WebService, HTTP .
• . , - Mif::Net::Http::WebService , AddHandler. , /view/stat
• , . -. . .
• - . Prm. Prm , . Prm. , , ( stl , , list, vector, set). , timestamp , boost::posix_time. Content. . , Headers / Params. . http_crud
• 実装クラスを作成するためのファクトリメソッドを定義する場合、追加のパラメーターがMIF_SERVICE_CREATORマクロに渡されます。これは、実装コンストラクターに渡す必要があります。マクロMIF_SERVICE_CREATORの使用については上記で説明しました。

クライアント



クライアントは、前述の例と大差ありません。例外は、事前定義されたクエリ処理チェーンの欠如です。開発者が独自に作成します。MIFでHTTPを介して作業するための定義済みの要求処理チェーンはありません。実装機能...理由については、おそらく何かが後続の投稿で書かれます。完全なクライアントコードはhttpの例です。



結果



組み立てられたサーバーをテストするには、例えばcurlコマンドを使用するかブラウザーからサーバーを起動してアクセスする必要があります

 curl "http://localhost:55555/view/main-page?format=text" curl "http://localhost:55555/view/main-page?format=html" curl "http://localhost:55555/view/main-page?format=json"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、管理インターフェイスを介してアクセスしてデータを変更するクライアントアプリケーションを起動し、curlコマンドを再度実行してください。クライアントによって行われた変更が正常に適用され、HTTPを介して返される結果が変更されたことがわかります。

データベースを操作する

DBなしでバックアップされていますか？それらなしではどうですか？必ずしもではありませんが、めったにありません...



現在、MIFでのデータベースの操作は、メタ情報に依存せずに実装されています。これまでは、データベースを操作するほぼ古典的な方法でした。この部分は、データベースに何かを保存する必要があるサービスを開発するために必要でした。しかし、この部分の開発は、ORMの基礎となり、型に追加されたすべてのメタ情報がすでに完全に使用されることを目的として行われました。 ORMとはまだ連携していません。実装する試みがいくつかありました。非常に面倒であるか、柔軟性がないことが判明しました。簡潔さと柔軟性の間の妥協点はすぐに到達し、ORMの次のバージョンに現れると思います。コンパイラにいくつかのチェックを転送できるようにしたいのですが、生のSQLクエリ文字列の単純なエラーやタイプミスに関連するプログラムの実行時にエラーをキャッチしたくありません。



ORMはありませんが、少し古典的です...



データベースの操作にはいくつかのステップが含まれています。

• データベース接続オブジェクトの作成
• 受信した接続を介したリクエストの履行
• 結果処理
• 取引

JDBC（Java）またはC ++に似たものなどのラッパーで作業した人は、ここでは新しいことを発見しません。db_clientの



例は、PostgreSQLとSQLiteの2つのDBMSでの作業を示しています。

HTTP CRUDサーバー

http_crudの例は、HTTPとデータベースを使用したデモの論理的な結論です。これは、相互に直接対話しないWeb用の単純なマイクロサービスの古典です。



Webサーバークラスには、すべての基本的なCRUD操作のハンドラーが含まれています。データベースの操作はハンドラー内にあります。このようなコードは、正常に機能するさまざまなサービスでよく見られます。しかし、最初のスコープにもかかわらず、DBMSへの依存という欠点があります。また、リレーショナルデータベースを放棄してNoSQLデータベースにアクセスする場合は、すべてのハンドラーのコードがほぼ完全に書き換えられます。多くの実際のプロジェクトでは、データベースでの同様の作業を避けようとしています。高レベルのロジック機能を個別のファサードに移動します。ファサードは通常、特定の実装を持つC ++インターフェイスです。そして、データベースの置き換えは、インターフェースの次の実装と、新しい識別子を持つ実装ファクトリーからの要求に帰着します。証拠のキャプテンを演じて、このアプローチは何度も証明されていると言えます。

おわりに

上記で説明したすべて：リフレクション、シリアル化、プロセス間通信、インターフェイスマーシャリング、データベースの操作、HTTPサポート-すべてが、マイクロサービスで小規模システムを構築する最後の例に反映されました。この例は、相互作用する2つのマイクロサービスで構成される小さなサービスを示しています。 1つのサービスはデータベースへのファサードであり、2番目のサービスは外部クライアントにJson APIを提供します。この例は、対象となる例http_crudの修正バージョンであり、投稿のフレームワークで説明されたすべての論理的な結論（結合）です。



MIFの一部、たとえばdb_clientは考慮されていません、ただしデータベースの操作は他の例に示されています。例では、サービスの操作（インターフェース実装）も部分的に影響を受けます。シリアル化、データベース処理、HTTPサポートなど、MIFの一部はすでに数回テストされています。開発の一部の部分に多くの時間が与えられているという事実にもかかわらず、プロセス間通信では検証とデバッグの時間が短縮されています。たとえば、これらには、インターフェイスをパラメーターとして別のプロセスに渡し、メソッドをコールバックするためのサポートが含まれます。本質的に「自我機能」とは何ですか。私は訪問者の例で示されている同様のメカニズムを実装したかったのですが、将来、この部分を完全で実績のあるデバッグされたソリューションにしたいという要望があります。



将来的には、おそらく、提示された資料に関心がある場合、たとえば、MIFの「内部」、特定の決定が行われた理由、解決しなければならないタスク、th約が適合しなかったものなど、これに含まれなかったもので投稿が続行されますまたは他の同様の決定、私が見ている欠点、私が変更および改善したいことなど。このプロジェクトは「ホームプロジェクト」として登場しましたが、驚いたことに、私がもう一年近く注意を払ってきたプロジェクトです。他に何か書くことに問題はないはずです。



要約すると、C ++プロジェクトのMIFへのリンクを複製します。



ご清聴ありがとうございました。