
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
任何编程开发技术都是有两面性的,我们在上文中给大家简单介绍了微服务架构开发的优势等内容,而本文我们就再来学习一下,微服务架构的缺点都有哪些。
运维难度增加
本来只需要部署一个IIS站点或者Tomcat服务、维护一个数据库,现在变成了需要部署N个不同的服务,N个不同类型的数据库。不同的服务甚至可能分散在不同的服务器上。要使这些服务正常的工作,正常的通讯,还要对其进行监控显然比单体架构时代对运维的考验提高了一个维度。没有强大的运维团队、自动化的运维工具的话微服务实施起来出故障的概率显然会大大增加。
分布式的挑战
微服务架构天然就是分布式的。但是分布式系统会带来很多单体架构没有的问题。比如分布式事务,数据一致性问题。本来在进程内一个锁或者在数据库开一个事务就能解决的事情,现在不得不借助分布式锁、分布式事务、数据终一致性来处理。这些问题对开发人员写代码的时候也是很大的挑战。除了一致性的问题,微服务架构中服务之间的通信也会有很高的成本。本来进程内的方法调用变成了跨进程、跨服务的通讯。我们知道网络是不可靠的,出现故障的概率远远超过进程内调用。
调试,测试难度增加
由于服务之间互相依赖,在做集成测试或者调试的时候需要把所有依赖的服务、数据库等全部都跑起来。出现问题很难一次性定位到确切位置。由于服务器之间网络带宽的原因多次测试结果可能会有变动,测试的结果不稳定。
沟通成本提高
在采用微服务架构开发之后,团队的组织架构都可能跟着变动,团队免不了被拆分成多个小团队甚至不同部门。在公司呆过的都知道,跨团队跨部门之间沟通的成本有多大。本来一天就能修复的bug,很可能变成一周。
模块划分困难
我们前面说微服务把每个模块进行独立部署,采用独立的数据库。这么轻描淡写的一句话,事实上实施起来并没有那么容易。如果模块划分的不好,那么会出现非常多的跨库查询,非常多的跨库事务。本来单体架构上很简单的事情变得无比复杂。本来一句Transaction就你搞定的事情,现在可能需要先团队之间进行沟通,然后互相开接口,再使用分布式事务来完成。模块划分的一个好的方案就是采用DDD的思想进划分,但是事实上能把DDD玩好落地也不是一件容易的事。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。