什么是微服务，微服务相对于单体服务的利弊

雨点打透心脏的1/2处 2022-05-17 06:17 153阅读 0赞

### 什么是微服务 ###

微服务一种系统架构的设计风格，主旨是将原本复杂的系统拆分成多个独立的小型服务，每个服务维护着自身的业务逻辑、数据处理以及部署，服务和服务之间通过简单的通信协议进行通信（比如说Restful API）,不要求每个微服务使用同一种变成语言编写。

### 单体服务和微服务的优缺点 ###

微服务的概念上面已经介绍了，至于单体服务，就是我们企业系统架构中目前常用的一个单体项目，分为前端-后端-数据库，一个服务解决所有问题。

下面说一下单体服务和微服务的优缺点(下面表格来自菠萝科技的CSDN博客)：

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>微服务</th> 
   <th>单体服务</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>领域分隔</td> 
   <td>领域被分隔为微服务。分隔力度大，相互间的影响较小。微服务可以各自拥有不同的进化节奏，不同领域的创新可以分别实施、快速落地。领域间的调用相对困难，需要一些基础服务帮助，比如服务注册和寻址等。</td> 
   <td>领域的分隔表现为模块的分隔，其间的联系简单直接。</td> 
  </tr> 
  <tr> 
   <td>团队分隔</td> 
   <td>团队按微服务配置。成员专注于小的领域和代码集。沟通成本低。容易学习。需要部件之间紧密协作时相对困难，比如当代码需要在部件之间移动。</td> 
   <td>整个系统一个团队。如果系统变得庞大，成员就需要学习大量的代码和领域知识，团队内的沟通和协作也变得低效。不得不分割团队时容易按职责分割，形成竖井团队</td> 
  </tr> 
  <tr> 
   <td>技术分隔</td> 
   <td>在不同的微服务中，可以根据不同的业务特性分别选择适当的技术。包括可以分别选择适当的存储策略</td> 
   <td>整个系统（甚至整个企业）统一的技术栈，管理起来看似简单。但有时候统一的标准并不适合所有的实际情况</td> 
  </tr> 
  <tr> 
   <td>运行时分隔</td> 
   <td>各部件通常运行于不同的进程。容易进行错误隔离。可以分别伸缩。运行时需要管理的单位较多，相对困难，需要一些专门的运营工具</td> 
   <td>通常运行于同一个进程。部件间协作的额外开销很小</td> 
  </tr> 
 </tbody> 
</table>

当然，微服务也不是万能的，相对于单体服务，微服务也是有很多缺点的：  
\- 运维层面上，运维需要维护的服务更多了  
\- 问题难定位，单体项目日志集中在一起，出现问题好定位，而微服务通过日志去定位问题比较困难  
\- 微服务的雪崩问题，由于网络的不稳定性，不可能保证每个服务100%可用，如果某个服务发生问题，可能会导致依赖服务阻塞，最终引发雪崩效应  
\- 分布式的复杂性，由于服务都独立部署，事物问题、网络延迟等问题会增大业务的复杂性

虽然使用微服务会遇到上面的这些问题，但是针对问题也同样产生了对应的解决方案：  
\- 运维层面上可以写自启动脚本  
\- 定位问题方面可以将日志文件写到一起  
\- 雪崩问题可以添加服务可用性监控  
\- 分布式复杂性问题，可以使用分布式事务解决事物问题

虽然使用为服务会带来一些问题，但是每当遇到问题，都会产生解决方案。相对于微服务带来的好处，微服务在一些大型服务上的使用前景还是很乐观的。

喜欢这篇文章的朋友，欢迎扫描下图关注公众号**lebronchen**，第一时间收到更新内容。  
![扫码关注][70]

[70]: /images/20220517/900aebd516604993bdf0dac7b70206b2.png