正確には、1.0プラットフォームのモノリシックアプリケーションアーキテクチャにはインターネットプロジェクトアーキテクチャがありません。従来のMVC開発モデルと単純な小規模ワークショップの運用プロセスは、開発者ごとに、ビジネス機能モジュールの実現に注意を払うだけで済みます。1.0プラットフォームの運用の6か月間で、ビジネスニーズの爆発的な成長に加えて、開発の反復は迅速である必要があり、各アップグレードは骨を傷つけてはならず、元のフレームワークでのモジュール性の蓄積または部分的な更新だけです。これらに加えて、ログプラットフォーム、監視プラットフォーム、スケジューリングプラットフォーム、レポートプラットフォーム、さらにはアクセス許可やシングルサインオンなど、プラットフォームの運用効率を向上させるために、1.0プラットフォーム自体の基本的な運用機能も緊急に必要であることがわかりました。非常に必要なので、2.0プラットフォームの全体的な計画を含める必要があります。
1つのプラットフォーム全体の容量計画
これは主に、元のビジネスレイヤーからいくつかのパブリックなものを削除し、プラットフォームベースのソフトウェアパッケージモデルで動作します。
1.統合スケジューリングプラットフォームは、プロジェクトの多くのビジネスでよく使用されますが、1.0プラットフォームは、スケジューリング作業とビジネス実行作業をコードで組み合わせているため、多くのスケジューリング作業が後のメンテナンスに非常に不便であり、スケジューリングでは現在の操作を監視できません。スケジュールと次回実行するスケジュール。統合スケジューリングプラットフォームは、この問題を解決し、管理インターフェイスを介してプラットフォームのすべてのスケジューリング作業を効果的に維持できます。設計の観点から、スケジューリング作業はスケジューリングプラットフォームに属し、ビジネスの実行はそれぞれのビジネスプラットフォーム（マイクロサービス）に属します。 。
2.統合インターフェイスプラットフォームは、主に、フロントエンドアプリケーションシステムが統合インターフェイスプラットフォームを介してデータを取得し、外部システムインターフェイスと直接対話しないことを解決します。統合インターフェースプラットフォームは、さまざまな方法で外部システムに接続してデータを取得し、さまざまなデータ形式パッケージをフロントエンドアプリケーションシステムに提供して、外部システムをビジネスシステムから効果的に分離します。フロントエンドアプリケーションシステムによって要求された外部インターフェイスは、統合インターフェイスプラットフォームに登録して開く必要があります。すべての訪問は効果的に記録および監視されます。フロントエンドとバックエンドの分離アーキテクチャシステム（実際にはマイクロサービスはそのようなものです）では、統合されたインターフェイスプラットフォームは、クロスドメインと負荷分散の役割も果たします。
3.初期段階の統合ログプラットフォームは、主にLinuxサーバーにログインし、ログログを表示するためのさまざまなアカウント権限を開くという問題を解決します。これにより、開発者は管理インターフェイスを介してログを管理および表示して作業効率を向上させることができます。ELKログは中期および後期段階で分析されます。プラットフォームに作業が導入されます。
4.統合権限プラットフォームは、主に多くのさまざまなプラットフォーム（上記のスケジューリングプラットフォーム、インターフェイスプラットフォーム、ログプラットフォームなど）の権限を統合管理するためのものです。この部分は、SSOシングルサインオンと組み合わせて使用されます。従来に従って各プラットフォームに割り当てられている場合アカウントの操作はより面倒です。統合権限プラットフォーム+ SSOシングルサインオンは、アカウントの割り当て、権限の割り当て、および操作のための主要なプラットフォームへの入力の問題を解決することです。
5.ユニファイドメッセージングプラットフォームは、主に内部ビジネスシステムのMQミドルウェアプラットフォームの管理を目的としています。ユニファイドスケジューリングプラットフォームに似ています。ビジネスの実行はビジネスに属します。MQは非同期転送のみを担当します。より堅牢で高速なhttpなどの複数のプロトコルを介してアクセスできます。 、メンテナンスがより便利です。
6. SSOシングルサインオン。繰り返しログインしなくても、相互に信頼できるすべてのアプリケーションシステムにアクセスするには、一度ログインするだけで済みます。
より多くのプラットフォームがまだ計画されており、以下の記事でもそれらを1つずつ取り上げ、遭遇したいくつかの落とし穴と行われたいくつかの最適化を共有します。
2つの事業領域が分割
2.0アーキテクチャシステムの事業分割は頭痛の種です。正直なところ、現在の特定のプロジェクトチームの状況とサーバーの計画によれば、詳細すぎたり粗すぎたりすることは、段階に応じて削除および最適化することしかできません。ですから、私の計画は、最初にビジネス機能に応じて少し分解し、マイクロサービスフレームワークプラットフォームの全体的なプロセスが安定した後、各ビジネス機能の分割を調整することです。
事業領域が分割されると、データベースも元の単一データベースから複数のデータベースに分割されることを意味します。
データベースアーキテクチャに関しては、サーバーのコストを考慮すると、初期段階では単一のマシンの可用性が高く、後の段階でシャードクラスターが実装されます。
3サービスアーキテクチャ
フロントエンドリクエストからバックエンドまでの一般的なプロセス（特に実際のプロジェクトの対象）：
1. htmlフロントエンドページにアクセスし（各ページでcheckCookie.jsが紹介されています）、Cookieが失敗した場合は、ssoシングルサインオンページにジャンプします。
2. ssoはユーザーとパスワードを正常に認証した後、トークンを生成し、それをredisとcookieに書き込みます。
3. ssoは、アクセスする必要のあるhtmlフロントエンドページ（各ページでcheckAuth.jsが導入されます）、htmlフロントエンドページリクエスト（リクエスト後）の統合権限プラットフォームにジャンプします。権限プラットフォームは、Cookieからトークンを取得し、トークンからユーザー情報を取得します。 、リソースメニューのユーザーロールと特定の権限を照会し、それをhtmlフロントエンドに返します。
4. htmlフロントエンドは、現在のユーザーロールが所有する特定のリソースメニューに応じて異なるdivブロック表示を表示します（ページレイアウトが面倒な場合は、元のページを変更することもできません。divブロックのコンテンツを許可なくシールドするか、許可なく表示するだけです）。
5. htmlフロントエンドのdivブロックのコンテンツが表示され、ユニファイドインターフェイスプラットフォームAPIインターフェイスを要求することにより、ユニファイドインターフェイスプラットフォームが特定のjavaビジネスプラットフォームAPIインターフェイス（マイクロサービス）を要求し、APIネットワーク管理がインターセプトし、トークンがredisに存在し、合法であるかどうかを確認し、合法的にリリースされているかどうかを確認します。 、特定のマイクロサービスへの特定のデータを取得するためのクライアントの負荷分散を通じて、htmlフロントエンドに戻って表示します。