本期介绍🍖

目录

一、服务拆分

1）拆分时机

1、有快速迭代的需求

2、提交代码频繁出现大量冲突

3、小功能要积累到大版本才能上线

4、解决高并发横向扩展问题

 2）拆分原则

3）拆分方法

2、需求变化频率

3、服务性能要求

4、组织架构和团队规模

5、安全边界

6、技术异构

4）服务拆分注意事项

二、 远程调用

1）RestTemplate简介

2）提供者和消费者

三、代码实操

1）注册RestTemplate

2）服务远程调用RestTemplate

一、服务拆分

1）拆分时机

微服务拆分绝非是一个大跃进的过程，拆分时机不对，很容易把一个应用拆分的七零八落，最终大大增加运维成本，却不会带来明显收益。

微服务拆分的过程，是基于某个痛点出发，是业务真正遇到快速迭代和高并发等问题，如果不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分才是有确定收益的，增加的运维成本才是值得的。

1、有快速迭代的需求

互联网时代，业务快速变化，应用的交付需要快速响应式交付。通过微服务架构，采用快速迭代的方式进行架构演进，将系统拆分成多个独立的微服务，微服务之间彼此独立，通过服务接口交互。当某个微服务遇到问题时发版修复，不会导致整个系统不可用，从而支撑业务的快速试错。

2、提交代码频繁出现大量冲突

单体应用开发通常是几十人开发一个系统，代码管理时经常会遇到代码提交冲突。微服务架构通过快速迭代可实现开发独立，将系统拆分成不同的微服务，每个微服务对外提供接口，其他依赖服务不用关注具体的实现细节，只需保证接口正确即可。每几个人维护一个服务模块，降低代码冲突的概率，出现冲突时也可快速解决。

3、小功能要积累到大版本才能上线

传统模式单次上线的需求通常较多、风险较大，小功能的错误可能会导致大功能无法上线。因此每次上线都会带来较大的工作量。

微服务架构对于快速迭代可带来独立上线的效果。微服务拆分后，在服务接口稳定的情况下，不同的微服务可独立上线。上线的次数增多，单次上线的需求量变小，可随时回滚，风险变小，时间变短，影响面小，从而加快迭代速度。

4、解决高并发横向扩展问题

互联网时代，业务应用的高并发要求越来越高，单体应用虽然可以通过部署多份承载一定的并发量，但是会造成资源非常浪费。有的业务需要扩容，例如下单和支付，有的业务不需要扩容，例如注册。如果一起扩容，消耗的资源可能是拆分后的几倍。因此，对于并发量大的系统，选择微服务拆分是很有必要的。

•  2）拆分原则

单一职责原则： 每个微服务只需关心自己的业务规则，确保职责单一，避免职责交叉，耦合度过高将会造成代码修改重合，不利于后期维护。

服务自治原则：每个微服务的开发，必须拥有开发、测试、运维、部署等整个过程，并且拥有自己独立的数据库等，可以完全把其当作一个单独的项目来做，而不牵扯到其他无关业务。

轻量级通信原则：微服务间需通过轻量级通信机制进行交互。首先是体量较轻，其次是需要支持跨平台、跨语言的通信协议，再次是需要具备操作性强、易于测试等能力，如：REST通信协议。

接口明确原则：明确接口要实现的内容，避免接口依赖，如A接口的改动会导致B接口的改动。

持续演进原则：单体架构向微服务架构拆分过程中，无法做到一蹴而就，刚开始不建议拆分太小，过度拆分将会带来架构复杂度的急剧升高，开发、测试、运维等环节很难快速适应，将会导致故障率大幅增加，可用性降低，非必要情况，应逐步拆分细化，持续演进，避免微服务数量的瞬间爆炸性增长。

3）拆分方法

 微服务的拆分应遵循上述拆分时机、拆分原则，并选择合适的拆分方法，逐步拆分。在实际拆分过程中，除了要遵循拆分原则，还要从实际业务领域出发，并结合考虑非业务的因素，比如需求变更的频率、高性能、安全性、团队规模以及技术异构等因素。这些非业务因素对于最终落地也会起到决定性的作用，因此在微服务拆分时需要重点关注。

 1、业务领域拆分

基于领域模型，围绕业务界限上下文边界，将同类业务划归为一个微服务，按单一职责原则、功能完整性进行微服务的拆分。

2、需求变化频率

