0

2流高手速成记(之七):基于Dubbo&Nacos的微服务简要实现 - 14号程序员

 1 year ago
source link: https://www.cnblogs.com/itfantasy/p/16855963.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

2流高手速成记(之七):基于Dubbo&Nacos的微服务简要实现

本节内容会用到之前给大家讲过的这两篇:

2流高手速成记(之六):从SpringBoot到SpringCloudAlibaba

2流高手速成记(之三):SpringBoot整合mybatis/mybatis-plus实现数据持久化

链接挂出来,方便咱们中途对比着看

老规矩,先放出本节的项目结构:

1047129-20221103203721248-2124320821.png

我们参考上一节中讲到的创建SpringCloudAlibaba工程模板的步骤,在工程下在创建三个子模块,创建过程中勾选相同的依赖项

1047129-20221103203909472-986004690.png

这三个子模块也是三个独立的可执行的工程,他们的用途分别为:

dubbo-nacos-provider:服务(Service)提供方

dubbo-nacos-consumer:消费方,服务的调用者

dubbo-nacos-api:接口及模型类定义,同时作为前边二者的依赖方

接下来,我们共同见证神奇的一幕:

大家都知道,我们在第三节中实现的工程是一个结构相对完备(包含Service、Controller,View由Postman替代)且可以直接执行的独立进程

本节我们依靠上一节讲到的微服务技术,以几乎不改变原有代码为前提,将其一分为三:

provider和consumer分别独立执行

consumer借助微服务技术完成对provider的调用

api模块是二者的依赖项,并非可执行的进程

1. Service接口、Model声明迁移到dubbo-nacos-api

1047129-20221103205404077-1245486431.png
package com.example.dubbonacosapi.model;

import java.io.Serializable;

public class Person implements Serializable {
    private Integer id = 0;

    private String name = "";

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}
package com.example.dubbonacosapi.service;

import com.example.dubbonacosapi.model.Person;

import java.util.List;

public interface PersonService {
    Integer insert(Person person);

    Integer update(Person person);

    Integer delete(int id);

    List<Person> select();
}

因为api的作用仅是构成provider、consumer的二者依赖,所以其仅是持有相关声明即可

Person类及PersonService在原有代码基础上保持不变!

2. Service接口实现类、Mapper声明(mybatis-plus)迁移到dubbo-nacos-provider

1047129-20221103205934502-1018355652.png

既然provider保有mybatis-plus访问mysql的能力,所以相关的依赖必定不可或缺

        <!-- 引入mybatis、mybatis-plus、mysql等依赖 -->
        <dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>2.2.2</version>
        </dependency>
        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-boot-starter</artifactId>
            <version>3.5.2</version>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>

        <dependency>
            <groupId>com.example</groupId>
            <artifactId>dubbo-nacos-api</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>

引入的方式和第三节讲到的方式一样

此外还包含了对于刚才我们创建的dubbo-nacos-api的依赖,引入非常的方便

package com.example.dubbonacosprovider.mapper;

import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import com.example.dubbonacosapi.model.Person;
import org.apache.ibatis.annotations.Mapper;
import org.springframework.stereotype.Repository;

@Mapper
@Repository
public interface PersonMapper extends BaseMapper<Person> {
}
package com.example.dubbonacosprovider.service.impl;

import com.example.dubbonacosapi.model.Person;
import com.example.dubbonacosapi.service.PersonService;
import com.example.dubbonacosprovider.mapper.PersonMapper;
import org.apache.dubbo.config.annotation.DubboService;
import org.springframework.beans.factory.annotation.Autowired;

import java.util.List;

@DubboService
public class PersonServiceImpl implements PersonService {

    @Autowired
    PersonMapper mapper;

    public Integer insert(Person person) {
        return mapper.insert(person);
    }

    public Integer update(Person person) {
        return mapper.updateById(person);
    }

    public Integer delete(int id) {
        return mapper.deleteById(id);
    }

    public List<Person> select() {
        return mapper.selectList(null);
    }
}

Mapper的声明没有任何变化,而PersonServiceImpl依然保有对接口PersonService的实现,区别在于后者来自api模块

唯一的区别在于PesonServiceImpl类的注解,由原有的@Service变更为@DubboService —— 这是唯一的区别!

