Spring IOC
IOCRPCとは？
IOCコンテナの初期化プロセスは次のようになります。
Springが起動すると、refreshメソッドによってコンテナの初期化とBeanの作成が完了します。
- prepareRefreshは、コンテキストの状態と時刻、およびプロパティ
- containFreshBeanFactory は、ビーン・ファクトリーを初期化し、既存のものを破棄して再作成します。
- prepareBeanFactoryにBeanFactory用のクラス・ローダー、式パーサー、自動アセンブリ、およびその他の構成を追加します。
- registerBeanPostProcessor registerBeanPostProcessor
- onRefreshは、サブクラスが実装するために提供されるロジックです。
- registerListeners メソッドはすべてのリスナーを検索し、7.のブロードキャスターに登録します。
- finishRefresh は、キャッシュのクリア、イベントの投稿など、その他のタスクを完了し、IOC コンテナの初期化を終了します。
ビーンズのライフサイクルと範囲について簡単に説明します。
InitialisingBeanとは？
1つはInitializingBeanインターフェイスを実装し、afterPropertiesSetメソッドを実装する方法、もう1つは設定ファイルでinitメソッドを指定する方法です。
{% fold この2つの違いは何ですか？ %}
InitializingBeanインターフェイスを実装するには、afterPropertiesSetメソッドを直接呼び出します。これは、リフレクションを介してinit-methodメソッドを呼び出すよりも効率的ですが、後者はspringへの依存を排除します。
{% endfold %}
ビーンの範囲はスコープで指定でき、以下の5種類があります：
- シングルトン：単一のインスタンスで、コンテナが同じオブジェクトを返すたびに、IOCコンテナの初期化で
- プロトタイプ：複数のインスタンス、毎回新しく作成されたインスタンスを返します。
- Request: HttpRequest に対してのみ動作し、各 Http リクエストで
- セッション: HttpSession でのみ動作します。
- グローバルセッション：すべてのHttpSessionが同じインスタンスを使用します。
BeanFactoryとFactoryBean、ApplicationContextの違い
BeanFactoryは、BeanのIOCコンテナ、オブジェクトファクトリを管理するために使用されるファクトリインタフェースは、BeanFactoryのインスタンス化は、自動的にBeanをインスタンス化せず、Beanがインスタンス化し、依存関係をアセンブルするために使用される場合にのみ、遅延ロードの使用は、マルチケースモデルに適しています。FactoryBeanは、Beanインタフェースをインスタンス化する方法をカスタマイズするコードを記述する方法は、従来の方法xml /プロパティアノテーションは、FactoryBeanを実装することにより、getObjectメソッドの操作を簡素化するために多くの構成が必要になることがあります。FactoryBeanは、コードを書くことによってBeanのインスタンス化をカスタマイズするために使用されるインタフェースです。 従来のxml/プロパティアノテーションアプローチでは、FactoryBeanを実装することによってこの操作を簡素化するために多くの構成が必要になる可能性があり、カスタムインスタンス化ロジックはgetObjectメソッドで実装されます; ApplicationContextは、即時ロードを使用するように拡張されたBeanFactoryのサブインタフェースです。即時ロードを使用するように拡張され、シングルトンモードに適しています。
AOPRPCとは？
AOPは、カッター指向プログラミングは、特定のビジネスは、特定のオブジェクトとは何の関係もない、一般的な機能コードは、特定の時点で実行する必要がある、ビジネスの機能コードとカッターコードを分離し、完全なビジネスにマージされます。一般的に使用されるシナリオは、許可認証、自動キャッシュ、エラー処理、ロギング、デバッグ、トランザクションが含まれます。
編み込みには3つの方法があります：
- コンパイル時のウィービング： AspectJのような特別なJavaコンパイラを必要とします。
- クラスロード時のウィービング： AspectJやAspectWerkzのような特別なコンパイラが必要です。
- ランタイム・ウィービング：ダイナミック・プロキシによって
applicationContext.getBean("name");SpringでのAOPの使用：依存関係のインポート、ファセット@Aspectの作成、エントリポイントメソッドの定義、タイミングアドバイスの定義、メソッド内での必要なロジックの実装。
Beanのポストプロセッサを介してSpringAOPは、プロキシにラップされ、呼び出しにプロキシを介して呼び出すには、実装する2つの方法があります、クラスがインターフェイスを実装している場合は、JDKの動的プロキシを使用し、それ以外の場合は、CGLibの動的プロキシを使用します。
JDKダイナミックプロキシ
プロキシされるクラスはビジネス・メソッドを含むインタフェースを実装する必要があり、プロキシ・クラスは特定のビジネス・メソッドを呼び出す InvocationHandler invoke メソッドを実装する必要があり、最後に Proxy.newInstance によってプロキシ・クラスを生成します。生成されたプロキシ・クラスをクラス・ローダでロードします。
Spring AOPでは、生成されたProxyクラスは、インターフェイスのすべてのメソッドが実際のクラスで実装されています。Proxyのバイトコードからわかるように、privateなstaticメンバ変数Method 01234が宣言されています。メソッドは静的コードブロックを通してリフレクションを使って初期化されます。特定のメソッドは、ProxyクラスのInvocationHandlerメンバ変数のinvokeメソッドを通して呼び出されます。invokeは、特定のメソッドの呼び出しの前後にカットイン・ロジックを持ちます。
{% fold コードを展開 %}
//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//
import aop.UserService;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.lang.reflect.UndeclaredThrowableException;
public final class $Proxy11 extends Proxy implements UserService {
private static Method m1;
private static Method m4;
private static Method m3;
private static Method m2;
private static Method m0;
public $Proxy11(InvocationHandler var1) throws {
super(var1);
}
public final boolean equals(Object var1) throws {
try {
return (Boolean)super.h.invoke(this, m1, new Object[]{var1});
} catch (RuntimeException | Error var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
public final void A() throws {
try {
super.h.invoke(this, m4, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
public final void B() throws {
try {
super.h.invoke(this, m3, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
public final String toString() throws {
try {
return (String)super.h.invoke(this, m2, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
public final int hashCode() throws {
try {
return (Integer)super.h.invoke(this, m0, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
static {
try {
m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
m4 = Class.forName("aop.UserService").getMethod("A");
m3 = Class.forName("aop.UserService").getMethod("B");
m2 = Class.forName("java.lang.Object").getMethod("toString");
m0 = Class.forName("java.lang.Object").getMethod("hashCode");
} catch (NoSuchMethodException var2) {
throw new NoSuchMethodError(var2.getMessage());
} catch (ClassNotFoundException var3) {
throw new NoClassDefFoundError(var3.getMessage());
}
}
}
{% endfold %}
CGLIBダイナミックプロキシ
cglibは、スーパーを介した実クラスからの継承を使用して、実クラスのメソッドを呼び出したり、新しいロジックを追加したりするためです。
Spring MVCのコアコンポーネントは何ですか？
SpringMVCはMVCデザインモデルに基づいたリクエスト駆動型の軽量なWEBフレームワークで、WEBアプリケーションのアーキテクチャはビュー層View、プロセッサ層Controller、永続層Modelに分かれています。
- DispatcherServlet: リクエストを受け付け、対応する処理コンポーネントに転送するフロントエンドコントローラー。
- ハンドラー：特定のビジネスロジックを完成させるプロセッサーで、サーブレットやアクションに似ています。
- HandlerInterceptor: インターセプター。このインターフェースの実装を通して、インターセプト処理を完了します。
- HandlerAdapterは：アダプタは、ハンドラの実行処理のビジネスメソッドは、フォームデータの検証、データ型の変換、JavaBeanや他の操作にカプセル化を完了する必要が、別のハンドラのアダプタの実行を介して、アダプタによって完了します。アダプタパターンのアプリケーション
- ViewResolver：ビューリゾルバ、DispatcherServletは、リゾルバを通して論理ビューを物理ビューに変換し、最後にレンダリング結果をクライアントに返します。
Spring Data JPAとMy Batisの違い？
両方は、ORMのオブジェクトリレーショナルマッピングフレームワークは、JavaBeanオブジェクトは、リレーショナルデータベースにマッピングされ、エンティティクラスの操作を介してデータベースのテーブルを操作する。 JDKの動的エージェントを介して実行時にSpring DataのJPAは、プロキシオブジェクトSimpleJpaRepositoryを作成するために、hibernateを介してデータベース操作を完了します。Batisは、半自動ORMフレームワーク、XMLとJavaBeanオブジェクトの使用マッピング関係の生成を通じて、接続され、一方、SQLステートメントを記述する必要が、ResultMapを介してクエリの結果は、Javaオブジェクトにマッピングされます。テーブルの関連付けから、私のBatisは、より柔軟で、JPAは、マルチテーブルの関連クエリを提供していません。
SpringBoot
SpringBootとは何ですか？
SpringBootは、Springのコンポーネントのためのワンストップソリューションは、主にAutoConfigureを通じて、構成上の慣習の原則に基づいて、Springの難易度の使用を簡素化するために、自動的に構成され、特別なニーズがあるときにのみ、独自の設定が必要な場合は、プロジェクトに他のフレームワークを統合するために、より便利なスターターの様々な提供しています。
- 簡単に始められ、より効率的に開発でき、煩雑な設定から解放されます。
- 組込みサーバ、セキュリティ管理、運用データ監視、運用状況確認、外部設定など、大規模プロジェクトに共通する一連の非業務機能を提供します。
- 多くのMavenインポートや様々なバージョンの競合を回避
SpringBootのコアアノテーション？
SpringBootの先発をご存知ですか？
スターターは、プロジェクトのフレームワークの他のコンポーネントを統合する必要があるときに方法の迅速な統合は、スターターの設定情報の手間を省くことです。スターター/ SpringBootがなければ、すべてのプロジェクトは、redisなどの他のフレームワークを統合する必要が手動で多くの情報を設定する必要がある、SpringBootは、設定上の慣習をプッシュし、スターターは、プロパティ内のコンポーネントの構成にカプセル化され、AutoConfigurationを介してデフォルトの設定をアセンブルします。デフォルトの構成：SpringBootは、自動構成を完了するために起動時にすべてのAutoConfigurationクラスをスキャンします。
SpringBootはどのように自動設定を行うのですか？
AutoConfigurationは@EnableAutoConfigurationというアノテーションによって有効になります。このアノテーションはAutoConfigurationImportSelectorを導入し、そのselectImportsメソッドはMETA-INF/spring.worksファイルから自動設定クラスのパスを読み込み、そのパスにAutoConfigurationImportSelectorを追加します。AutoConfigurationクラスはコンテナに追加され、自动配置类中通过@EnableConfigurationPeoperties引入了对应的配置类xxxProperties.class。クラス内のプロパティはymlファイルを通してカスタム設定することができ、そうでなければデフォルトの設定が使用され、自動設定機能が実装されます。
SpringCloud
サービスガバナンスとは？
サービス登録の発見、監視、オフライン、更新などのためのマイクロサービスの自動管理。
登録センターの原則について教えてください。
エウレカは主に定時タスクとレストコールによってサービスの登録と発見を行い、サービスインスタンスはレジストリに情報を送信し、レジストリは定時タスクによってサービスの状態と情報の更新をチェックします。
登録センターには何が保存されていますか？どのようなデータ構造が使われていますか？
名前、インスタンスID、IPなど、サービスインスタンスに関する情報を格納します。
クライアントサイドの負荷分散とは何ですか？サーバサイドロードバランシングとの違いは？
spring-cloudの分散フレームワークを使うと、同じサービスのインスタンスが複数存在することになります。spring-cloud分散フレームワークのクライアント側の負荷分散は、@LoadBalancedアノテーションを追加するだけで、開発者には透過的です。サーバー側の負荷分散は、分散するサーバーの上流で行われ、一般的なnginxやlvsなど、それぞれ7層と4層の負荷分散があり、url、ip、portを使って負荷分散ポリシーの選択を行うことができます。クライアントロードバランシングとサーバーロードバランシングの違いの核心は、サービスリストそのものにあります。 クライアントロードバランシングのサービスリストはクライアントを通して管理され、サーバーロードバランシングのサービスリストは中間サービスによって別に管理されます。
なぜRibbonはクライアント側の負荷分散を行うのですか？
クライアントのロードバランシングのサービスリストは、クライアントによって維持されます。そのため、クライアントは自身のメモリ内で利用可能なサービスインスタンスを直接取得することができます。
ロードバランシングポリシー
ThreadLocalRandom.current().nextInt(serverCount)ランダム選択 RandomRule: upServerList のランダムインデックスを取得します。- ポーリングRoundRibbonRule: デフォルトでは10回まで。
- RetryRule: ポーリング戦略に基づいて、インスタンスが取得されるまで繰り返し再試行します。
- WeightedResponseTimeRule: すべてのサービスを繰り返し、平均レスポンスタイムの合計を求め、この合計からサービスの平均レスポンスタイムを重みとして引きます。
メルトダウンの意味は？
融合メカニズムは、雪崩効果に対処するためのマイクロサービスリンク保護メカニズムです。マイクロサービスが利用できない場合、または応答時間が長すぎる場合、サービスが低下するため、ノードのマイクロサービスコールを融合し、迅速に "エラー "応答メッセージを返します。ノードマイクロサービスの呼び出し応答が検出されると、呼び出しのリンクを復元します。Hystrixの実装を介してメルトダウン機構でSpringCloudフレームワークでは、Hystrixは、マイクロサービス間のコールの状態を監視します、ときに一定のしきい値にコールの失敗、デフォルトでは、20回呼び出すには5秒です、それが失敗した場合、それはメルトダウン機構を開始します。
サービスの劣化は、一般的に全体的な負荷の観点から考慮されます。つまり、サービスがメルトダウンした後、サーバーはもはや呼び出されません、その時点でクライアントは、デフォルト値を返す、独自のローカルフォールバックコールバックを準備することができます。そうすることで、レベルは低下しますが、少なくとも利用可能で、直接ハングアップするよりも優れています。
分散フレームワーク／分散サービスについてどのように理解していますか？
分散サービスとは、従来のモノリシックなアプリケーションを、ビジネスの観点などから複数のアプリケーションに切り分け、独立して動作させ、外部にサービスを提供することです。異なるサーバーノードに配置されたものを分散サービスと呼びます。フレームワークは、特定の実装のための分散システムを構築する方法を指示するために使用されます。分散フレームワークは、2つの最も重要なコンポーネントは、レジストリとRPCフレームワークです、レジストリは、サービスの状態を維持するため、RPCは、サービス間の通信を実現する責任があります。
