Spring の 2 つのコアが IoC (制御の反転) と AOP (アスペクト指向プログラミング) であることは誰もが知っています。また、現在のマイクロサービス時代における springCloud、springBoot、および spring の関係について、この記事では主に詳しく説明したいと思います。これら 2 つの関係について私の問題の理解に間違いがある場合は修正してください。
1. SpringCloud、SpringBoot、Springの関係
Spring と SpringBoot の関係
簡単に言うと、SpringBoot は Spring フレームワークをベースにしており、Spring のアップグレード版です Spring と比較した SpringBoot の利点は、Maven の依存関係が簡素化されること、本来 xml が必要な構成が設定できることです。アノテーションを使用して、再カプセル化し、複雑な構成と実装の原則をシールドすることにより、最終的には、理解しやすく、展開し、保守しやすい一連の分散システム開発ツールキットを開発者に提供します。
Spring Boot は Spring に代わるものではなく、Spring をより簡単に使用できるようにするために発明されました。
SpringBoot と SpringCloud の関係
Spring Cloud は、一連のフレームワークの順序付けられたコレクションであり、Spring Boot の開発上の利便性を利用して、分散システム インフラストラクチャの開発を巧みに簡素化します。Spring Boot 開発スタイルを使用すると、サービス ディスカバリの登録、構成センター、メッセージ バス、ロード バランシング、サーキット ブレーカー、データ モニタリングなどをすべてワンクリックで開始およびデプロイできます。Spring Cloudは、Spring Bootをベースに開発されたマイクロサービスアーキテクチャによるサービスガバナンスソリューションです。
一般に、SpringCloud は SpringBoot に基づいており、SpringBoot は Spring に基づいています。
2. Spring の 2 つのコアは、IoC (制御の反転) と AOP (アスペクト指向プログラミング) です。
Spring の 2 つのコアはさておき、初めて Java を学ぶときは、当然次のようなコードを書かなければなりません。
いくつかのロジックを ServiceB にカプセル化します。ServiceA がこれらのロジックを使用する必要がある場合、ServiceA 内に新しい ServiceB が作成されます。
ServiceB によってカプセル化されたロジックが非常に一般的な場合、それに依存する必要がある ServiceC...ServiceF なども存在するため、コード内のあらゆる場所で新しい ServiceB が必要になることになります。変更した場合は、すべての場所でそれを使用する必要があるため、その場所に移動してコードを変更します。
たとえば、ServiceB インスタンスの作成には ServiceC が必要なため、コードは次のように変更されます。
確かにこの問題はあります。
しかし、実際には、共通のサービス ロジックをカプセル化すると、毎回新しいインスタンスを作成する必要はなくなります。言い換えれば、単一のインスタンスで十分です。私たちのシステムは、使用するオブジェクトごとに新しい ServiceB を必要とするだけで、この問題を解決できます。 。
問題は解決されたように見えますが、そうではありません。
大学の大規模な課題など、プロジェクトが比較的小規模な場合、上記の操作は実際には大きな問題にはなりませんが、エンタープライズレベルのアプリケーションとなると複雑になります。
多くのロジックが関係しているため、多くのカプセル化されたサービス クラスがあり、それらの間の依存関係も複雑です。コード内には ServiceB1、ServiceB2...ServiceB100 があり、相互に依存関係がある可能性があります。
依存関係に関係なく、ServiceB の単純なシングルトン ロジック コードを考えてみましょう。繰り返されるロジックは、数百または数千のコピーを作成する必要がある場合があります。
また拡張も容易ではなく、以前はServiceBの動作にトランザクションが必要なかったかもしれませんが、今後はトランザクションが必要になるため、ServiceBのコードを変更してトランザクション関連のロジックを組み込む必要があります。
その後間もなく、ServiceC にもトランザクションが必要になり、トランザクションに関するまったく同じコードを ServiceC と D、E、F... で繰り返す必要がありました。
いくつかの Service トランザクションは要件が異なりますし、トランザクションが入れ子になっているという問題もあり、一言で言えば少々面倒です。
ここしばらくトランザクション要件を満たすために忙しく、オンラインにアクセスしましたが、コードを繰り返す悪夢からようやく解放され、ゆっくり休めると思いました。
オンラインの問題のトラブルシューティングが必要になることが多いため、トラブルシューティングを容易にするためにインターフェイスの入力パラメータをログに記録する必要があり、大幅な変更を一度に行う必要があります。
必要に応じて変更を加えるのは通常のことですが、各変更には多くの反復作業が必要であり、面倒で、技術的な内容がなく、見落としがちです。これは十分エレガントではありません。
1.IOC (制御の反転);
したがって、このように実装したいと思います。ServiceB に依存する ServiceA のみを考慮しますが、ServiceB がどのように生成されるかは考慮しません。その「もの」は、ServiceB の生成と ServiceA と ServiceB の関連付けに役立ちます。
この「もの」とは、Spring によって管理されるオブジェクト コードとそれらの XML ファイル (または @Configuration でマークされたクラス) です。
現在のロジックは、ServiceA が具体的にどの ServiceB に依存しているかということです。ServiceB を作成する方法に関する完全なロジックをコード内で明示的に記述する必要はありません。構成ファイルを記述するだけでよく、Spring が特定の部分を支援します。創造と関連付け。
Spring でのデータベース構成の例を見てみましょう。
図面が非常に明確に記述されていることがわかります。mybatis を作成する MapperScannerConfigurer は、2 つのプロパティの値をそれに伝える必要があります。たとえば、最初のプロパティは sqlSessionFactoryBeanName で、その値は sqlSessionFactory です。
sqlSessionFactory は dataSource に依存しており、dataSource は driverClassName、url などで構成する必要があります。
したがって、実際には、ServiceA (Bean) を作成するために何が必要かはよくわかっていますが、作成プロセスは Spring によって処理されるため、それを明確に伝えるだけで済みます。
したがって、Spring を使用した後は、ServiceA がどの ServiceB に依存するか、ServiceB がどのように正常に作成されるかが気にならなくなるわけではなく、Spring がこれらのオブジェクトを組み立てるプロセスを支援してくれることを意味します。
Spring に伝えるために正しい描画を描画する必要があるため、オブジェクトがどのように作成されるかを明確に知る必要があります。
Spring は実際には、与えられた図面に基づいて使用する関連オブジェクトを自動的に作成するマシンであり、完全な作成コードをコード内に明示的に記述する必要はありません。
Spring によって作成されるこれらのオブジェクト インスタンスは Bean と呼ばれます。
これらの Bean を使用したい場合は、Spring から取得できます。Spring は、作成されたこれらのシングルトン Bean をマップに配置し、名前またはタイプでこれらの Bean を取得できます。
これがIOCです。
ps: SpringBoot にはこの種の XML 構成があまりなく、基本的にアノテーションまたはその他のメソッドが使用されるため、Spring の Bean の XML 構成メソッドは初心者が IOC を理解するのに役立ちます。
ps: SpringBoot にはこの種の XML 構成があまりなく、基本的にアノテーションまたはその他のメソッドが使用されるため、初心者にとって IOC を理解するには Spring の Bean の XML 構成メソッドの方が役立ちます。
2.AOP (アスペクト指向プログラミング);
これらの Bean は、コードの隅々で遅延して作成するのではなく、Spring マシンによって作成する必要があるため、この統一されたインターフェイスに基づいて多くのことを簡単に行うことができます。
たとえば、ServiceB に @Transactional アノテーションが付けられている場合、Spring はこのアノテーションを解析して、ServiceB にトランザクションが必要であることを理解できるため、トランザクションのオープン、送信、ロールバックなどの操作が ServiceB に組み込まれています。
@Transactional アノテーションが付いているものはすべて自動的にトランザクション ロジックを追加するため、反復的なコードが大幅に削減されます。トランザクションを必要とするメソッドまたはクラスに @Transactional アノテーションを追加する限り、Spring はトランザクション機能を補完するのに役立ちます。すべての操作は Spring までに完了します。
別の例として、すべてのコントローラーのリクエスト入力パラメーターを記録する必要があります。これも非常に簡単です。xxx パス (コントローラー パッケージ パス) にあるクラスの各メソッドの入力パラメーターを Spring に伝える設定を記述するだけです。 ) をログに記録する必要があり、ログ出力ロジック コードも記述します。
Spring はこの設定を解析した後にこのコマンドを取得したので、後続の Bean を作成するときに、そのパッケージが上記の設定に準拠しているかどうかを確認し、準拠している場合はログ出力ロジックを追加し、元のロジックと織り合わせます。 。
このようにして、繰り返されるログ出力アクションの操作が構成に抽象化され、Spring マシンがその構成を認識した後、コマンドを実行してこれらの繰り返されるアクションを完了します。
私たちは Spring の起源と中心となる概念をある程度理解しており、上記の機能に基づいてできることはたくさんあります。Spring の統一されたクローズ処理により、設定ファイルの解析時、Bean の初期化前後、Bean インスタンス化の前後など、さまざまなタイミングで柔軟に多くの拡張ポイントを提供できます。したがって、Spring Family Bucket を使用する必要があります。これが提供する拡張機能とカプセル化は、多くのニーズに柔軟に対応でき、これらの柔軟性は Spring のコア IOC と AOP に基づいています。
ps: 興味のある方は、Spring Family Bucket について学ぶことができます。
Spring の原理を簡単に説明します。Spring
は、提供された構成クラスと XML 構成ファイルに従ってコンテンツを解析し、管理する必要がある Bean とそれらの間の関係の情報を取得します。また、Spring は、多くの拡張ポイントを公開します。 BeanFactoryPostProcessor、BeanPostProcessor など、カスタマイズされた操作を実行するには、このインターフェイスを実装するだけで済みます。
Spring が Bean 情報を取得した後、リフレクションに基づいて Bean インスタンスを作成し、Bean 間の依存関係をアセンブルし、ネイティブまたは定義された関連する PostProcessor を散在させて、Bean を変換したり、一部の属性を置き換えたり、元の Bean ロジックをプロキシしたりします。
最後に、構成要件を持つすべての Bean が作成された後、シングルトン Bean がマップに保管され、Bean を取得して使用するための BeanFactory が提供されます。
これにより、コーディング プロセス中に Bean がどのように作成されるかに注意を払う必要がなくなり、多くの反復的なコーディング アクションも節約されます。これらはすべて、私たちが作成したマシンである Spring によって行われます。