需要识别业务需求的变动频率，考虑业务变化频率与相关度，将业务需求变动较高和功能相对稳定的业务进一步分离拆分。

因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种拆分可以有效降低频繁发布版本的业务对不需要经常发布版本的业务的影响。

3、服务性能要求

需要识别性能压力较大的业务。因为对性能指标要求高的业务在资源需求上会比其他业务的高，这样可能会拖累其他业务，也会造成资源无谓的浪费。为了降低对系统整体性能和资源要求的影响，我们将对性能方面有较高要求的业务与对性能要求不高的业务进一步拆分。

4、组织架构和团队规模

除非有意识地优化组织架构，否则微服务的拆分应尽量避免对组织架构和团队的调整，避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本。

在进行微服务拆分和组建项目团队时，应尽量将沟通边界控制在团队内。

5、安全边界

对于有特殊安全要求的业务，应独立出来，避免因不同的安全要求，而带来不必要的成本，或带来泄密的风险。

6、技术异构

虽然都是在同一个业务领域内，但由于各种条件的限制，在技术实现时可能会存在较大的差异（存在技术异构的问题）。

大部分都是采用Java语言实现，但由于业务场景或者技术条件的限制，有的可能需要采用Go语言实现，甚至有的采用大数据技术架构。

4）服务拆分注意事项

• 1、不同微服务，不要重复开发相同业务
• 2、微服务数据独立，不要访问其他微服务的数据看
• 3、微服务可以将自己的业务暴露为接口，供其他微服务调用

二、 远程调用

1）RestTemplate简介

1、RestTemplate类可用于在应用中调用rest服务：

• 它简化了与http服务的通信方式；

• 统一了RESTful的标准；
• 封装了http链接， 我们只需要传入url及返回值类型即可。
• 相较于之前常用的HttpClient，RestTemplate是一种更优雅的调用RESTful服务的方式。

2、在Spring应用程序中访问第三方REST服务与使用Spring RestTemplate类有关。

RestTemplate类的设计原则与许多其他Spring *模板类(例如JdbcTemplate、JmsTemplate)相同，为执行复杂任务提供了一种具有默认行为的简化方法。

3、RestTemplate默认依赖JDK提供http连接的能力（HttpURLConnection），如果有需要的话也可以通过setRequestFactory方法替换为例如 Apache HttpComponents、Netty或OkHttp等其它HTTP library。

4、考虑到RestTemplate类是为调用REST服务而设计的，因此它的主要方法与REST的基础紧密相连就不足为奇了，后者是HTTP协议的方法:HEAD、GET、POST、PUT、DELETE和OPTIONS。

例如，RestTemplate类具有headForHeaders()、getForObject()、postForObject()、put()和delete()等方法。

2）提供者和消费者

服务提供者：一次业务中，被其他微服务调用的服务。

服务消费者：一次业务中，调用其他微服务的服务。

服务调用关系

• 服务提供者：暴露接口给其他微服务调用
• 服务消费者：调用其他微服务提供的接口
• 提供者与消费者角色其实是相对的
• 一个服务可以同时服务提供者和服务消费者

三、代码实操

1）注册RestTemplate

package com.cloud.order;import org.mybatis.spring.annotation.MapperScan;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.context.annotation.Bean;import org.springframework.web.client.RestTemplate;@MapperScan("com.cloud.order.mapper")@SpringBootApplicationpublic class OrderApplication {    public static void main(String[] args) { SpringApplication.run(OrderApplication.class, args);    }    @Bean    public RestTemplate restTemplate(){ return new RestTemplate();    }}

2）服务远程调用RestTemplate

package com.cloud.order.service;import com.cloud.order.mapper.OrderMapper;import com.cloud.order.pojo.Order;import com.cloud.order.pojo.User;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;import org.springframework.web.client.RestTemplate;@Servicepublic class OrderService {    @Autowired    private OrderMapper orderMapper;    @Autowired    private RestTemplate restTemplate ;    public Order queryOrderById(Long orderId) { // 1.查询订单 Order order = orderMapper.findById(orderId); //2.利用restTemplate 发起http请求，查询用户 String url = "localhost:8880/user/"+order.getId(); User user = restTemplate.getForObject(url,User.class); //设置用户信息 order.setUser(user); // 4.返回 return order;    }}

代码资源下载：
https://pan.baidu.com/s/169SFtYEvel44hRJhmFTRTQ
提取码：1234