効率化と開発サイクルの短縮を目的としたコミュニティPHPビジネス開発について

インターネットビジネスが急速に発展している現在、雨後の筍のように新製品が次々と登場し、古い製品ラインや新しいビジネスも絶えず突破口を開き、実験が行われています。これにより、迅速な開発反復に対する要求が高まります。

1. 基本的な動作環境

新製品の開発には、LAMP アーキテクチャを迅速に構築できることが必要です。その後は、Web サーバーの選択、PHP バージョンの選択、MySQL バージョンの選択、PHP 開発フレームワークの選択、PHP 共通拡張機能と基本ライブラリの選択を行うだけです。読者は、このプロセスはすでに非常に高速だが、さらに高速化できるのではないかと思うかもしれません。

選択プロセスでは、R&D 担当者が関連する技術方向について一定の蓄積を持ち、長所と短所、優先順位を比較検討し、調査と研究を行うことが求められます。ウェブサーバー、PHP、MySQL の自動インストールを提供し、高性能で柔軟な PHP 開発フレームワークを搭載し、標準化され、安全で、よく使用される構成ファイルを提供するワンクリック インストール プログラムがあれば、製品ラインの LAMP システム研究のコストを大幅に削減し、作業サイクルを短縮できます。

ワンクリックインストールは、(1)ダウンロード、(2)ちょっとした設定、(3)インストール、(4)起動の4ステップで完了します（もちろん終了、簡単な操作・保守ツールもあります）、動作環境はOKです。

2. 事業開発フレームワーク

コミュニティ製品ラインは独立しており、独自のビジネス ロジックをクローズドな方法で開発します。実際、セッション検証、権限判定、パラメータ検証、ログ出力など、さまざまな製品ライン間で共通するビジネスロジックプロセスは数多くあります。異なる製品ラインからのすべてのリクエストは、このように処理する必要があります。開発の重複を避けることは可能ですか? ワイヤレスビジネス開発と PC 上のビジネスロジックには多くの違いがありますが、異なる製品ライン間でも多くの共通点があります。開発の重複を避けることは可能ですか?

製品ラインでは通常、これらの共通ロジックの処理を内部的に抽象化し、ActionChain の形式または基本クラス ソリューションを通じて設計します。フレームワークはより徹底したものとなり、これらすべてのリクエストを処理するための共通ロジックがビジネス ロジック フレームワークの形で提供され、R&D 担当者はユーザー リクエストに固有のロジック処理にのみ集中できるようになります。

ユーザーリクエストの処理ロジックは次の図のようになります。青い部分はコントローラーフレームワークの処理フローで、緑の部分はコントローラーフレームワークと組み合わせて、すべてのリクエストに共通するビジネスロジックを処理します。 R&D の同僚の注意と開発が本当に必要なユーザー リクエスト専用のビジネス処理は黄色の部分です (もちろん、これは単なるアクション スクリプトではありません。リクエストの処理は、後で関与する MVC に水平に階層化されます)。

ビジネスロジックフレームワークの継承はワンクリックインストーラーで提供されており、簡単に入手できます。

ネイティブ PHP ビジネスとテンプレートは階層化設計なしで深く結合されており、コードの再利用性が低下します。このオリジナルの PHP システムは現在ではほぼ消滅しています。 PHP 開発フレームワークは、ルーティング、レンダリング、AutoLoad、共通ビジネス ロジックと基本ライブラリの抽象化、独自のビジネス MVC 階層化を統一的に処理し、製品ラインのビジネス ロジックの開発を大幅に加速します。次の図に示すように:

上から順に、アクセス層 (高性能 Web サーバー)、PHP 開発フレームワーク (ルーティング、自動読み込み、ビュー エンジンなど)、アプリケーションおよび基本ライブラリ、ストレージ エンジンです。

3. 一般サービス

コミュニティ製品ラインには、ログ処理、構成ファイルの処理、文字列処理、データベースの相互作用、ネットワークの相互作用など、多くの共通要件があります。これらのアルゴリズムとツールは、製品ラインで使用するために phplib にパッケージ化されており、比較的成熟しています。

コミュニティ製品ラインには、コメント機能、タグ機能、友達機能、アルバム、タスク システムなど、共通のビジネス機能が多数あります。多くのコミュニティ製品ラインには、同様の新機能と新しい要件があります。それらは個別に設計および開発されていますか?

これらの要件は、各製品ラインの UI に対して個別の要求を伴いますが、バックエンドの実装ソリューションは類似しており、ある程度の普遍性があります。機能的なサービスが提供され、さまざまな製品ラインで使用できるように API インターフェイスが提供されます。製品ラインは、表示ロジックとプライベート データの処理ロジックに集中するだけで済みます。サービスは統一された方法で運用および保守されるため、製品下のシステムの複雑さが軽減されます。

4. 垂直分割サブシステム

事業が拡大するにつれ、単一アプリケーション内の UI やモジュールの数が増加し、Action と Logic (MVC の M 層に相当。内部的にさらに階層化できるため、今回は詳しく説明しません) 間のやり取り、ロジックとロジック間のやり取りがますます複雑になっていきます。開発者はアプリケーション全体のロジックを理解する必要があります。特定のロジックをアップグレードするには、アプリケーション全体の他の UI またはロジックとの逆依存関係があるかどうかを確認する必要があります。迅速な開発の要求により、開発者はロジック間の相互結合関係を明確に把握できず、ますます多くの問題が発生し、プロジェクトの品質に影響を与え、開発の開始が困難になります。

