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

机智兵

已于 2022-04-17 21:53:05 修改

阅读量1.4k

点赞数 24

分类专栏：微服务 java 文章标签： java spring spring cloud 微服务

于 2022-04-17 21:50:31 首次发布

本文链接：https://blog.csdn.net/a6470831/article/details/124235654

版权

本文深入探讨微服务的拆分原则和方法，包括拆分时机、业务领域拆分、需求变化频率等因素。同时讲解了远程调用中的RestTemplate使用，介绍了服务提供者和消费者的概念，以及如何通过代码实操进行服务调用。

摘要由CSDN通过智能技术生成

本期介绍🍖

一、服务拆分

1）拆分时机

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

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

1、有快速迭代的需求

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

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

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

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

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

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

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

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