前言

現在越來越多的網際網路公司還是將自己公司的專案進行服務化，這確實是今後專案開發的一個趨勢，就這個點再憑藉之前的SSM專案來讓第一次接觸的同學能快速上手。

淺談分散式架構

分散式架構單看這個名字給人的感覺就是高逼格，但其實從歷史的角度來分析一下就比較明瞭了。

我們拿一個電商系統來說：

單系統

對於一個剛起步的創業公司專案肯定是追求越快完成功能越好，並且使用者量也不大。

這時候所有的業務邏輯都是在一個專案中就可以滿足。

垂直拆分-多應用

當業務量和使用者量發展到一定地步的時候，這時一般會將應用同時部署到幾臺伺服器上，在使用者訪問的時候使用Nginx進行反向代理和簡單的負載均衡。

SOA服務化

當整個系統以及發展的足夠大的時候，比如一個電商系統中存在有：

• 使用者系統
• 訂單系統
• 支付系統
• 物流系統

等系統。
如果每次修改了其中一個系統就要重新發布上線的話那麼耦合就太嚴重了。

所以需要將整個專案拆分成若干個獨立的應用，可以進行獨立的開發上線實現快速迭代。

如上圖所示每個應用之間相互獨立,每個應用可以消費其他應用暴露出來的服務，同時也對外提供服務。

從架構的層面簡單的理解了，接下來看看如何編碼實現。

基於dubbo的實現

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相關的配置檔案了。

spring-dubbo-config.xml

    <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地址，以及服務名稱、超時時間等配置。

spring-dubbo-provider.xml

<dubbo:annotation package="com.crossoverJie.api.impl" />複製程式碼

這個配置掃描註解包的位置，一般配置到介面實現包即可。

spring-dubbo-consumer.xml

這個是消費者配置項，表明我們需要依賴的其他應用。
這裡我們在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。

登陸介面如下圖：

其中我們可以看到有兩個服務以及註冊上去了，但是沒有消費者。

消費服務

為了能夠更直觀的體驗到消費服務，我新建了一個專案：
github.com/crossoverJi…。

其中在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。

以上就是我理解的，如有差錯歡迎指正。

專案地址：github.com/crossoverJi…

個人部落格地址：crossoverjie.top。

GitHub地址：github.com/crossoverJi…。