***
10625 ワード
前言:1年以上の学習を経て、これまで携帯電話/手帳に記録されていたメモをここでまとめ、振り返り、まとめます.
プロジェクトはdubooxの各依存パッケージバージョンを採用
dubooバージョン2.8.4
duboo統合springバージョン3.2.9
プライマリエンジニアリングpomファイルでdubbo-parentに依存
その他の依存バージョンは次のとおりです.
redis/mybatis/activemq/zookeeper/log 4 j/spirngなどのミドルウェア、ベースフレームワークを含むバージョン.
わあ、このCSDNの改版のテキストエディタはまったく使いません...改行して长い间、使って卵が砕けます.
PS:【今dubbo公式サイトがメンテナンスを再開し、その中のいくつかの穴を修復し、最新のspirng 4などのフレームワークをサポートしてアップグレードし、新しいバージョンを使用したい学生は最新バージョンを使用することができます.】
エンジニアリング構造
このパターン形成過程
最初は1つのparentしかなく、すべての依存パッケージバージョンとサービスmoduleを管理していました.大体以下の通りです.
このような結果は非常に惨めで、共同開発の際にこのファイルを修正し、各サービスを追加削除しなければならない.サービス依存のサードパーティ製パッケージのバージョンが異なるため、
親プロジェクト、または自分のプロジェクトの依存項目を変更しようとします.その後、サービスが多すぎて、このmoduleノードを維持するのは非常に難しいです.従来のディレクトリ構造を採用しています.
プロジェクトの作成
親parent pomエンジニアリング、公共依存.
トラフィックラインparent pomエンジニアリング、サービスラインの共通依存.
サービスpom jarエンジニアリング、サービス自体の依存.
大まかな構築過程は、ネット上の多くの入門と同じであり、これ以上説明しない.
【このようにして作られたメリットは、メンテナンスが容易であることです】
【dubooの両方のパケットAPI共有モデルについては、最初は接触が深くなかったため、最終的には双方のパケットバージョンを共有倉庫に置く方法ではなく、サービス側からapiとモデルをコピーして呼び出し、実際には多くの問題を誘発する可能性がある】
開発プロセス
開発プロセスでは、与えられたテンプレートに従ってdubooはsrc/main/resourcesの下のxmlファイルを遍歴するので、最終的なサービスディレクトリ構造は大体以下の通りです.
開発において注意すべき点
beanの注入についてはxml注入ではなく注釈方式を採用しているので、それぞれメリットがあるでしょう.
注釈実装:コードを見るのが便利で、一目瞭然です.
インタフェースパッケージ名:com.hesiyuan.業務名.サービス名.apiをインタフェースとして明記
実装パッケージ名:com.hesiyuan.業務名.サービス名.api.impl クラス名xxxServiceImpl@Service(「サービス名」)注記を採用
xml実装:注入されたbeanを削除してクラスに注入するかどうかを制御できます.すべてのbeanがxmlで表示できるなどのメリットがあります(実際の生産では、xmlで新旧バージョンのbeanを注入して有効にするかどうかを制御する必要はありません.面倒になります).
消費者側xml構成
サービス側xml構成
登録センターの構成
duboo spirng boot, , , spring boot,duboo rpc , rpc , spring boot 、 、 , 。
duboo , , , , 。( QQ ,CSDN !, , , )
プロジェクトはdubooxの各依存パッケージバージョンを採用
dubooバージョン2.8.4
duboo統合springバージョン3.2.9
プライマリエンジニアリングpomファイルでdubbo-parentに依存
com.alibaba
dubbo-parent
2.8.4
その他の依存バージョンは次のとおりです.
redis/mybatis/activemq/zookeeper/log 4 j/spirngなどのミドルウェア、ベースフレームワークを含むバージョン.
UTF-8
UTF-8
UTF-8
1.8
1.8
1.8
2.8.4
3.4.6
0.1
4.12
1.3
1.10.19
1.16.0
3.4.2
1.3.1
5.1.41
8.0.41
20160810
2.3
1.8.9
5.14.4
3.2.9.RELEASE
2.0
2.2.3
1.1.0.Final
5.4.1.Final
3.0.0
わあ、このCSDNの改版のテキストエディタはまったく使いません...改行して长い间、使って卵が砕けます.
PS:【今dubbo公式サイトがメンテナンスを再開し、その中のいくつかの穴を修復し、最新のspirng 4などのフレームワークをサポートしてアップグレードし、新しいバージョンを使用したい学生は最新バージョンを使用することができます.】
エンジニアリング構造
---xxx-parent
----service1-parent
-----service1-module1
----src
----pom
-----service1-module2
----src
----pom
-----service1-module3
----src
----pom // + base
-----service1-module-base
----src
----pom // base
-----pom
-------service2-parent
-----service2-module1
-----service2-module2
-----service2-module-base
-----pom
-------service3-parent
-----service3-module1
-----pom //
-------pom.xml // :log4j、json、spring、duboo 。
このパターン形成過程
最初は1つのparentしかなく、すべての依存パッケージバージョンとサービスmoduleを管理していました.大体以下の通りです.
-base
1- 1
1- 2
.......
......
2- 1
2- 3
.......
........
13- 1
........
このような結果は非常に惨めで、共同開発の際にこのファイルを修正し、各サービスを追加削除しなければならない.サービス依存のサードパーティ製パッケージのバージョンが異なるため、
親プロジェクト、または自分のプロジェクトの依存項目を変更しようとします.その後、サービスが多すぎて、このmoduleノードを維持するのは非常に難しいです.従来のディレクトリ構造を採用しています.
プロジェクトの作成
親parent pomエンジニアリング、公共依存.
トラフィックラインparent pomエンジニアリング、サービスラインの共通依存.
サービスpom jarエンジニアリング、サービス自体の依存.
大まかな構築過程は、ネット上の多くの入門と同じであり、これ以上説明しない.
【このようにして作られたメリットは、メンテナンスが容易であることです】
【dubooの両方のパケットAPI共有モデルについては、最初は接触が深くなかったため、最終的には双方のパケットバージョンを共有倉庫に置く方法ではなく、サービス側からapiとモデルをコピーして呼び出し、実際には多くの問題を誘発する可能性がある】
開発プロセス
開発プロセスでは、与えられたテンプレートに従ってdubooはsrc/main/resourcesの下のxmlファイルを遍歴するので、最終的なサービスディレクトリ構造は大体以下の通りです.
----service1-module1
----src
----main
----java
----com
----....//package java
----resources
----mybatis
config.xml
mapper.xml
----META-INF
----spring
mq.xml
redis.xml
application-context.xml
dubbo-consumer.xml
duboo-provider.xml
application.properites
xxx.properites
jdbc.properites
log4j2.xml
.........//
pom // pom
開発において注意すべき点
beanの注入についてはxml注入ではなく注釈方式を採用しているので、それぞれメリットがあるでしょう.
注釈実装:コードを見るのが便利で、一目瞭然です.
インタフェースパッケージ名:com.hesiyuan.業務名.サービス名.apiをインタフェースとして明記
実装パッケージ名:com.hesiyuan.業務名.サービス名.api.impl クラス名xxxServiceImpl@Service(「サービス名」)注記を採用
xml実装:注入されたbeanを削除してクラスに注入するかどうかを制御できます.すべてのbeanがxmlで表示できるなどのメリットがあります(実際の生産では、xmlで新旧バージョンのbeanを注入して有効にするかどうかを制御する必要はありません.面倒になります).
消費者側xml構成
, 。
1.connections // 。 TCP 1
2.check // zookeeper , flase
3.id @service
4.retries
5. scope
サービス側xml構成
, 。
1. name duboo dubbox rest
2. port
3. 200
4. version 0.0.1 1.2.11
5. timeout , , ( ☺)
6. ref bean
7. executes // ... , , , 2.8 duboo 。 dubbo 。
登録センターの構成