微服务的利弊

目录

1.微服务的利

1.1. 从个人开发的角度来看：更加精确。

1.2. 从小组开发的角度来看：更加灵活。

1.3. 从企业的角度来看：项目的生命力和扩展性更强。

1.4. 从测试运维发布的角度来看：快上快下。

1.5. 从资源分配的角度来看：合理调配。

1.6. 从事务差错处理的角度来看：细粒度容错。

1.7. 从业务耦合度的角度来看：业务解耦。

2.微服务的弊。

2.1. 一个字：贵

2.2. 部署结构复杂。

---

我们在说微服务的利弊的时候，总会拿它与单体项目去做对比。

那么什么又是单体项目呢？

其实很好理解，我们可以把一个单体项目比喻成一个大盒子，一个业务中的所有的东西都放在这一个盒子里面。

说到这里可能大家会觉得微服务多此一举，既然一个项目能整合在一起运作，为什么要对他进行拆分呢？这不是多此一举吗？如果你也有这样的疑问，那说明认真思考了。

1.微服务的利

1.1. 从个人开发的角度来看：更加精确。

在以前做单体项目时，可能一些人的业务目标不够明确，或者开发不够彻底，在衔接的时候出现差错，发现一些隐藏问题，需要进行改进和版本回退，从而可能会导致某些人拖延进度，导致项目无法按时交割上线，无形中带来一系列损失。

1.2. 从小组开发的角度来看：更加灵活。

在以前做单体项目时，可能这个大的项目需要20甚至30人共同协作完成，要经常的开会沟通和小组讨论诸多问题的解决方案，过程非常繁琐，浪费大量时间；假设我们采用微服务，就可以把一个大的单体项目拆分成诸多的小模块，每个小组分配几个人只负责其中一个模块，只负责自己小组所分配到的业务模块，不需要像以前那样花费大量的时间开会讨论解决方案。而且后续如果那个业务出现了问题，追责更加容易。

其次，由于业务得到了拆分，我们每个小组可以在自己的业务基础上做一些独立的升级改进，一步步的演化，业务越来越复杂，在整个项目中的比例越来越高，话语权也越来越重，表现优异，企业对员工以及小组都肯定会有一定的奖励，从而提高了员工的工作热情，形成一种正相关，双向促进发展。

1.3. 从企业的角度来看：项目的生命力和扩展性更强。

由于我们的项目做成了微服务项目，所以项目的生命力是很顽强的，在项目中，由于一些分布式技术的加入，不会出现业务崩溃的情况，不会对公司财务造成毁灭性的打击；而且，紧接着我们刚才说的小组开发，整个大项目的可扩展性非常非常高，后续这个大项目说不定甚至可以和公司一些其他的业务做交互，扩展性极高，对公司发展也非常有利。

1.4. 从测试运维发布的角度来看：快上快下。

这里主要指项目的部署，因为在之前的单体项目中，你要上线部署，就必须把所有的事情全部完成，不能有差错，然后进行部署，但一旦有任何一个地方出现错误，都要延迟发布，回溯版本，所造成的损失是巨大的。

而微服务就不会有这样的困难，因为每个模块小组独立，他们可以独立部署，独立发布，独立测试，就算你的用户业务模块出现了问题，延迟进行发布，但不会影响我订单业务模块的测试发布，而且每个独立项目上线之后，我们可以各个小组都可以对他们自己负责的业务进行独立的升级和快速的验证是否可用。

1.5. 从资源分配的角度来看：合理调配。

假设我们整个集群有10000台机器，我们这里可以根据不同业务的繁忙程度，分配不同的机器，假设用户搜索业务最繁忙，分配5000台机器，订单服务较为繁忙，分配4000台机器，库存业务模块不太繁忙，只分配1000台机器足以，那么这些都是在微服务中可以实现的。而在单体项目中，就无法做到如此精细。

1.6. 从事务差错处理的角度来看：细粒度容错。

从服务差错处理角度来讲，微服务也比单体项目要好很多，限流与降级熔断是我们微服务中一个很重要的环节，在微服务中，我们可以给每一个业务定制非常细粒度的限流与降级熔断措施，但单体项目就不可以，它的耦合程度过高。

举一个最简单的例子，在单体项目中，由于我们的业务都写在一起，很多操作写在同一个事务中，假设我们一个事务中的一个小环节出现了一点点差错，如写数据库操作失败，就要马上回滚，结束事务。

但是在微服务架构里面，我们经常会有一些熔断降级的措施，还是写数据库失败，我们可以做一个降级，把这个写数据库的操作打到缓存当中，或者打入MQ消息组件当中，采用异步处理写库的方式，这就是一个很常见的降级补偿的措施，在单体项目中，根本无法做到这么精细力度的容错处理。

1.7. 从业务耦合度的角度来看：业务解耦。

在单体项目中，他们的业务之间都掺杂在了一起，没有很明确的界限，而且数据库较为集中，项目的所有有关表的数据都放在一个数据库中，处理业务时都是直接在同一个数据库的几张表上进行读写操作。

比如说，我的支付下单操作，可以直接去商品表中进行读写操作，商品接口也能到下单的数据库中进行读写操作；如果有朝一日，我的某个数据库表需要修改，那么有关该表所有的业务都会受牵连，造成的损失是非常大的。

但是在微服务项目中，就可以避免这些问题的发生，我们的业务模块进行拆分，同时把数据库也进行拆分，支付下单功能有自己的独立的数据库表，商品库存也有自己的独立的数据库表，当我支付下单功能要对库存表进行读写的时候，只需要通过远程调用调用库存业务模块的操作，让库存业务模块中的接口去读写自己的数据库，实现了数据库的隔离操作；而且后续如果对数据库的表做改变，我们也只需要改动对应的业务模块中的方法即可，只要对外暴露的业务接口保持不变，就不会对其他业务有影响。从而规范了业务流程，也规范了数据的访问，对数据库的安全性作到了一定的保障。

2.微服务的弊。

2.1. 一个字：贵

相比于单体项目，微服务的成本是要更高一些的，如果我们想要做一个小型项目，只有几个简单的业务，做一个单体项目图个方便图个便宜也是不错的选择。

但如果想要好的，还得用钱砸出来，做更全面，作为服务项目，我们刚才也说了微服务的一些好处，所以它也是要比单体项目成本更高的。

2.2. 部署结构复杂。

其实要说微服务结构复杂，倒也不复杂，就现在而言，微服务的技术已经非常成熟，以前的很多问题和困难，到现在已经被很多框架屏蔽解决了，是不需要我们开发人员管理的，但相比于单体项目而言，还是要复杂一点的。

总结：综合考虑，微服务的好处还是很多的，而且现在互联网行业的趋势也表明了微服务活力还是非常旺盛的；现在，几乎所有的企业都在使用微服务架构，那些没有使用微服务的也在逐渐向微服务转变。