ZooKeeper分布式專題與Dubbo微服務入門

本項目地址

Dubbo入門到重構服務

本文將以原理+實戰的方式，首先對“微服務”相關的概念進行知識點掃盲，然后開始手把手教你搭建這一整套的微服務系統。

微服務

微服務一次近幾年相當火，成為程序猿飯前便后裝逼熱門詞匯，你不對它有所了解如何在程序猿裝逼圈子里混？下面我用最為通俗易懂的語言介紹它。

要講清楚微服務，我先要從一個系統架構的演進過程講起。

單機結構

我想大家最最最熟悉的就是單機結構，一個系統業務量很小的時候所有的代碼都放在一個項目中就好了，然后這個項目部署在一臺服務器上就好了。整個項目所有的服務都由這臺服務器提供。這就是單機結構。 那么，單機結構有啥缺點呢？我想缺點是顯而易見的，單機的處理能力畢竟是有限的，當你的業務增長到一定程度的時候，單機的硬件資源將無法滿足你的業務需求。此時便出現了集群模式，往下接著看。

集群結構

集群模式在程序猿界由各種裝逼解釋，有的讓你根本無法理解，其實就是一個很簡單的玩意兒，且聽我一一道來。

單機處理到達瓶頸的時候，你就把單機復制幾份，這樣就構成了一個“集群”。集群中每臺服務器就叫做這個集群的一個“節點”，所有節點構成了一個集群。每個節點都提供相同的服務，那么這樣系統的處理能力就相當于提升了好幾倍（有幾個節點就相當于提升了這么多倍）。

但問題是用戶的請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均。要實現這個功能，就需要在所有節點之前增加一個“調度者”的角色，用戶的所有請求都先交給它，然后它根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理。這個“調度者”有個牛逼了名字——負載均衡服務器。

集群結構的好處就是系統擴展非常容易。如果隨著你們系統業務的發展，當前的系統又支撐不住了，那么給這個集群再增加節點就行了。但是，當你的業務發展到一定程度的時候，你會發現一個問題——無論怎么增加節點，貌似整個集群性能的提升效果并不明顯了。這時候，你就需要使用微服務結構了。

微服務結構

先來對前面的知識點做個總結。 從單機結構到集群結構，你的代碼基本無需要作任何修改，你要做的僅僅是多部署幾臺服務器，沒太服務器上運行相同的代碼就行了。但是，當你要從集群結構演進到微服務結構的時候，之前的那套代碼就需要發生較大的改動了。所以對于新系統我們建議，系統設計之初就采用微服務架構，這樣后期運維的成本更低。但如果一套老系統需要升級成微服務結構的話，那就得對代碼大動干戈了。所以，對于老系統而言，究竟是繼續保持集群模式，還是升級成微服務架構，這需要你們的架構師深思熟慮、權衡投入產出比。

OK，下面開始介紹所謂的微服務。 微服務就是將一個完整的系統，按照業務功能，拆分成一個個獨立的子系統，在微服務結構中，每個子系統就被稱為“服務”。這些子系統能夠獨立運行在web容器中，它們之間通過RPC方式通信。

舉個例子，假設需要開發一個在線商城。按照微服務的思想，我們需要按照功能模塊拆分成多個獨立的服務，如：用戶服務、產品服務、訂單服務、后臺管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目，可以獨立運行。如果服務之間有依賴關系，那么通過RPC方式調用。

這樣的好處有很多：

1. 系統之間的耦合度大大降低，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界非常明確，排錯也變得相當容易，開發效率大大提升。
2. 系統之間的耦合度降低，從而系統更易于擴展。我們可以針對性地擴展某些服務。假設這個商城要搞一次大促，下單量可能會大大提升，因此我們可以針對性地提升訂單系統、產品系統的節點數量，而對于后臺管理系統、數據分析系統而言，節點數量維持原有水平即可。
3. 服務的復用性更高。比如，當我們將用戶系統作為單獨的服務后，該公司所有的產品都可以使用該系統作為用戶系統，無需重復開發。

