コミュニティ PHP ビジネス開発について語る_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 17:43:15973ブラウズ
インターネットビジネスが急速に発展している現在、新製品は雨後の筍のように湧き出ており、古い製品ラインや新しいビジネスは常に画期的な進歩と試みを行っています。これにより、迅速な開発反復に対するより高い要件が要求されます。
1.基本動作環境
新製品の開発には、LAMP アーキテクチャを迅速に構築できる必要があります。次に、Web サーバーを選択し、PHP バージョンを選択し、MySQL バージョンを選択し、次に PHP 開発フレームワークを選択し、PHP の一般的な拡張機能と基本ライブラリを選択するだけです。読者は、このプロセスはすでに非常に高速であると考えるかもしれません。
選考プロセスでは、研究開発の学生は関連する技術的方向性を一定に蓄積し、長所と短所、優先順位を比較検討する必要があり、研究と学習の期間でもあります。 Web サーバー、PHP、および MySQL の自動インストールと、高性能で柔軟な PHP 開発フレームワークを提供し、標準化された安全で一般的に使用される構成ファイルを提供するワンクリック インストール プログラムがあれば、インストール時間を大幅に短縮できます。製品ラインLAMPシステムの研究コストを削減し、作業サイクルを短縮します。
ワンクリックインストールの 4 つのステップ: (1) ダウンロード、(2) インストール、(4) 開始 (もちろん、簡単な操作とメンテナンスのツール)実行環境はOKです。
2.事業開発フレームワーク
コミュニティの製品ラインは独立しており、独自のビジネス ロジックをクローズドな方法で開発する必要があります。実際、セッション検証、権限判定、パラメータ検証、ログ出力など、さまざまな製品ライン間で共通するビジネスロジックプロセスが数多く存在します。異なる製品ラインについては、すべてのリクエストを処理する必要があります。開発を繰り返すことはできませんか?ワイヤレス ビジネス開発と PC 上のビジネス ロジックの間には多くの違いがありますが、異なる製品ライン間には多くの共通点もあります。開発を繰り返すことはできないのでしょうか？
製品ラインは通常、これらの一般的なロジックの処理を内部である程度抽象化し、ActionChain の形式または基本クラス ソリューションを通じて設計します。フレームワークはより徹底され、すべてのリクエストで処理する必要がある共通ロジックはビジネス ロジック フレームワークの形式で提供され、研究開発学生はユーザー リクエストに固有のロジック処理のみに集中する必要があります。
ユーザーリクエストの処理ロジックは以下のとおりです。青色の部分はコントローラーフレームワークの処理フロー、緑色の部分はコントローラーフレームワークと結合して、すべてのリクエストに共通のビジネスロジックを処理します。研究開発学生の注意と開発を本当に必要とするユーザーは、独自の業務処理、つまり黄色の部分を要求します (もちろん、1 つは単なる Action スクリプトではなく、リクエストの処理は MVC によって水平階層化され、後で説明します。)
ビジネス ロジック フレームワークの継承はワンクリック インストーラーで提供されているため、簡単に入手できます。
ネイティブ PHP ビジネスとテンプレートは階層化された設計なしで深く結合されているため、コードの再利用性が低くなります。このようなオリジナルの PHP システムは、現在ではほとんど消滅しています。 PHP 開発フレームワークは、ルーティング、レンダリング、AutoLoad、一般的なビジネス ロジックと基本ライブラリの抽象化、および独自のビジネス MVC 階層化を均一に処理し、製品ラインのビジネス ロジックの開発を大幅に加速します。下の写真に示すように:
上から下に、アクセス層 (高性能ウェブサーバー)、PHP 開発フレームワーク (ルーティング、自動読み込み、ビュー エンジンなど)、アプリケーションおよび基本ライブラリ、ストレージ エンジンです。
3. 一般的なサービス
コミュニティ製品ラインには、ログ処理、構成ファイル処理、文字列処理、データベース対話、ネットワーク対話など、多くの共通のニーズがあります。これらのアルゴリズムとツールは phplib にパッケージ化されており、製品ラインで使用するには比較的成熟しています。
コミュニティ製品ラインのビジネス機能には、コメント機能、タグ機能、友達機能、フォトアルバム、タスクシステムなど、多くの共通点があります。多くのコミュニティ製品ラインには、同様の新機能と新しい要件があり、それらは設計されていますか?別途開発？
これらの要件には、各製品ラインの UI に関する個別の要件がありますが、バックエンドの実装ソリューションは類似しており、ある程度の汎用性があります。機能サービス化では、さまざまな製品ラインで使用できる API インターフェイスが提供され、製品ラインは表示ロジックとプライベート データ処理ロジックにのみ焦点を当てる必要があり、サービスは製品の下でシステムの複雑さを軽減するために統一された方法で運用および保守されます。
4. 垂直分割サブシステム
ビジネスが拡大するにつれて、1 つのアプリケーション内の UI やモジュールの数が増加し、アクションとロジック (MVC の M 層に相当し、内部でさらに階層化することができますが、今回は詳しく説明しません) の間の相互作用は、論理と論理の間はますます複雑になります。開発者はアプリケーション全体のロジックを理解する必要があり、特定のロジックをアップグレードするには、アプリケーション全体で他の UI またはロジックへの逆依存関係が存在するかどうかを確認する必要があります。迅速な開発が求められる中、開発者はロジック間の結合関係を明確に理解していないため、必然的に問題がどんどん発生し、プロジェクトの品質に影響を及ぼし、開発の開始が困難になります。
単一システム内で露呈する問題が増えているため、システムを分割する時期が来ています。解体方法は？ビジネスロジックごとに垂直分割します。機能的に独立したビジネス ロジックを独立したサブシステムに分離します。現時点では、ビジネスの多様性も考慮する必要があります。サービス指向にできるかどうか。アプリケーションには同じニーズを持つ共通のサービスがすでにありますか?このとき、一般的なビジネスロジックは一般的なサービスにカプセル化するか、一般的なサービスを利用し、バイパスされたビジネスロジックは独立してサブシステム化することで、元の単一の巨大システムへの負担を大幅に軽減します。この再構築段階が完了すると、システムは次のようになります:
単一のシステムが複数の APP に分割され (APP 内には水平 MVC 層がまだ存在します)、多数の共通サービスが再利用されます。その結果、研究開発チームは分業と並行開発を大幅に改善しました。
5. クロスシステムコールフレームワーク
しかし、現実には、分割されたサブシステム間の依存関係を完全に排除することはできません。複数のサブシステム間のデータ依存関係を解決するには、統一されたソリューション、つまり API フレームワークが必要です。サブシステムは独立したアプリケーション (APP) となり、APP 間には相互のデータ依存関係があり、これらの依存関係は API の形式で外部に提供されます。以下に示すように:
APP1 が APP2 または APP3 のデータに依存する場合、APP2 と APP3 はデータ インターフェイスの一部を API の形式で提供し、データは均一にパッケージ化され、製品ライン内の他の APP 呼び出しは標準 URL を通じて提供されます。この形式は、製品の外部へのオープン API (サードパーティへのオープン API、私たちはこれを openAPI と呼び、統一プロトコルに準拠し、必要な権限の検証を受けます) と内部間のデータの依存関係を解決する API インターフェイスに非常に似ています。サブシステムはさらに簡素化できます。
APP が提供する API ソリューションは、インターフェイスの説明 (入力、出力)、処理 API URL、およびロジック転送の実装を提供します。 API_LIB は、すべての API インターフェイスを統合された方法で管理し、呼び出し用の統合された API_Server::call インターフェイスを提供します。シールドの内部転送および実装の詳細と完全に一致しています。通常、製品ライン内の運用とメンテナンスを簡素化および統合するために、すべてのサブシステムが同じマシンにデプロイされると、ネットワーク消費量が増加し、QPS が増加します。この展開前提の下では、API_Server は HTTP 呼び出しを通じて実装することも、PHPRequire を指示するように最適化することもできます。利点:
(1) フレームワークの統合、インターフェースの統合、ビジネスの分離
(2) パフォーマンスの向上、高い使いやすさ、高い拡張性;
6. UI分割モデル
このとき、独立したサブシステムはビジネスロジックに集中でき、基幹システムの負担も軽減されます。ただし、基幹システムはアップグレードと更新の頻度が最も高く、ビジネス ロジックも最も複雑です。一定期間が経過すると、コア システムが肥大化して保守が困難になります。このとき、一部の設計パターンを使用すると、プログラムの拡張性や保守性が低下する可能性があります。しかし、そうであっても、アプリ内では、開発者は多かれ少なかれ、他のモジュールのコードに注意を払う必要があり、アプリが徐々に開発されるにつれて、アップグレードには多くの点でトラブルシューティングが必要になります。負担をさらに軽減する時代が来ています。負担が軽減されたらどうなるでしょうか？ 2 つの部分に分かれています:
ステップ 1: 非同期モデル
ページのレンダリングは、トピック ページ データとその他の非トピック ページ データの 2 つの段階に分かれています。データは、ページのさまざまな部分に基づいてさまざまなデータ ソースから提供されます。このロジックに従えば、アプリはさらに縦に分割されます。
PHPService は PHPmodule + 非常に薄い UI で構成され、フォーマットされたデータを返します。
ステップ 2: モデルを同期する
モジュール分割。さまざまなビジネス ロジックがさまざまなモジュールに分割され、複数のデータ ソースに分割され、それぞれが異なるデータ コンテンツを提供します。統合 UI がさまざまなデータ ソースをスケジュールした後、統合レンダリング ページが応答を返します。
このような継続的な負荷削減の後、製品ライン内のサブシステムとモジュールはますます増え、展開と運用と保守の統一性を維持する必要があります。チームメンバー間の役割分担は非常に詳細であり、ビジネスの理解は非常に集中的かつ深く行われ、協力と並列処理の効率が高くなるため、開発サイクル全体が短縮されます。
7.まとめ
ビジネス ロジックが拡大するにつれて、各サブシステムまたはモジュールのビジネス機能が肥大化しすぎる場合は、制御可能な規模内に保つために継続的に削減する必要があります。製品が発展するにつれて、製品ライン内のサブシステムやモジュールの数はますます増え、展開、運用、メンテナンスを統合してシンプルに保つ必要があります。チームメンバー間の分業はより詳細になり、ビジネスの理解は焦点を絞った深いままとなり、協力と並列処理の効率が高くなり、開発サイクル全体が短縮されます。
投稿者: ルハイシア