如今愈來愈多的互聯網公司仍是將本身公司的項目進行服務化,這確實是從此項目開發的一個趨勢,就這個點再憑藉以前的SSM
項目來讓第一次接觸的同窗能快速上手。java
分佈式架構
單看這個名字給人的感受就是高逼格,但其實從歷史的角度來分析一下就比較明瞭了。git
咱們拿一個電商系統來講:github
對於一個剛起步的創業公司項目確定是追求越快完成功能越好,而且用戶量也不大。spring
這時候全部的業務邏輯都是在一個項目中就能夠知足。api
當業務量和用戶量發展到必定地步的時候,這時通常會將應用同時部署到幾臺服務器上,在用戶訪問的時候使用
Nginx
進行反向代理和簡單的負載均衡。服務器
當整個系統以及發展的足夠大的時候,好比一個電商系統中存在有:mybatis
等系統。 若是每次修改了其中一個系統就要從新發布上線的話那麼耦合就太嚴重了。架構
因此須要將整個項目拆分紅若干個獨立的應用,能夠進行獨立的開發上線實現快速迭代。app
如上圖所示每一個應用之間相互獨立,每一個應用能夠消費其餘應用暴露出來的服務,同時也對外提供服務。負載均衡
從架構的層面簡單的理解了,接下來看看如何編碼實現。
dubbo
應該算是國內使用最多的分佈式服務框架,基於此來實現對新入門的同窗應該頗有幫助。
其中有涉及到安裝dubbo服務的註冊中心zookeeper等相關知識點能夠自行查看官方文檔,這裏就不單獨講了。
首先第一步須要在SSM-API
模塊中定義一個接口,這裏就搞了一個用戶查詢的接口
/** * Function:用戶API * @author chenjiec * Date: 2017/4/4 下午9:46 * @since JDK 1.7 */ public interface UserInfoApi { /** * 獲取用戶信息 * @param userId * @return * @throws Exception */ public UserInfoRsp getUserInfo(int userId) throws Exception; }
接着在SSM-SERVICE
模塊中進行實現:
import com.alibaba.dubbo.config.annotation.Service; /** * Function: * @author chenjiec * Date: 2017/4/4 下午9:51 * @since JDK 1.7 */ @Service public class UserInfoApiImpl implements UserInfoApi { private static Logger logger = LoggerFactory.getLogger(UserInfoApiImpl.class); @Autowired private T_userService t_userService ; /** * 獲取用戶信息 * * @param userId * @return * @throws Exception */ @Override public UserInfoRsp getUserInfo(int userId) throws Exception { logger.info("用戶查詢Id="+userId); //返回對象 UserInfoRsp userInfoRsp = new UserInfoRsp() ; T_user t_user = t_userService.selectByPrimaryKey(userId) ; //構建 buildUserInfoRsp(userInfoRsp,t_user) ; return userInfoRsp; } /** * 構建返回 * @param userInfoRsp * @param t_user */ private void buildUserInfoRsp(UserInfoRsp userInfoRsp, T_user t_user) { if (t_user == null){ t_user = new T_user() ; } CommonUtil.setLogValueModelToModel(t_user,userInfoRsp); } }
這些都是通用的代碼,但值得注意的一點是這裏使用的dubbo
框架所提供的@service
註解。做用是聲明須要暴露的服務接口。
再以後就是幾個dubbo相關的配置文件了。
<dubbo:application name="ssm-service" owner="crossoverJie" organization="ssm-crossoverJie" logger="slf4j"/> <dubbo:registry id="dubbo-registry" address="zookeeper://192.168.0.188:2181" file="/tmp/dubbo.cachr" /> <dubbo:monitor protocol="registry" /> <dubbo:protocol name="dubbo" port="20880" /> <dubbo:provider timeout="15000" retries="0" delay="-1" /> <dubbo:consumer check="false" timeout="15000" />
其實就是配置咱們服務註冊的zk地址,以及服務名稱、超時時間等配置。
<dubbo:annotation package="com.crossoverJie.api.impl" />
這個配置掃描註解包的位置,通常配置到接口實現包便可。
這個是消費者配置項,代表咱們須要依賴的其餘應用。 這裏咱們在SSM-BOOT
項目中進行配置:
<dubbo:reference id="userInfoApi" interface="com.crossoverJie.api.UserInfoApi" />
直接就是配置的剛纔咱們提供的那個用戶查詢的接口,這樣當咱們本身的內部項目須要使用到這個服務只須要依賴SSM-BOOT
便可,不須要單獨的再去配置consumer
。這個我有在上一篇SSM(十) 項目重構-互聯網項目的Maven結構中也有提到。
還有一個須要作的就是安裝管理控制檯,這裏能夠看到咱們有多少服務、調用狀況是怎麼樣等做用。
這裏咱們能夠將dubbo的官方源碼下載下來,對其中的dubbo-admin
模塊進行打包,將生成的WAR包
放到Tomcat
中運行起來便可。
可是須要注意一點的是: 須要將其中的dubbo.properties
的zk地址修改成本身的便可。
dubbo.registry.address=zookeeper://127.0.0.1:2181 dubbo.admin.root.password=root dubbo.admin.guest.password=guest
到時候登錄的話使用root,密碼也是root。 使用guest,密碼也是guest。
登錄界面以下圖:
其中咱們能夠看到有兩個服務以及註冊上去了,可是沒有消費者。
爲了可以更直觀的體驗到消費服務,我新建了一個項目: https://github.com/crossoverJie/SSM-CONSUMER。
其中在SSM-CONSUMER-API
中我也定義了一個接口:
/** * Function:薪資API * @author chenjiec * Date: 2017/4/4 下午9:46 * @since JDK 1.7 */ public interface SalaryInfoApi { /** * 獲取薪資 * @param userId * @return * @throws Exception */ public SalaryInfoRsp getSalaryInfo(int userId) throws Exception; }
由於做爲消費者的同時咱們也對外提供了一個獲取薪資的一個服務。
在SSM-CONSUMER-SERVICE
模塊中進行了實現:
/** * Function: * @author chenjiec * Date: 2017/4/4 下午9:51 * @since JDK 1.7 */ @Service public class SalaryInfoApiImpl implements SalaryInfoApi { private static Logger logger = LoggerFactory.getLogger(SalaryInfoApiImpl.class); @Autowired UserInfoApi userInfoApi ; /** * 獲取用戶信息 * * @param userId * @return * @throws Exception */ @Override public SalaryInfoRsp getSalaryInfo(int userId) throws Exception { logger.info("薪資查詢Id="+userId); //返回對象 SalaryInfoRsp salaryInfoRsp = new SalaryInfoRsp() ; //調用遠程服務 UserInfoRsp userInfo = userInfoApi.getUserInfo(userId); salaryInfoRsp.setUsername(userInfo.getUserName()); return salaryInfoRsp; } }
其中就能夠直接使用userInfoApi
調用以前的我的信息服務。
再調用以前須要注意的有點是,咱們只須要依賴SSM-BOOT
這個模塊便可進行調用,由於SSM-BOOT
模塊已經爲咱們配置了消費者之類的操做了:
<dependency> <groupId>com.crossoverJie</groupId> <artifactId>SSM-BOOT</artifactId> </dependency>
還有一點是在配置SSM-BOOT
中的spring-dubbo-cosumer.xml
配置文件的時候,路徑要和咱們初始化spring配置文件時的路徑一致:
<!-- Spring和mybatis的配置文件 --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath*:spring/*.xml</param-value> </context-param>
接下來跑個單測試一下可否調通:
/** * Function: * * @author chenjiec * Date: 2017/4/5 下午10:41 * @since JDK 1.7 */ @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = { "classpath*:/spring/*.xml" }) public class SalaryInfoApiImplTest { @Autowired private SalaryInfoApi salaryInfoApi ; @Test public void getSalaryInfo() throws Exception { SalaryInfoRsp salaryInfo = salaryInfoApi.getSalaryInfo(1); System.out.println(JSON.toJSONString(salaryInfo)); } }
消費者
提供者 能夠看到確實是調用成功了的。
接下來將消費者項目也同時啓動在來觀察管理控制檯有什麼不同: 會看到多了一個消費者所提供的服務
com.crossoverjie.consumer.api.SalaryInfoApi
,同時 com.crossoverJie.api.UserInfoApi
服務已經正常,說明已經有消費者了。
點進去即可查看具體的消費者。
這樣一個基於dubbo的分佈式服務已經講的差很少了,在實際的開發中咱們便會開發一個大系統中的某一個子應用,這樣就算一個子應用出問題了也不會影響到整個大的項目。
再提一點: 在實際的生產環境通常同一個服務咱們都會有一個master
,slave
的主從服務,這樣在上線的過程當中不至於整個應用出現沒法使用的尷尬狀況。
談到了SOA
的好處,那麼天然也有相對於傳統模式的不方便之處:
Jenkins
。elk
。以上就是我理解的,若有差錯歡迎指正。
我的博客地址:http://crossoverjie.top。
GitHub地址:https://github.com/crossoverJie。