【微服务】（二）—— 服务拆分与远程调用

 本期介绍🍖

目录

一、服务拆分

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）拆分原则

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

服务自治原则：每个微服务的开发，必须拥有开发、测试、运维、部署等整个过程，并且拥有自己独立的数据库等，可以完全把其当作一个单独的项目来做&#x