マイクロサービス設計

前回の投稿で、マイクロサービスアーキテクチャを使用する利点について書いた。 次に、1つの便利なマイクロサービスを作成するプロセスを説明します。 これからは、意味ではなく、テクノロジーの追求の悲しい結果に関する専用の「マイクロサービス」記事があると言います。

挑戦する

Wheelyからのテストの割り当てでは、SMSメッセージのコードを介して認証を実装する必要がありました。 プロセスの本質は次のとおりです。

1. ユーザーがアクションを実行しています。
2. このアクションを確認するために、コードが生成されます。
3. コードはSMSメッセージで送信されます。
4. ユーザーがキーを指定します。
5. キーのコンプライアンスがチェックされます。

結果は、パラグラフ2、3（模倣のみ）、5で指定されたタスクを実行する独立したアプリケーションになることでした。 ピンは、生成の2分後には関係なくなります。 他のすべては私次第です。



私は同様のタスクをさまざまなレベルで詳細に実行しましたが、両方ともモノリシックサービスとして、プロジェクトに既に存在していたテクノロジーを使用しようとしました。 同じタスクで、検証中にツールの選択に特別な注意が払われることが指摘されました。

スケッチ

そこで、APIを介してメインクライアントアプリケーションと対話するマイクロサービスを作成しています。 このサービスは、ピンの作成とチェックの2つの主要コンポーネントに基づいています。



破線のフレームは、サービスとメインアプリケーションの相互作用を担当するコンポーネントを示しています。

ツール

データベース

ピンレコードの軽量で短い保存期間に注意する価値があります。 また、多数のコードの処理に注目する価値があります。



超高速REDISデータベースは、速度に加えて、レコードの保存時間を設定する素晴らしい有効期限オプションもあるため、これらの条件に最適です。 この小さなオプションのおかげで、「遅延」の機能を果たすコードを取り除き、データベースの無駄な情報で高価なメモリをロードしません。

Webアプリケーション

RESTが必要です。ビューと、多くのフレームワークが提供する（この場合）冗長な「ヘルパー」セットは必要ありません。 この場合のシナトラは非常に優れたオプションです。Web用の軽量DSLです。

プロジェクト

この章では、マイクロサービス開発機能について具体的に説明し、アプリケーションコンポーネントがどのように機能するかを非常に表面的に説明します。 読者がサービス自体の開発プロセスに興味を持っている場合は、このために別の出版物を準備しようとします。



まず、サービス内で実行するパラメーターを決定します。

1. api_token-アプリケーションキー。
2. operation_id-一意のオペレーションコード。
3. 電話 -電話番号。
4. code -n桁の確認コード。

次に、コンポーネントのアルゴリズムを書き留めます。

ピンを作成する

1. リクエストを送信します。
   
   
   
   

   POST 'https://test.dev/api/v1/pins', api_token: 'zx..d', operation_id: 'cs12', phone: '79..1'
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. api_tokenでアクセスを確認します。
3. 一意のコードを生成し、データベースにエントリを追加します（SETピン：$ operation_id $ code） 。
   
   
4. コード付きのメッセージを送信しています。
5. 答えを返します。

確認する

1. リクエストを送信します。
   
   
   
   

    POST 'https://test.dev/api/v1/pins/cs12/check', api_token: 'zx..d', code: '2213'
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. api_tokenでアクセスを確認します。
3. 受信したコードと、操作に関連して保存されているコードを確認します->成功した場合は、データベースからレコードを削除します。
4. 答えを返します。

回答を生成します

この場合、両方のコンポーネントが同じ答えを構造で返します。 成功した場合はSTATUS 200 、そうでない場合はSTATUS 403 。

まとめ

すばらしいことですが、このアプリケーションはデータを受け入れて処理し、応答を返します。 マイクロサービスとして行われたと想定できます:)



長所：

• メインアプリケーションはコンパクトなままです。
• 実装に最適（1時間未満）。
• システム全体の保守とテストのカバーが容易です。
• 仮説：安定性が向上しました。 マイクロサービスがオフラインになっても、スペアサービスに切り替わるだけなので、製品の動作には影響しません。

短所：

• APIを介した通信の遅延。
• 展開用の追加リソース。

この場合、結果はすべての期待を満たしていたので、肯定的なメモでこの出版物を終了したいと思います。 ただし、マイクロサービスアーキテクチャがすべてに適しているわけではないことを、読者にすぐに警告したいと思います。 しかし、これはまったく異なる話です。



UPD。1。 応答形式をジェイソンからステータスコードに変換しました。 推奨事項と説明については、 f0rkとsmileonlに感謝します。