取得バック1のApp
1.1アプリケーションのバックグラウンド機能
（1）リモートストレージトランザクション。
（2）転送メッセージ。
1.2アプリケーションの背景アーキテクチャ
アーキテクチャ設計プロセス
（1）アプリケーション、ビジネスプロセスアウトのAppソートのデザイン。
（2）すべてのビジネス・プロセスを整理発生する可能性がある問題。
問題によると、（3）は、実行可能な技術的解決策を探る整理しました。
（4）技術ソリューションの有機的統合のすべては、予備的なフレームワークアプリケーションのバックグラウンドです。
建築デザインの特徴
（1）アーキテクチャと密接にビジネスに関連しています。
（2）アーキテクチャの進化は、ビジネスによって駆動されます。
（3）技術アーキテクチャを誇示するためではありません。
1.3アプリケーションとApp楽屋通信
（1）HTTPプロトコルまたは独自のプロトコル。
（2）が長いか短い接続で接続されています。
（3）通信データ形式（JSON、XML）
[サーバー1.4
（1）従来のIDC。
（2）クラウドサーバ。
開発言語の選択1.5
（1）ビジネスシナリオと異なる言語は、その優れた性能特性を持っています。
（2）効率及び動作効率の開発を考慮し、
別の言語を使用することができ、同じプロジェクトである（3）ビジネスロジック。
1.6アジャイル開発
（1）スプリント計画ミーティング。
（2）反復的開発。
（3）毎日のミーティング。
（4）再検討会議。
（5）再検討会議。
（6）タイムリーなフィードバック。
2アプリケーションの基盤となる技術の背景
ビジネスロジックから2.1抽出APIインタフェース
ビジネスロジックからの抽出物のAPIは、以下の6つの段階に分けることができる：
（1）ビジネスロジックマインドマップ。
抽象ビジネス・ロジックのニーズによると。
（2）機能 - マインドマップのビジネスロジック。
サービス論理機能モジュールをサポートし、
（3）基本的な機能モジュールとの間の関係。
モジュール設計;
（4）UMLデザイン機能モジュール。
（5）APIの設計。
（6）書き込みAPIドキュメント。
威張っ-UIオンラインAPIのテストドキュメント、テスト駆動開発（TDD）。
ポイント2.2 APIの設計
（1）オブジェクトに基づいてAPIの設計。
命名規則（2）API。
（3）APIのセキュリティ;
（4）APIリターンデータ。
（5）ピクチャーモード。
（6）返信メッセージ。
（7）オンラインAPIのテストドキュメント;
（8）APIのバージョンアップ。
2.3適切なデータベース製品を選択します
（1）のRedis、MongoDBのは、MySQL
2.4メッセージキュー製品の選択
（1）メッセージ・キューは、典型的には3つの文字からなる：キューサーバ、キュープロデューサ、コンシューマキュー;
（2）共通メッセージキュー製品、RabbitMQの、Redisの、ZeroMQ、ActiveMQの、RocketMQ。
2.5分散サービス
（1）リモート・サービス、REST、RPC。
2.6検索技術
（1）オープンソースの検索プロジェクト、のLucene、Solrの、ElasticSearch、スフィンクス、CoreSeek。
2.7タイミングタスク
（1）Linuxのカスタムタスクのcrontab。
（2）は、Javaクォーツ。
（3）パイソンAPScheduler。
3アプリのコア技術の背景
3.1ユーザー認証方式
（1）HTTPSプロトコルを使用して、
（2）+キーを使用してトークン。
3.2 通信安全
（1）URL署名。
（2）は、対称暗号化をAES。
3.3ショートメッセージサービス
（1）は、SMSのプラットフォームを選択します。
3.4効率的なデータ更新
（1）プッシュコンテンツ。
（2）増分アップデート。
3.5画像処理
（1）APPローカルキャッシュイメージ;
異なるサイズの（2）動的に生成された画像。
3.6ビデオ処理
（1）FFmpegの。
3.7リソースファイル
（1）アンドロイド-APKtoolにより、基本情報ファイル用のAndroid APKファイル。
（2）のiOS IPAファイル。
3.8ファイルシステム
（1）クラウドストレージ、CDN。
（2）分散ファイルシステム。
3.9 ELKログ解析プラットフォーム
（1） Logstash、ElasticSearch、Kibana。
3.10 Docker容器
（1）ドッカーは、一貫した開発環境を構築します。
4アプリケーションの背景の運用・保守
4.1 Linuxでは、アプリケーションの舞台裏最も広く使用されているシステム
（1）共通コマンド、上部、PS、netstatの、lsofを、トレースルート
武器4.2 Nginxは、アプリケーションのバックグラウンドのHTTPサービス
（1）HTTPサービス。
（2）負荷分散。
4.3 MySQLの、アプリケーション舞台裏最も一般的なデータベース
（1）ストレージエンジン、MyISAMテーブル、InnoDBの。
（2）屈折率;
（3）サブライブラリーサブテーブル、MyCat。
4.4のRedis、アプリのバック高性能キャッシュシステム
（1）共通のデータ構造。
（2）クラスタ、Twemproxy、CODIS。
（3） 持久化。
4.5 MongoDBは、アプリの舞台裏新興データベース
（1）可用性クラスタ。
（2）LBS。
5アプリのバックグラウンドのアーキテクチャ分析
チャットアプリの5.1アーキテクチャの背景
ネットワーク特性（1）モバイルインターネット、弱い、トラフィック感受性のネットワーク。
（2）プロトコル、XMPP、MQTT、ActivitySync、TCPカスタム。
接続層、ビジネス層、データ層を含む（3）全体的な構造、;
（4）プッシュプル・モード・メッセージ。
（5）データベース・スキーマ、スタンドアロン配置、別個読み出し及び書き込み、サブサブテーブル・リポジトリ。
（6）キャッシュ・アーキテクチャ、キャッシュマスターから単一のキャッシュ、分散キャッシュ、。
5.2 LBSアプリケーションの背景アーキテクチャ
（1）地理的座標、GPS、基地局、AGPS（GPS +結合基地局）、無線LAN測位。
MongoDBのベース（2）。
（3）プッシュサービス。
進化6のApp背景アーキテクチャ
アーキテクチャの6.1コア要素
ソフトウェアアーキテクチャは、大規模なソフトウェアシステムの設計指針のさまざまな側面のためのソフトウェアとコンポーネントの全体的な構造の抽象的な記述です。各構成要素の機能として定義され、アプリの背景アーキテクチャは、全体的なシステム構成の間の関係をアプリの背景を説明しました。背景アーキテクチャのコア要素のアプリケーション：
（1）高性能。
（2）高可用性。
（3）伸縮自在。
（4）が拡張することができます
（5）セキュリティ。
6.2アーキテクチャの選択のポイント
成熟し、安定したオープンソースソフトウェア（1）;
（2）可能な限り、クラウドサービスを使用しています。
進化6.3アーキテクチャ
（1）シングル展開。
（2）配置分散。
サービスとして（3）。