BFFは何ですか
BFFは、バックエンドのためにフロントエンド（バックエンドの前でサービス）の略で、2015年に、サム・ニューマンのブログ記事起源「： -単一目的のエッジサービスのUI用と外部の関係者のバックエンドフロントエンドのパターンを」。
フロントエンドまで提供するために、別の前端と後端とマイクロサービスの人気、後端の境界がサービスAPIレイヤ、システム化にマイクロサービス複数の重合プロセスの一連の後、通常、等適合を切断します、 APIのHTTPプロトコル。
そして、携帯端末の画面サイズが比較的小さいため、携帯側の上昇に伴って、多くの倍の並行開発シナリオH5、iOSとAndroidのがあったので、従来のWebの情報側表示と大きな差があり、接続端へのモバイルアクセス数とデータの量は、より高い要件があります。このとき、共通API層の開発は、このような異なるエンドに異なるAPIを提供する必要性などの困難の数が発生します。API相関の異なる端部の設計とプレゼンテーションロジックは、チームやバックエンドのAPIチームに関与することが適切ではない、強いです。これらのAPIの保守要員は、協調と選択、非常に疲れた心を行うために前端と後端との間に挟まれますので。
サム・ニューマンはBFFと呼ばれる異なる端部のための独立したバックエンドのAPIを行うためのREAとSoundCloudが実際、2つの会社を持っています。APIの異なるエンドのさまざまなニーズに対処するために。
BFFのメリット
レガシービジネスサポート
インタフェース仕様古いシステムは、比較的古い可能性があり、そのような安らかではありません。インターフェースコンバータによるBFF層は、より良いエンド技術開発のニーズに合わせて何かをします。
最後のニーズの変化、台湾における協調と安定性
主に二つの側面に反映急速な変化を終了します。
- 技術革新：速いの端の技術の更新、JSフレームワークレベルが貧弱ではありません。モバイルエンドは、H5、Javaの/ OC、Kotlin /スウィフトは、ネイティブ、フラッターに反応、というように、多くの選択肢があります。
- ビジネスの変化：フロントエンド製品の変化は、バックエンドよりも頻繁にビジネスの変化に傾向があります。
分化能は、サービング端側を満たし
さまざまな国、言語、群衆に配信一部の製品は、あなたがここにいくつかの言語関連の翻訳を行うことができ、そのようなバックエンドとユーザー・エラーなど、いくつかの変換BFF層を、行うことができます。
横方向の重合および重合に基づく最適化
一部の製品は、重合APIとしてBFFエッジサービスレイヤ機能として、サービスステーションにおける複数のモジュールを必要とします。
端のビジネス効果の評価
最後にAPIを変更することが避けられない新しい経験をお試しください。BFFがなければ、A / Bに、フロントエンドとAPIを変更する必要性をテストします。モバイルやWebチームのニーズが行う方法をテストするA / Bを実行する場合は？チームは別のチームを待つ必要があります。
BFF異なるチームが独立してテストすることができるようにということ。最初にAPIの変更に実験BFFで実施し、試験A / Bテストに移植し、その後コアAPIに移植し、より便利で、見つけることができます。
問題のいくつかのBFF
高いリソースコスト
、あなたは少しタイトを実行しているサーバーを提供する必要がいかに簡単BFFに関係なく、その後も展開環境のいくつかのセットを提供する必要があります。このような内部のようないくつかの大企業
の要件は、単純なアプリケーションは、4台のサーバーを必要とどのように関係なく、および承認プロセスサーバーが遅く長いかもしれません。
並行性は保証することは困難です
BFF層は、一般的に学生のフロントエンドの開発で構成され、しかしBFF、高可用性を確保するため、フロントエンドの学生はしばしば挑戦です。オフフックBFF第一の層を発生することがあり、トラフィックの急激な増加は、全体のシステム・インフラストラクチャの可用性が低くなる原因となります。
運用・保守の困難
運用・保守を開発者、そしてクラスメートの前には、BFFの運用・保守にも大きな問題である、オンラインアプリケーションの経験の運用・保守を欠いている可能性があります。
サーバレスのバックエンド
サーバレス以来、特に関数計算、アプリケーションの展開の後、トラフィックがない場合は、コンピューティングリソースを消費しませんが、コストを生成しません。トラフィックが増加し、プラットフォームがされるときに数百ミリ秒ものアプリケーションに縮小する（関数インスタンス）の背後のリソースを計算した後拡張、トラフィックドロップを高速。しかし、また、それはボックスとモニターのアラームログ検索機能をユーザに提供します。
この関数は、伝統的な欠点が対応する正確BFFさんの利点の弾性伸縮、有料無料の量および運用・保守を計算します。BFFは、上記のBFFさんを解決することができます完璧な機能コンピューティングプラットフォームに展開されますので。
導入コストだけでなく、小さなBFFの提供解体の可能性のためにする場合。この終わりに対応するサービスモジュールのBFFモジュールに合わせて整理することができます。たとえば、あなた自身のBFFの責任のモジュール開発、フロントエンド機器センターを対応する、独自のBFFを担当するフロントエンドの開発プラットフォーム事業者は、本当に、お互いにあまり競合かもしれ責任者を楽しむ人。
プログラムの機能に基づいて計算
端側、ゲートウェイ層、層BFFやサービスステーション：プラットフォーム・アーキテクチャの実施形態を計算BFF関数は、4つの層を有しています。
端側が使い慣れた技術開発プログラムを維持することができます。たとえば、Webクライアントが選択するか、Vue.jsて、モバイル端末は、Java / KotlinまたはObjective Cの/スウィフトを選択することが反応します。また、この全体の先住民やフラッターマルチポート・ソリューションに反応選択することができます。
API GatewayおよびHTTPトリガー：レイヤーゲートウェイは、2つの選択肢があります。ゲートウェイの機能豊富なAPI、電流制限をサポートしていますが、追加料金が発生します。HTTPトリガーのサポート、単純な、それは軽量なアプリケーションのための無料の制限をサポートしていませんが、マップをルーティングドメインを結合。
大端部のインターフェースモジュールとの間の差は、異なる機能に分けることができればBFF層サービスモジュールは、推奨解像度に応じて、異なる機能モジュールは、異なる機能を構築します。楽しいツールは、これらの機能は、いくつかのプロジェクトに編成されています。解体プロジェクトには、さまざまなプロジェクトを維持するために、とクロスの間の紛争を減らすために別のチーム、保守チームと分割合わせを考慮することができます。
SFFの開発プロセス
SFFを取得する方法を確認するために、開発プロセスの三つの側面を監視プロセスやサービスを公開、ローカルの開発をしてみましょう。
現地R＆D
ローカルプロジェクトは、3つの部分に分かれています
- APP / H5 - ネイティブエンド技術などVue.jsに反応
- SFF - FC機能、共通明示または卵
- 台湾のAPIインタフェースで - あなたは選択、または直接API模擬テスト環境ことができます。
ローカルデバッグ。開発者は、コマンドラインを使用することができます好むfuncraftサービスを開始するために地元の楽しい地元のスタートでツールを。環境設定デスクトップのGUIの開発者が提供する関数の計算に使用することができますVSCodeプラグイン。
モカや冗談：ユニットテストは、自分の好きなテスティングフレームワークを選択することができます
以下は、提案されたプロジェクト構造であります
sffdemo
├── README.md
├── function
│ ├── package.json
│ ├── template.yml
│ └── user.js
├── package.json
└── src
├── component
├── layout
├── model
├── page
└── service
srcディレクトリは、APPまたはH5のコードを配置しました。コードBFF機能ディレクトリの配置は、公開するための楽しいツールを使用して、ROS記述関数template.ymlテンプレートを使用することができます。
公開プロセス
毎日の推奨事項は、コマンドラインを使用して、楽しいツールをインストールして構成した後、template.yml BFFプロジェクトにROS記述ファイルを置き発行し、その後、急速な展開のための楽しいdeployコマンドを用いて開発しています。
初心者にもに選択することができ、コンソールコンピューティング機能、使用のZIPファイルアップロードパッケージのリリースを。
より複雑なシナリオについてCI / CDを設定することができます。例えば、コードリポジトリの選択Gitlab / Githubに、ビルドシステムはトラヴィスCI / Gitlab CI /ジェンキンスを選択し、自動的にビルドおよび放出を引き起こすコードリポジトリにコードを提出します。詳細を参照することができますサーバレスの戦闘を- Funcraft + OSS + ROSは、CI / CDました
サービス監視
観測面については、監視機能がボックス、ログやアラームの出て算出されています。
コスト優位性
典型的には、ユーザアプリケーション負荷、様々なタイプ、異なるリソースの仕様と弾性要件を含みます。機能を使用すると、さまざまなシナリオに大幅なコストメリットを得る助けにプリペイドクーポンや後払い測光モードを計算します。プリペイドは、最初の使用前に購入クーポンにユーザアプリケーション、リソースの事前指定された数のリソースニーズを決定するために参照します。プリペイド利点は、ポストペイドの70％よりも安い低価格であり、欠点は、動的な負荷変動のアプリケーションであり、ピークの購入リソースに合わせてリソース使用率を下げるためにつながります。オンデマンド、実際に使用したアプリケーションのリソースベースのポストペイド利用料を指します。数百ミリ秒まで正確なリソースの量により有償機能の実行要求を、計算時間の一例です。要求がない場合は、無償。それは100％の量によって、リソースの使用率ということになります。ポストペイドリソース使用率の利点は欠点は高い価格で、高いです。自動開閉式の機能を使用すると、シームレスにコスト競争力の異なるシナリオの下へのアクセス権を持っているために結合プリペイドとポストペイドのリソースを計算することができます。
具体的には、原価計算とコストの最適化スキームはを参照してもよい機能の最適化計算コストのベストプラクティス
概要
サーバレスの定義と床に誰もが異なる理解を有することができます。機能により、コンピューティング、本当に運用・保守の責任自由かつ低コストで誰が好きですかサーバレス利点、BFFをもたらします。
「アリババクラウドネイティブ懸念マイクロサービス、サーバレス、コンテナ、サービスメッシュ及び他の技術分野、クラウドネイティブ人気の技術動向を中心に、ネイティブの大規模な着陸の練習を曇らせるが、ほとんどは開発者のネイティブクラウド技術界を理解してください。」