那么問題來了，當采用微服務結構后，一個完整的系統可能有很多獨立的子系統組成，當業務量漸漸發展起來之后，而這些子系統之間的關系將錯綜復雜，而且為了能夠針對性地增加某些服務的處理能力，某些服務的背后可能是一個集群模式，由多個節點構成，這無疑大大增加了運維的難度。微服務的想法好是好，但開發、運維的復雜度實在是太高。為了解決這些問題，阿里巴巴的Dubbo就橫空出世了。

Dubbo

Dubbo是一套微服務系統的協調者，在它這套體系中，一共有三種角色，分別是：服務提供者（下面簡稱提供者）、服務消費者（下面簡稱消費者）、注冊中心。

你在使用的時候需要將Dubbo的jar包引入到你的項目中，也就是每個服務都要引入Dubbo的jar包。然后當這些服務初始化的時候，Dubbo就會將當前系統需要發布的服務、以及當前系統的IP和端口號發送給注冊中心，注冊中心便會將其記錄下來。這就是服務發布的過程。與此同時，也是在系統初始化的時候，Dubbo還會掃描一下當前系統所需要引用的服務，然后向注冊中心請求這些服務所在的IP和端口號。接下來系統就可以正常運行了。當系統A需要調用系統B的服務的時候，A就會與B建立起一條RPC信道，然后再調用B系統上相應的服務。

這，就是Dubbo的作用。

創建項目的組織結構

• 創建一個Maven Project，命名為 microserver-dubbo-learning,
  這個Project由多個Module構成，每個Module對應著“微服務”的一個子系統，可獨立運行，是一個獨立的項目。 這也是目前主流的項目組織形式，即多模塊項目。
• 在這個項目下創建各個子模塊, 每個子模塊都是一個獨立的SpringBoot項目：
  • micro-user 用戶服務
  • micro-order 訂單服務
  • micro-product 商品服務
  • micro-analysis 數據分析服務
  • micro-controller 本系統的控制層，和以往三層結構中的Controller層的作用一樣，都是用作請求調度，只不過在微服務架構中，我們將它抽象成一個單獨的系統，可以獨立運行。
  • micro-common 它處于本系統的最底層，被所有模塊依賴，一些公用的類庫都放在這里。
  • micro-api 接口服務,

  • micro-redis 我們將Redis封裝成一個單獨的服務，運行在獨立的容器中，當哪一個模塊需要使用Redis的時候，僅需要引入該服務即可，就免去了各種繁瑣的、重復的配置。而這些配置均在micro-redis系統中完成了。

    
    
    image.png

下面我們開始動手創建項目

1,new 一個 Project

groupId:cn.haoxy.micro.server.dubbo
artifactId:microserver-dubbo-learning
version:v1.0.0

image.png

2,創建Model,在Project上創建model

image.png

依次創建好所有的model,如圖所示:

image.png

3,構建模塊之間的依賴關系:

目前為止，模塊之間沒有任何聯系，下面我們要通過pom文件來指定它們之間的依賴關系，依賴關系如下圖所示：

image.png

micro-user、micro-analysis、micro-product、micro-order這四個系統相當于以往三層結構的Service層，提供系統的業務邏輯，只不過在微服務結構中，Service層的各個模塊都被抽象成一個個單獨的子系統，它們提供RPC接口供上面的micro-controller調用。它們之間的調用由Dubbo來完成，所以它們的pom文件中并不需要作任何配置。而這些模塊和micro-common之間是本地調用，因此需要將micro-common打成jar包，并讓這些模塊依賴這個jar，因此就需要在所有模塊的pom中配置和micro-common的依賴關系。

此外，為了簡化各個模塊的配置，我們將所有模塊的通用依賴放在Project的pom文件中，然后讓所有模塊作為Project的子模塊。這樣子模塊就可以從父模塊中繼承所有的依賴，而不需要自己再配置了。

• 首先將micro-common的打包方式設成jar,當打包這個模塊的時候，Maven會將它打包成jar，并安裝在本地倉庫中。這樣其他模塊打包的時候就可以引用這個jar。

<dependency>
    <artifactId>micro-common</artifactId>
    <groupId>cn.haoxy.micro.server.dubbo.common</groupId>
    <version>v1.0.0</version>
    <packaging>jar</packaging>
</dependency>

• 將其他模塊的打包方式設為war,除了micro-common外，其他模塊都是一個個可獨立運行的子系統，需要在web容器中運行，所以我們需要將這些模塊的打包方式設成war

    <artifactId>micro-user</artifactId>
    <groupId>cn.haoxy.micro.server.dubbo.user</groupId>
    <version>v1.0.0</version>
    <packaging>war</packaging>

• 在總pom中指定子模塊modules標簽指定了當前模塊的子模塊是誰，但是僅在父模塊的pom文件中指定子模塊還不夠，還需要在子模塊的pom文件中指定父模塊是誰。

<modules>
  <module>micro-user</module>
  <module>micro-order</module>
  <module>micro-product</module>
  <module>micro-api</module>
  <module>micro-controller</module>
  <module>micro-analysis</module>
  <module>micro-common</module>
  <module>micro-redis</module>
</modules>

• 在子模塊中指定父模塊

例如在 micro-user子模塊中的 pom.xml中指定父模塊

<parent>
   <artifactId>microserver-dubbo-learning</artifactId>
   <groupId>cn.haoxy.micro.server.dubbo</groupId>
   <version>v1.0.0</version>
</parent>

到此為止，模塊的依賴關系配置完畢！但要注意模塊打包的順序。由于所有模塊都依賴于micro-common模塊，因此在構建模塊時，首先需要編譯、打包、安裝micro-common，將它打包進本地倉庫中，這樣上層模塊才能引用到。當該模塊安裝完畢后，再構建上層模塊。否則在構建上層模塊的時候會出現找不到micro-common中類庫的問題。

4,在父模塊的pom中添加所有子模塊公用的依賴

<dependencies>
        <dependency>
            <artifactId>micro-common</artifactId>
            <groupId>cn.haoxy.micro.server.dubbo.common</groupId>
            <version>v1.0.0</version>
        </dependency>
        <!--Spring MVC-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--Test-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <!-- MyBatis -->
        <dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>1.3.1</version>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>

        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid</artifactId>
            <version>1.0.11</version>
        </dependency>

        <!-- AOP -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

        <!-- guava -->
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>23.3-jre</version>
        </dependency>

        <!--fastjson-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>1.2.31</version>
        </dependency>
    </dependencies>

當父模塊的pom中配置了公用依賴后，子模塊的pom文件將非常簡潔，如下所示：

<modelVersion>4.0.0</modelVersion>
<parent>
  <artifactId>microserver-dubbo-learning</artifactId>
  <groupId>cn.haoxy.micro.server.dubbo</groupId>
  <version>v1.0.0</version>
</parent>


<artifactId>micro-user</artifactId>
<groupId>cn.haoxy.micro.server.dubbo.user</groupId>
<version>v1.0.0</version>

5,整合dubbo

Dubbo一共定義了三種角色，分別是：服務提供者、服務消費者、注冊中心。注冊中心是服務提供者和服務消費者的橋梁，服務消費者會在初始化的時候將自己的IP和端口號發送給注冊中心，而服務消費者通過注冊中心知道服務提供者的IP和端口號。

在Dubbo中，注冊中心有多種選擇，Dubbo最為推薦的即為ZooKeeper，本文采用ZooKeepeer作為Dubbo的注冊中心。

dubbo官網

• 父pom文件中引入dubbo依賴

