著者：ビジー魚の技術 - 柔術
背景
忙しい魚は現在、最大の未使用アイテムの取引プラットフォームです。、魚の量の増加と拡大し、ユーザー忙しい共通バナーアプリケーション上や忙しい魚は通常のカードにフィードされると、彼らは数千万人の人々が毎日見になりそうです。
より良い、より洗練された材料を、より優れた大規模なユーザーコミュニティを提供し、よりパーソナライズされたコンテンツの推薦と置くためには、特に必要です。今日は、ユーザ、オペレータの迅速な試行錯誤の正確なタッチを設計する方法を解放デリバリーシステム開発の生産性をチャットすることができます。
アイデア解析
何がそれを置きますか？例えば、異なる代替シナリオで異なる時間に街の広場に看板、ポスターが実行されているの一種であるため、当然のことながら、インターネット技術が人間の次元をもたらした、異なるユーザがポスターは同じではありません表示されることがあります。何が私たちが見て、このようなシステムは、含まれるべきいただけます。
1、私たちは、リソースビットと呼ばれる「街の広場に一枚看板」を持っている、あなたは明らかに必要な材料を得るために、サーバ側のインタフェースを必要としています。
2は、おそらくバナー、現出映像フォーマットが異なっていてもよく、必要な異なるリソースビットおそらく、オペレータが手カスタマイズフィルデータであってもよい、フィード任意の合理的なデータ構造であってもよいです。
3は、リソースのビットは、異なる時間に、異なるプラットフォーム、人々のさまざまなグループのための材料を明らかにすることはありません同じであってもよいし、我々はコンテンツリソース材料の山で、適切な位置をフィルタリングするサービスを持っている必要があります。リソースビットのヒットで複数のクリップは、また、最終的な暴露のことを排除するいくつかのメカニズムを持っている必要がある場合。
詳細設計
我々は、送達システムは、フロントエンドとバックエンドデータソースとの間の物理的なリソースビット複数の役割ブリッジを果たして設計しました。以下に示すように一定の規則、基本的なデータ・ストリームに応じてビットデータを明らかにした特定のリソースに要求されるサービスにさまざまなソースからのデータをスクリーニングするための責任があります。
ニッチ
いわゆる資源位置は、我々のシステムでは、フロントページ上のエンティティピット位置を指します。これは、製品開発の学生によって作成された技術です。もちろん、リソース・ビットの消費のデータ構造は、バナーとして、開発段階で識別される必要がフィードまたは構造非常に柔軟な手でデータを埋めます。
我々のシステムでは、リソースのデータ構造は、私たちは、スキーマによって記述ビットを消費する必要があります。
这个 schema 是用 json 描述的。技术同学在前端页面上开发实体资源位后，需要在我们的系统中创建对应的虚拟资源位，并通过一个图形化的 json schema 编辑器来定义这个资源位需要消费的数据结构
投放物料
上述 schema 定义了一个资源位所需要消费的数据的格式。但是光有 schema 是不够的，因为资源位要消费的数据，而不是数据结构本身。在我们的系统中，我们用一个动态表单模块根据schema生成动态的表单，产品运营同学通过动态表单生产的数据，我们称之为投放物料。资源位消费的就是投放物料。
对于一些手填数据，表单直接产生的数据就是资源位可用的了。但是对于 Feeds 之类的，表单往往只能定义 Feeds 的一些诸如选品等特征字段。对于这类特殊类型的数据源，服务端就不能简单的直接返回数据了，需要根据这些特征字段，做一些数据查询和数据解析工作，再返回给前端一个完整规范的数据。
投放单元
前述文章说到，同一个banner，可能对新用户投放的是红包，对年轻男孩子投放的是手机数码内容，对年轻女孩子投放的是美妆服饰。我们把这个连接了资源位、投放物料与多个投放因子的桥梁叫做投放单元。
那么投放单元需要有多少个投放因子呢？其实是视业务而定的，我们认为基础的投放因为应该包含 投放时段、投放人群、投放平台、投放AB配置等。
当资源位向投放系统发起请求拉取数据时，投放系统在这个资源位上挂载的所有投放单元中根据投放因子筛选出命中的投放单元，最后将命中的投放单元上挂载的投放物料返回给前端的投放资源位。当命中了多个投放单元时，需要有些方法来裁决出最终胜出的那一个。这个方法简单点做，可以在投放单元中配一个权重，筛选时最后选择权重高的那个，也可以引入算法决策，根据投放的 ctr 数据做排序。
投放计划
投放计划是产品运营对多个资源位管理形式。简单来说，一个投放计划下，可以挂载多个关联的资源位。试想一下，一次大促活动可能涉及到几十个资源位的投放，将这些资源位组织到同一个投放计划中进行管理，可以更加方便操作以及查看投放效果。
アクセス終了
フロントエンドのために、我々は、単に呼び出すことによって、パッケージNPMパッケージを提供することで、入ってくるRESOURCEID（リソースビットのID）がデータを取得することを願っています。
これは、ビジネスに呼び出し側によって呼び出された比較的エレガントですが、それは心配のページのパフォーマンスではありません。ページは、多くの場合、リソースのビット数で構成されているため、リソースの各ビットは、同時要求の多数を開始するために別の要求を形成するページのパフォーマンスが低下しますだけでなく、サーバー上の比較的大きなQPS圧力。
このような状況に鑑み、我々は少し最適化を行いました。サーバは、要求モジュールは、重合を行うために10ms毎に呼び出され、SDK内部フロントエンド、バッチクエリインターフェースを提供し、単一ビットの取得されたデータは、リソースクエリバッチに変換されます。利点は、ページの全体的なパフォーマンスを向上させるためであるリソースビット荷重の一部のデータの負の影響は、最大10msの遅延を引き起こし、効果サーバQPSの圧力を低下させます。
効果
上記の当社の新事業のデリバリーシステムは非常によく練習走行を引き出し、毎日数万ユーザー、無料の魚をサービスを魚ビットアプリケーションにアイドル状態のリソースの何百ものサポートを提供する能力を入れています。これは、単一ビットのリソースの使用率を向上させ、リソースを割り当てるために細かい位置を達成し、事業者にコストを削減するために、様々な新しい引張り試験、試行錯誤を起動するためのより多くの自由を可能にするだけでなく、技術的な学生が頻繁に運用テストの変革に参加削減します開発努力、技術的な生産性の学生の解放。
概要
物品上に単純な送達システムの設計を導入し、本質的に、フロントエンドサーバーの物理リソース位置とブリッジ設計データのさまざまなソースに接続されています。
その多くの容量は、次のようなチーム内の他の学生の努力の結果に依存している：
1、のJSON Schemaの記述方法リソースビットのデータ構造の設計
2、達成するためにどのように動的に生成されたフォームのJSONスキーマに従って
、人々がサービスをチェックし、3とする能力
4 ABテストする能力
5を、選択した商品やサービスのフィード
4、ダイナミックバナーパーソナライゼーション機能
戦略の能力を最適化するためのスクリーニングアルゴリズムを導入する方法、データをよりよく行う方法をリフローなどの最適化を図ることができ、多くの点では、あります。。。連続最適化、我々は方向を遵守しようとしているビジネスのために価値を創造し続けます。
詳細については、それはないだろう、魚の技術の公開自由に注意を払ってください。青山は、緑のフローを変更しないでください -