【譲渡】コミュニティPHP事業展開について語る

【再投稿】コミュニティPHP事業展開について語る

元のアドレス: http://stblog.baidu-tech.com/?p=1954

?

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

1. 基本動作環境

新製品の開発には、LAMP アーキテクチャを迅速に構築できる必要があります。次に、Web サーバーを選択し、PHP バージョンを選択し、MySQL バージョンを選択し、次に PHP 開発フレームワークを選択し、PHP の一般的な拡張機能と基本ライブラリを選択するだけです。読者は、このプロセスはすでに非常に高速であると考えるかもしれません。

選考プロセスでは、研究開発の学生は関連する技術的方向性を一定に蓄積し、長所と短所、優先順位を比較検討する必要があり、研究と学習の期間でもあります。 ワンクリック インストール プログラム がある場合は、Web サーバー、php、mysql の自動インストールを提供し、高性能で柔軟な php 開発フレームワークを搭載し、標準化された安全で一般的に使用される構成ファイルを提供します。 、製品ラインを大幅に短縮できる LAMP システム 研究コストを削減し、作業サイクルを短縮します。

?

ワンクリックインストールの 4 つのステップ: (1) ダウンロード、(2) 簡単な設定、(4) 開始 (もちろん、簡単な操作とメンテナンスのツール) 、実行環境は問題ありません。

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

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

製品ラインは通常、これらの一般的なロジックの処理を内部である程度抽象化し、ActionChain の形式または基本クラス ソリューションを通じて設計します。フレームワークはより徹底されます。すべてのリクエストで処理する必要がある共通ロジックは ビジネス ロジック フレームワーク の形式で提供され、研究開発の学生はユーザー リクエストの特定のロジック処理にのみ集中する必要があります。

ユーザー リクエストの処理ロジックは次のとおりです。青色の部分はコントローラー フレームワークの処理フローで、緑色の部分はコントローラー フレームワークと結合して、すべてのリクエストの共通のビジネス ロジックを処理します。研究開発学生の注意と開発を本当に必要とするユーザーは、独自の業務処理、つまり黄色の部分を要求します (もちろん、1 つは単なる Action スクリプトではなく、要求の処理は MVC によって水平階層化され、後で説明します。)

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

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

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

3. 一般的なサービス

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

コミュニティ プロダクト ラインのビジネス機能には、コメント機能、タグ機能、フレンド機能、アルバム、タスク システムなど、多くの共通点があります。多くのコミュニティ プロダクト ラインは、同様の新機能や新しい要件を持ち、設計されています。と別々に開発されました。

これらの要件には、各製品ラインの UI に関する個別の要件がありますが、バックエンドの実装ソリューションは類似しており、ある程度の汎用性があります。 機能サービス は、さまざまな製品ラインで使用するための API インターフェイスを提供し、製品ラインは表示ロジックとプライベート データ処理ロジックのみに重点を置く必要があり、サービスは統一された方法で運用および保守されるため、システムが削減されます。製品の背後にある複雑さ。

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

ビジネスの拡大に伴い、単一アプリケーション内の 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 インターフェイスを提供します。シールドの内部転送および実装の詳細と完全に一致しています。通常、製品ライン内の運用とメンテナンスを簡素化および統合するために、すべてのサブシステムが同じマシン上にデプロイされ、API インターフェイスによりネットワーク消費量が増加し、QPS が増加します。この展開前提の下では、API_Server の実装は HTTP 呼び出しを通じて実装することも、PHPRequire を直接指定するように最適化することもできます。利点:

(1) フレームワークの統合、インターフェースの統合、ビジネスの分離

(2) パフォーマンスの向上、高い使いやすさ、高い拡張性

6. UI 分割モデル

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

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

ページのレンダリングは、トピック ページ データとその他の非トピック ページ データの 2 つの段階に分かれています。データは、ページのさまざまな部分に基づいてさまざまなデータ ソースから提供されます。このロジックに従えば、アプリはさらに縦に分割されます。

PHPService は、PHP モジュールと、フォーマットされたデータを返す UI の薄い層で構成されます。

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

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

このような継続的な負荷削減の後、製品ライン内のサブシステムとモジュールはますます増え、展開と運用および保守の統一性を維持する必要があります。チームメンバー間の役割分担は非常に詳細であり、ビジネスの理解は非常に集中的かつ深く行われ、協力と並列処理の効率が高くなるため、開発サイクル全体が短縮されます。

7. まとめ

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

ルハイシア作