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

什么是微服务

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

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

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

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

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

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

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

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

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