3. Controller迁移到dubbo-nacos-consumer

1047129-20221103210824555-1225019599.png
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>com.example</groupId>
            <artifactId>dubbo-nacos-api</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>

consumer作为外部可访问的web服务,自然需要持有web相关依赖项

同时,与provicer相同,其与api模块保持依赖关系

package com.example.dubbonacosconsumer.controller;

import com.example.dubbonacosapi.model.Person;
import com.example.dubbonacosapi.service.PersonService;
import org.apache.dubbo.config.annotation.DubboReference;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@RestController
@RequestMapping("/person")
public class PersonController {
    @DubboReference
    PersonService service;

    @PostMapping("/insert")
    public Integer insert(Person person) {
        return service.insert(person);
    }

    @PostMapping("/update")
    public Integer update(Person person) {
        return service.update(person);
    }

    @PostMapping("/delete")
    public Integer delete(int id) {
        return service.delete(id);
    }

    @GetMapping("/select")
    public List<Person> select() {
        return service.select();
    }
}

留意PersonService的引入方式:不再是@Autowired,而是变更为@DubboReference —— 这是唯一的区别!

4. Consumer和Provider的配置项

这里我们依然沿用上一节讲到的知识——以nacos作为配置中心

二者同时仅在本地保留一个bootstrap.properties配置文件,application.properties托管给nacos

1047129-20221103211350607-1901890572.png
# Nacos帮助文档: https://nacos.io/zh-cn/docs/concepts.html
# Nacos认证信息
spring.cloud.nacos.config.username=nacos
spring.cloud.nacos.config.password=nacos
spring.cloud.nacos.config.contextPath=/nacos
# 设置配置中心服务端地址
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
# Nacos 配置中心的namespace。需要注意,如果使用 public 的 namcespace ,请不要填写这个值,直接留空即可
# spring.cloud.nacos.config.namespace=

# 应用名称
spring.application.name=dubbo-nacos-consumer
# Nacos帮助文档: https://nacos.io/zh-cn/docs/concepts.html
# Nacos认证信息
spring.cloud.nacos.config.username=nacos
spring.cloud.nacos.config.password=nacos
spring.cloud.nacos.config.contextPath=/nacos
# 设置配置中心服务端地址
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
# Nacos 配置中心的namespace。需要注意,如果使用 public 的 namcespace ,请不要填写这个值,直接留空即可
# spring.cloud.nacos.config.namespace=

# 应用名称
spring.application.name=dubbo-nacos-provider

内容均为nacos相关配置,以及各自声明了自己的应用名称(spring.application.name)

然后是他们在nacos上托管的配置数据:

1047129-20221103211817939-361636040.png

 注意,新创建配置的Data Id需要与他们的应用名称同名

 

1047129-20221103212038419-1650083467.png

 provider需要持有mysql相关配置

1047129-20221103212205460-883655622.png

consumer作为controller的持有者,需要声明外部的可访问端口

全部的移植工作到这里就完毕了!

我们分别执行provider、consumer两个独立进程

此时我们打开nacos服务列表,会看到dubbo-nacos-consumer、dubbo-nacos-provider两个执行中的服务

1047129-20221103213009781-1568464830.png

 执行结果如下:

1047129-20221103213326555-1414165628.png

怎么样?是不是非常神奇?我们只改动了两个注解,原本还是一个整体的工程就被一分为二了,并且是两个可以彼此独立运转在两台独立机器上的服务

—— 这就是微服务的神奇之处!

借助于强大的SpringCloudAlibaba,我们不仅可以对所有的业务实现统合拆分,充分调动团队人员配置各司其职各自编写自己的服务模块,

更大的意义在于我们可以充分调动多台独立设备的技能,使之串联为一个庞大服务集群,较之于单台机器实现整个架构性能成千上万倍的飞跃!

但是,微服务带来研发、管理、性能便捷的同时,整个集群也在运维层面面对了前所未有的挑战,最明显的:

consumer在业务上依赖于后端的provider,如果provider运转不正常,前方的consumer又该如何自处?!

围绕这个问题,又有新的概念诞生了——【限流、熔断、容错、服务降级】

Sentinel要来咯~ 敬请期待!

properties


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK