微服务根本拆分实践（第一篇）

目录

前言
一、认识微服务
1.1 单体架构 VS 微服务架构 
1.2 微服务的集大成者：SpringCloud
1.3 微服务拆分原则
1.4 微服务拆分方式
二、微服务拆分入门步骤 ：以拆分商品模块为例
三、服务注册订阅与远程调用：以拆分购物车为例
3.1 拆分模块、发现问题
3.2 问题分析、办理方法
3.3 实现远程调用：RestTemplate工具，实现端到端哀求发送
四、微服务根本拆分总结
五、微服务根本追问巩固

---

前言

1. 微服务的根本入门篇，读完本文让你对微服务有一个基本的相识，与此同时通过两个微服务的模块拆分实行，发现微服务拆分面对的困难。并尝试去办理它。
2. 介绍微服务与单体架构的区别、微服务的拆分原则；办理跨微服务哀求问题

一、认识微服务

        我觉得既然能看到这篇笔记，想必大家对微服务都是有肯定的概念的。本篇文章是笔者在学习微服务、拆分微服务、办理拆分微服务中遇到的问题总结而来。是面向实践的。

---

参考下面这张项目架构演变图。微服务就是随着项目规模不停扩大，为了减轻服务器的压力、维持提高项目团队的高效协作、加快项目部署打包等功能提出的技术。
它将业务代码按照业务模块的不同，分别成多个小项目或是小模块，确保了每一个模块的职责明确，且分别部署到不同的一台或多台服务器上，减少服务器压力。

1.1 单体架构 VS 微服务架构 

单体架构：将业务的所有功能集中在一个项目中开辟，打成一个包部署。
优点：（小规模下的优势）

• 架构简单
  
• 部署难度低 
  
• 维护成本低
  

缺点：（大规模下的缺陷）

• 团队协作难（就好像1个人盖楼100天、100人盖楼1天、100万人盖楼1分钟 可能吗？ 人越多，在一个单体中开辟、维护越来越困难）
  
• 发布效率低 （单体打包几个G、几十个G甚至更大，浪费多少时间）
  
• 系统可用性差（对服务器压力大，别的业务哀求量大的时间会影响其他正常的业务）
  

---

微服务架构：是服务化思想指导下的一套最佳实践架构方案。服务化，就是把单体架构中的功能模块拆分为多个独立项目。
优点：（大规模下谈、小规模都不消）

• 粒度小、发布效率高
  
• 团队协调效率高
  
• 单台服务器压力小
  

缺点：（大规模下谈、小规模都不消）

• 需要办理不同业务之间的服务调用问题 （涉及到不同服务器之间的通信哀求）
  
• 需要更多的部署成本 （服务器多了、项目标部署更加讲究）
  

1.2 微服务的集大成者：SpringCloud

简单来说，微服务的概念很早就有了，但是家家不同。SpringCloud的出现，就像同一度量衡制定了一系列行业标准。
SpringCloud是目前国内使用最广泛的微服务框架。 SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
   官网学习：Spring Cloud
  

这张图可告急啦，对应着我们在拆分微服务项目标时间会遇到的各种问题，SpringCloud都给出了相应的办理措施。

---

【SpringCloud 与 SpringBoot的版本对照】
由于目前企业使用jdk8、jdk11比力多，所有本次实行接纳2021版Spring Cloud举行微服务搭建

1.3 微服务拆分原则

1. 单一职责原则

每个微服务应专注于实行单一的功能或业务范畴。
2. 高内聚、低耦合

把相干的行为都聚集在一起，把不干系的行为放到其他地方。这样，当他们要修改某个行为的时间，只需要在一个地方修改即可，然后就能对该修改及早地举行发布。同时也有利于低落模块与模块之间的耦合性，提高每个模块的独立性。
假如要在许多不同的地方做修改，那么就需要同时发布多个微服务才能交付这个功能。修改进度不同一、测试工作不线性、部署工作不集中。从而大大低落开辟效率。
3. 独立有界限

微服务应有明确定义的界限和功能。

1.4 微服务拆分方式

纵向拆分：按业务模块举行拆分，并遵照微服务拆分原则
横向补充：对于大家都会用到的公共服务，还可以在纵向根本上补充横向拆分，抽取公共服务，提高代码复用

【目前广泛应用的两种微服务架构】
1. 拆分独立若干project，分项目管理
这种拆分得当于超大规模的团队协调开辟，项目完全解耦。

• 优点：服务之间耦合度低
  
• 缺点：每个项目都有本身的独立仓库，管理起来比力麻烦
  

2. 拆分依赖于主模块的若干子模块，同一Maven管理
这种拆分相对我们学习来说比力容易，一个项目内用不同的模块代表不同的服务

• 优点：项目代码集中，管理和运维方便
  
• 缺点：服务之间耦合，编译时间较长
  

二、微服务拆分入门步骤 ：以拆分商品模块为例

本次实行以黑马商城的项目拆分为例，接纳拆分模块的方式来举行微服务的学习：

2.1 入门拆分微服务步骤 

• 第一步：新建微服务模块
  
• 第二步：拷贝父工程的依赖坐标
  
• 第三步：搭建基本框架，编写启动类
  
• 第四步：拷贝设置文件，修改相干设置
  
• 第五步：拷贝业务代码，遵照从 domain -- mapper -- service -- controller，注意检查导包
  
• 第六步：连接数据库，确认微服务数据库
  
• 第七步：测试项目 访问 接口文档 举行代码哀求测试http://localhost:8081/doc.html
  
  http://localhost:8081/doc.html
  

1. <!--来自父工程-->
2.     <dependencies>
3.         <!--common-->
4.         <dependency>
5.             <groupId>com.heima</groupId>
6.             <artifactId>hm-common</artifactId>
7.             <version>1.0.0</version>
8.         </dependency>
9.         <!--web-->
10.         <dependency>
11.             <groupId>org.springframework.boot</groupId>
12.             <artifactId>spring-boot-starter-web</artifactId>
13.         </dependency>
14.         <!--数据库-->
15.         <dependency>
16.             <groupId>mysql</groupId>
17.             <artifactId>mysql-connector-java</artifactId>
18.         </dependency>
19.         <!--mybatis-->
20.         <dependency>
21.             <groupId>com.baomidou</groupId>
22.             <artifactId>mybatis-plus-boot-starter</artifactId>
23.         </dependency>
24.         <!--单元测试-->
25.         <dependency>
26.             <groupId>org.springframework.boot</groupId>
27.             <artifactId>spring-boot-starter-test</artifactId>
28.         </dependency>
29.     </dependencies>
30.     <build>
31.         <finalName>${project.artifactId}</finalName>
32.         <plugins>
33.             <plugin>
34.                 <groupId>org.springframework.boot</groupId>
35.                 <artifactId>spring-boot-maven-plugin</artifactId>
36.             </plugin>
37.         </plugins>
38.     </build>

复制代码

2.2 办理商品模块的哀求 500 问题

【原因】 数据库连接失败，设置文件加载失败

【办理措施】修改设置文件名即可

三、服务注册订阅与远程调用：以拆分购物车为例

3.1 拆分模块、发现问题

前面的拆分步骤照常，以下是拆分购物车模块遇到的问题
购物车微服务需要依赖商品微服务模块的方法，因此产生了报错，对此我们先采取解释的方式。先确保购物车微服务模块搭建运行成功后，后续我们再来通过SpringCloud的技术来办理这个问题。

接着设置数据库、将微服务部署到8082端口，启动访问测试：http://localhost:8082/doc.html

3.2 问题分析、办理方法

我们发现，拆分微服务的项目往往会面对这样一个问题：一个微服务需要注入另外一个微服务的方法或属性。

但是拆分微服务需要遵照一个原则：独立性、单一职责。也就是说我们不应该在购物车的微服务业务中注入过多的商品微服务模块的方法。
因此，我们需要思索怎样让购物车微服务获取到商品微服务的方法同时又不破坏拆分原则呢？我们知道现实上我们发送的哀求是一个完整的URL，可不可以这样做：我们模仿前端向后端发送哀求的格式，让购物车发送获取商品信息的哀求，这样一来不就办理问题了嘛

3.3 实现远程调用：RestTemplate工具，实现端到端哀求发送

服务拆分之后，不可避免的会出现跨微服务的业务，此时微服务之间就需要举行远程调用。微服务之间的远程调用被称为RPC，即远程过程调用。

【RestTemplate介绍】
java开辟中，使用http连接访问第三方网络接口，通常使用工具HttpClient和OKHttp。（后面讲）
假如使用spring框架，可以使用Spring给我们提供了一个RestTemplate工具，可以方便的实现Http哀求的发送。
restTemplate默认的连接方式是java中的HttpConnection，可以使用ClientHttpRequestFactory指定不同的HTTP连接方式。

【使用步骤】
1. 在springboot项目中，需要使用RestTemplate的模块【cartcart-service】新建config设置

2. 注入RestTemplate对象

3. 使用RestTemplate方法举行代码修改

1. private void handleCartItems(List<CartVO> vos) {
2.         // 1.获取商品id
3.         Set<Long> itemIds = vos.stream().map(CartVO::getItemId).collect(Collectors.toSet());
4.         // 2.查询商品
5.         // 2.1 构建请求、发送请求
6.         ResponseEntity<List<ItemDTO>> response = restTemplate.exchange(
7.             "http://localhost:8081/items?ids={ids}",
8.                 HttpMethod.GET,
9.                 null,
10.                 new ParameterizedTypeReference<List<ItemDTO>>() {},
11.                 Map.of("ids", CollUtil.join(itemIds, ","))
12.         );
13.         //2.2 解析响应对象
14.         if(!response.getStatusCode().is2xxSuccessful()) {
15.             // 查询失败
16.             return;
17.         }
18.         // 2.3 获取查询商品对象
19.         List<ItemDTO> items = response.getBody();
20.         if(CollUtils.isEmpty(items)) {
21.             return;
22.         }
24.         // 3.构建商品id与商品对象的映射
25.         Map<Long,ItemDTO> itemMap = items.stream().collect(Collectors.toMap(ItemDTO::getId, Function.identity()));
27.         //4. 写入VO对象返回前端
28.         for(CartVO v : vos) {
29.             ItemDTO item = itemMap.get(v.getItemId());
30.             if(item == null) {
31.                 continue;
32.             }
33.             v.setNewPrice(item.getPrice()); // 最新价格
34.             v.setStock(item.getStock()); // 库存
35.             v.setStatus(item.getStatus()); // 状态
36.         }
37.     }

复制代码

【功能测试】

四、微服务根本拆分总结

到此为止，事实上你已经可以搭建一个浅易的微服务项目了。只管这个微服务项目另有诸多问题和挑衅。
比方你发现没有？在我们使用RestTemplate工具发送哀求的时间，url是我们写死的。而且开辟者需要非常清晰有这么一个方法，有这么一个方法的提供者，而且要知道提供者的具体地址。与此同时，假如服务的提供者宕机了，服务调用者也无法得知。这样的限定太大了。所以后期我们肯定会寻求这方面的突破的。
在根本篇中，我们相识了微服务架构和单体架构的区别、学习了微服务拆分的模式和需要遵照的原则、尝试举行简单微服务模块的拆分并调试成功、成功发现跨微服务哀求问题并初步尝试使用强大的RestTemplate去办理它......通过以上内容，相信你已经入门微服务了，接下来也能更好地去深入微服务项目标学习。


五、微服务根本追问巩固

1. 谈谈什么是微服务？什么时间要用微服务？目前主流的微服务技术有哪些？
2. 谈谈拆分微服务应该遵守哪些原则？你认为其中最有挑衅性的是什么？
3. 详细解说微服务的拆分步骤是什么？
4. 假如拆分过程中遇到要使用其他微服务提供的方法是，怎样实现哀求的远程调用？
5. 相识过RestTemplate没有？请谈谈你对RestTemplate的见解，具体的使用步骤是什么？


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。