効率を向上させ、開発サイクルを短縮するためのコミュニティ PHP ビジネス開発について話し合う-php手册-php.cn

インターネットビジネスが急速に発展している現在、新製品は雨後の筍のように湧き出ており、古い製品ラインや新しいビジネスも絶えず進歩と試みを行っています。これにより、迅速な開発反復に対するより高い要件が要求されます。

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 の階層化を均一に処理し、製品ラインのビジネスロジックの開発を大幅に加速します。以下に示すように:

上から下に、アクセス層 (高性能 Web サーバー)、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. まとめ

ビジネスロジックが成長するにつれて、各サブシステムまたはモジュールのビジネス機能が肥大化しすぎる場合は、制御可能な規模内に保つために継続的に削減する必要があります。製品が発展するにつれて、製品ライン内のサブシステムやモジュールの数はますます増え、展開、運用、メンテナンスを統合してシンプルに保つ必要があります。チームメンバー間の分業はより詳細になり、ビジネスの理解は焦点を絞った深いままとなり、協力と並列処理の効率が高くなり、開発サイクル全体が短縮されます。