本节内容会用到之前给大家讲过的这两篇：
2流高手速成记（之六）：从SpringBoot到SpringCloudAlibaba
2流高手速成记（之三）：SpringBoot整合mybatis/mybatis-plus实现数据持久化
链接挂出来 ，方便咱们中途对比着看
老规矩 ，先放出本节的项目结构：
我们参考上一节中讲到的创建SpringCloudAlibaba工程模板的步骤 ，在工程下在创建三个子模块 ，创建过程中勾选相同的依赖项
这三个子模块也是三个独立的可执行的工程 ，他们的用途分别为：
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
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
既然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
<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
# 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上托管的配置数据：
注意 ，新创建配置的Data Id需要与他们的应用名称同名
provider需要持有mysql相关配置
consumer作为controller的持有者 ，需要声明外部的可访问端口
全部的移植工作到这里就完毕了！
我们分别执行provider 、consumer两个独立进程
此时我们打开nacos服务列表 ，会看到dubbo-nacos-consumer 、dubbo-nacos-provider两个执行中的服务
执行结果如下：
怎么样？是不是非常神奇？我们只改动了两个注解 ，原本还是一个整体的工程就被一分为二了 ，并且是两个可以彼此独立运转在两台独立机器上的服务
—— 这就是微服务的神奇之处！
借助于强大的SpringCloudAlibaba ，我们不仅可以对所有的业务实现统合拆分 ，充分调动团队人员配置各司其职各自编写自己的服务模块 ，
更大的意义在于我们可以充分调动多台独立设备的技能 ，使之串联为一个庞大服务集群 ，较之于单台机器实现整个架构性能成千上万倍的飞跃！
但是 ，微服务带来研发 、管理 、性能便捷的同时 ，整个集群也在运维层面面对了前所未有的挑战 ，最明显的：
consumer在业务上依赖于后端的provider ，如果provider运转不正常 ，前方的consumer又该如何自处？！
围绕这个问题 ，又有新的概念诞生了——【限流 、熔断 、容错 、服务降级】
Sentinel要来咯~ 敬请期待！
properties
声明：本站所有文章 ，如无特殊说明或标注 ，均为本站原创发布 。任何个人或组织 ，在未征得本站同意时 ，禁止复制 、盗用 、采集 、发布本站内容到任何网站 、书籍等各类媒体平台 。如若本站内容侵犯了原著者的合法权益 ，可联系我们进行处理 。