<dependency>
   <groupId>com.alibaba.boot</groupId>
   <artifactId>dubbo-spring-boot-starter</artifactId>
   <version>0.2.0</version>
</dependency>

• 發布服務

假設，我們需要將micro-user項目中的UserService發布成一項RPC服務，供其他系統遠程調用，那么我們究竟該如何借助Dubbo來實現這一功能呢？

在micro-common中定義UserService的接口,由于服務的發布和引用都依賴于接口，但服務的發布方和引用方在微服務架構中往往不在同一個系統中，所以需要將需要發布和引用的接口放在公共類庫中，從而雙方都能夠引用。接口如下所示：

public interface UserService {


    UserEntity login(LoginReq loginReq);

}

在micro-user中定義接口的實現,在實現類上需要加上Dubbo的@Service注解，從而Dubbo會在項目啟動的時候掃描到該注解，將它發布成一項RPC服務。

@Service(version = "v1.0.0")
@org.springframework.stereotype.Service
public class UserServiceImpl implements UserService {

    @Autowired
    UserDAO userDAO;
    @Override
    public UserEntity login(LoginReq loginReq) {
        // do something ....

    }
}

配置服務提供者(micro-user、micro-analysis、micro-product、micro-order)

## Dubbo 服務提供者配置
dubbo.application.name=user-provider # 本服務的名稱
dubbo.registry.address=127.0.0.1:2181 # ZooKeeper所在服務器的IP和端口號
dubbo.registry.protocol=zookeeper
dubbo.protocol.name=dubbo  # RPC通信所采用的協議
dubbo.protocol.port=20880  # 本服務對外暴露的端口號
dubbo.scan.base-packages=cn.haoxy.micro.server.dubbo.user.service  # 服務實現類所在的路徑

按照上面配置完成后，當micro-user系統初始化的時候，就會掃描dubbo.scan.base-packages所指定的路徑下的@Service注解，該注解標識了需要發布成RPC服務的類。Dubbo會將這些類的接口信息+本服務器的IP+dubbo.protocol.port所指定的端口號發送給Zookeeper，Zookeeper會將這些信息存儲起來。 這就是服務發布的過程，下面來看如何引用一項RPC服務。

• 引用服務

假設，micro-controller需要調用micro-user 提供的登錄功能，此時它就需要引用UserService這項遠程服務。下面來介紹服務引用的方法。

聲明需要引用的服務,引用服務非常簡單，你只需要在引用的類中聲明一項服務，然后用@Reference標識，如下所示:

@RestController
public class UserControllerImpl implements UserController {


    @Reference(version = "v1.0.0")
    UserService userService;

    @PostMapping(value = "login")
    @Override
    public Result login(@RequestBody LoginReq loginReq, HttpServletResponse httpRsp) {
        UserEntity userEntity = userService.login(loginReq);
        return Result.newSuccessResult(userEntity);
    }
}

注意: @Reference(version = "v1.0.0")和@Service(version = "v1.0.0")的version的值一定要一致;

配置服務消費者(micro-controller)

## Dubbo 服務消費者配置
dubbo.application.name=controller-consumer # 本服務的名稱
dubbo.registry.address=zookeeper://127.0.0.1:2181  # zookeeper所在服務器的IP和端口號
dubbo.scan.base-packages=cn.haoxy.micro.server.dubbo  # 引用服務的路徑

上述操作完成后，當micro-controller初始化的時候，Dubbo就會掃描dubbo.scan.base-packages所指定的路徑，并找到所有被@Reference修飾的成員變量；然后向Zookeeper請求該服務所在的IP和端口號。當調用userService.login()的時候，Dubbo就會向micro-user發起請求，完成調用的過程。這個調用過程是一次RPC調用，但作為程序猿來說，這和調用一個本地函數沒有任何區別，遠程調用的一切都由Dubbo來幫你完成。這就是Dubbo的作用。