単一システムの問題が次々と明らかになるにつれて、システムを分割する時期が来ます。どのように分割しますか? ビジネス ロジックに従って垂直に分割します。機能的に独立したビジネス ロジックを分離し、独立したサブシステムにします。このとき、ビジネスの普遍性も考慮する必要があります。サービス指向にできますか？アプリケーションにはすでに同じ要件を持つユニバーサル サービスがありますか？このとき、ユニバーサル ビジネス ロジックはユニバーサル サービスにカプセル化されるか、ユニバーサル サービスが使用され、バイパスされたビジネス ロジックはサブシステムとして独立しています。このようにして、元の単一の巨大なシステムにかかる負担が大幅に軽減されます。この再構築フェーズが完了すると、システムは次のようになります。

単一のシステムが複数のアプリに分割され (アプリ内には水平方向の MVC レイヤーが残っています)、多数の共通サービスが再利用されます。その結果、R&D チームの人員分担と並行開発が大幅に改善されました。

5. システム間コールフレームワーク

しかし、実際には、分割されたサブシステム間の依存関係を完全に排除することはできません。複数のサブシステム間のデータ依存関係を解決するには、統一されたソリューション、つまり API フレームワークが必要です。サブシステムは独立したアプリケーション（APP）となり、APP間には相互のデータ依存関係があり、APIの形で外部に提供されます。以下のように表示されます。

APP1 が APP2 または APP3 のデータに依存する場合、APP2 と APP3 はデータ インターフェイスの一部を API の形式で提供し、データを統一された方法でパッケージ化し、製品ライン内の他の APP が呼び出すための標準 URL を通じて提供します。この形態は、製品がAPIを外部に公開する形態に非常に似ており（第三者に公開されるAPIはオープンAPIと呼ばれ、統一されたプロトコルに準拠し、必要な権限検証を受ける）、内部サブシステム間のデータ依存関係を解決するAPIインターフェースをさらに簡素化することができます。

APP が提供する API は、インターフェース記述 (入力、出力) の提供、API URL の処理、ロジックの実装の転送という問題を解決します。 API_LIB はすべての API インターフェースを統一された方法で管理し、呼び出し用の統一された API_Server::call インターフェースを提供します。内部転送と実装の詳細を完全に保護します。通常、製品ライン内の操作と保守を簡素化および統一するために、すべてのサブシステムは同じマシンに展開されます。API インターフェースにより、ネットワーク消費が増加し、QPS が増加します。この展開の前提では、API_Server の実装は HTTP 呼び出しを通じて実装することも、PHPRequire を直接実行するように最適化することもできます。利点:

（１）フレームワークの統一、インターフェースの収束、ビジネスの分離

（２）性能の向上、高いユーザビリティ、高いスケーラビリティ

6. UI分割モデル

この時点で、独立したサブシステムはビジネス ロジックに集中でき、コア システムの負担も軽減されます。ただし、コアシステムはアップグレードと更新の頻度が最も高く、ビジネス ロジックも最も複雑です。一定期間が経過すると、コアシステムが肥大化し、保守が困難になりました。現時点では、いくつかの設計パターンを使用すると、プログラムのスケーラビリティと保守性が低下する可能性があります。しかし、それでも一定の学習コストはあります。アプリ内では、開発者は他のモジュールのコードに多かれ少なかれ注意を払う必要があり、徐々に、1 つのポイントをアップグレードするときに多くのポイントを確認する必要があるところまで発展します。今こそ、負担をさらに軽減すべき時です。負担を軽減するにはどうすればよいでしょうか? それは 2 つの部分に分かれています。

ステップ1: 非同期モデル

ページのレンダリングは、対象ページ データとその他の対象以外のページ データの 2 つの段階に分かれています。さまざまなデータ ソースがページのさまざまな部分のデータを提供します。このロジックによれば、アプリはさらに垂直に分割できます。

PHPService は PHP モジュール + 薄い UI レイヤーで構成され、フォーマットされたデータを返します。

ステップ2: モデルを同期する

モジュールは分割され、異なるビジネス ロジックは異なるモジュールに分割され、それぞれ異なるデータ コンテンツを提供する複数のデータ ソースに分割されます。統一された UI がさまざまなデータ ソースをスケジュールした後、ページがレンダリングされ、応答が統一された方法で返されます。

負担が軽減され続けるにつれて、製品ライン内のサブシステムとモジュールがますます増え、統一された展開と運用および保守の維持が必要になります。チームメンバー間の分業は非常に細かく、ビジネス理解は非常に集中的かつ深く、協力と並列化の効率が高くなり、開発サイクル全体が短縮されます。

VII. 要約

ビジネス ロジックが拡大するにつれて、各サブシステムまたはモジュールのビジネス機能が肥大化しすぎる場合は、制御可能な規模内に維持するために継続的に縮小する必要があります。製品が発展するにつれて、製品ライン内のサブシステムやモジュールはますます増えていきますが、展開と運用・保守の統一性を保ち、シンプルに保つことが必要になります。チームメンバー間の分業がより詳細になり、ビジネス理解が集中的かつ深くなり、協力と並列化の効率が高まり、開発サイクル全体が短縮されます。

原題: 効率化と開発サイクルの短縮を目的としたコミュニティPHPビジネス開発について

キーワード: トーク、コミュニティ、PHP、ビジネス、開発、改善、効率、短縮、開発週、ウェブマスター、ウェブサイト、ウェブサイトのプロモーション、収益化