微服务的利弊

目录一.微服务的利1.1. 从个人开发的角度来看更加精确。1.2. 从小组开发的角度来看更加灵活。1.3. 从企业的角度来看项目的生命力和扩展性更强。1.4. 从测试运维发布的角度来看快上快下。1.5. 从资源分配的角度来看合理调配。1.6. 从事务差错处理的角度来看细粒度容错。1.7. 从业务耦合度的角度来看业务解耦。二.微服务的弊。2.1. 一个字贵2.2. 部署结构复杂。我们在说微服务的利弊的时候总会拿它与单体项目去做对比。那么什么又是单体项目呢其实很好理解我们可以把一个单体项目比喻成一个大盒子一个业务中的所有的东西都放在这一个盒子里面。说到这里可能大家会觉得微服务多此一举既然一个项目能整合在一起运作为什么要对他进行拆分呢这不是多此一举吗如果你也有这样的疑问那说明认真思考了。一.微服务的利1.1. 从个人开发的角度来看更加精确。在以前做单体项目时可能一些人的业务目标不够明确或者开发不够彻底在衔接的时候出现差错发现一些隐藏问题需要进行改进和版本回退从而可能会导致某些人拖延进度导致项目无法按时交割上线无形中带来一系列损失。1.2. 从小组开发的角度来看更加灵活。在以前做单体项目时可能这个大的项目需要20甚至30人共同协作完成要经常的开会沟通和小组讨论诸多问题的解决方案过程非常繁琐浪费大量时间假设我们采用微服务就可以把一个大的单体项目拆分成诸多的小模块每个小组分配几个人只负责其中一个模块只负责自己小组所分配到的业务模块不需要像以前那样花费大量的时间开会讨论解决方案。而且后续如果那个业务出现了问题追责更加容易。其次由于业务得到了拆分我们每个小组可以在自己的业务基础上做一些独立的升级改进一步步的演化业务越来越复杂在整个项目中的比例越来越高话语权也越来越重表现优异企业对员工以及小组都肯定会有一定的奖励从而提高了员工的工作热情形成一种正相关双向促进发展。1.3. 从企业的角度来看项目的生命力和扩展性更强。由于我们的项目做成了微服务项目所以项目的生命力是很顽强的在项目中由于一些分布式技术的加入不会出现业务崩溃的情况不会对公司财务造成毁灭性的打击而且紧接着我们刚才说的小组开发整个大项目的可扩展性非常非常高后续这个大项目说不定甚至可以和公司一些其他的业务做交互扩展性极高对公司发展也非常有利。1.4. 从测试运维发布的角度来看快上快下。这里主要指项目的部署因为在之前的单体项目中你要上线部署就必须把所有的事情全部完成不能有差错然后进行部署但一旦有任何一个地方出现错误都要延迟发布回溯版本所造成的损失是巨大的。而微服务就不会有这样的困难因为每个模块小组独立他们可以独立部署独立发布独立测试就算你的用户业务模块出现了问题延迟进行发布但不会影响我订单业务模块的测试发布而且每个独立项目上线之后我们可以各个小组都可以对他们自己负责的业务进行独立的升级和快速的验证是否可用。1.5. 从资源分配的角度来看合理调配。假设我们整个集群有10000台机器我们这里可以根据不同业务的繁忙程度分配不同的机器假设用户搜索业务最繁忙分配5000台机器订单服务较为繁忙分配4000台机器库存业务模块不太繁忙只分配1000台机器足以那么这些都是在微服务中可以实现的。而在单体项目中就无法做到如此精细。1.6. 从事务差错处理的角度来看细粒度容错。从服务差错处理角度来讲微服务也比单体项目要好很多限流与降级熔断是我们微服务中一个很重要的环节在微服务中我们可以给每一个业务定制非常细粒度的限流与降级熔断措施但单体项目就不可以它的耦合程度过高。举一个最简单的例子在单体项目中由于我们的业务都写在一起很多操作写在同一个事务中假设我们一个事务中的一个小环节出现了一点点差错如写数据库操作失败就要马上回滚结束事务。但是在微服务架构里面我们经常会有一些熔断降级的措施还是写数据库失败我们可以做一个降级把这个写数据库的操作打到缓存当中或者打入MQ消息组件当中采用异步处理写库的方式这就是一个很常见的降级补偿的措施在单体项目中根本无法做到这么精细力度的容错处理。1.7. 从业务耦合度的角度来看业务解耦。在单体项目中他们的业务之间都掺杂在了一起没有很明确的界限而且数据库较为集中项目的所有有关表的数据都放在一个数据库中处理业务时都是直接在同一个数据库的几张表上进行读写操作。比如说我的支付下单操作可以直接去商品表中进行读写操作商品接口也能到下单的数据库中进行读写操作如果有朝一日我的某个数据库表需要修改那么有关该表所有的业务都会受牵连造成的损失是非常大的。但是在微服务项目中就可以避免这些问题的发生我们的业务模块进行拆分同时把数据库也进行拆分支付下单功能有自己的独立的数据库表商品库存也有自己的独立的数据库表当我支付下单功能要对库存表进行读写的时候只需要通过远程调用调用库存业务模块的操作让库存业务模块中的接口去读写自己的数据库实现了数据库的隔离操作而且后续如果对数据库的表做改变我们也只需要改动对应的业务模块中的方法即可只要对外暴露的业务接口保持不变就不会对其他业务有影响。从而规范了业务流程也规范了数据的访问对数据库的安全性作到了一定的保障。二.微服务的弊。2.1. 一个字贵相比于单体项目微服务的成本是要更高一些的如果我们想要做一个小型项目只有几个简单的业务做一个单体项目图个方便图个便宜也是不错的选择。但如果想要好的还得用钱砸出来做更全面作为服务项目我们刚才也说了微服务的一些好处所以它也是要比单体项目成本更高的。2.2. 部署结构复杂。其实要说微服务结构复杂倒也不复杂就现在而言微服务的技术已经非常成熟以前的很多问题和困难到现在已经被很多框架屏蔽解决了是不需要我们开发人员管理的但相比于单体项目而言还是要复杂一点的。总结综合考虑微服务的好处还是很多的而且现在互联网行业的趋势也表明了微服务活力还是非常旺盛的现在几乎所有的企业都在使用微服务架构那些没有使用微服务的也在逐渐向微服务转变。