微服务架构的优缺点

什么是微服务
微服务是用一组小服务构建的一个应用,服务运行在不同的进程中,服务之间通过轻量的通讯机制进行交互,并且服务可以通过自动化部署方式独立部署。正因为微服务架构中,服务之间是相互独立的,所以不同的服务可以使用不同的语言来开发,或者根据业务的需求使用不同类型的数据库。
优点
1、服务解耦
将原有的巨大的单体应用拆分为多个独立的微服务,使得每个服务更专注于自己的业务,满足高内聚低耦合的设计原则。比如将电商服务差费为用户服务、账户服务、商品服务、购物车服务、订单服务等。

2、独立的开发环境
将应用拆分为独立的微服务,服务之间彼此隔离,通过轻量级的通讯机制(比如:dubbo)进行交互,使得开发时无需关注具体的开发环境,只需要协商好通讯机制即可。

3、独立的部署环境
微服务拥有独立的开发环境,因此需要根据各自的开发环境规划部署环境,对于访问量大的服务可以增加服务的部署数量,访问量小的服务适当的减少部署数量。

4、更高的扩展性
基于服务的独立性,服务之间的耦合性降低,无论从功能上,还是架构上,我们都可以进行更为灵活的扩展,而不影响其他服务。

缺点
1、通讯机制的不标准问题
微服务之间相互独立,但是服务间的交互需要依赖规范的通讯机制,没有规范的通讯机制作为桥梁,服务间交互将变得非常复杂。保证规范的通讯机制,是微服务的前提。

2、事务一致性问题
单体应用通过数据库事务保证一致性,拆分为微服务后,会形成分布式处理的业务,进而就会产生分布式事务一致性问题。分布式系统的事务一致性本身就是一个技术难题,目前没有一种很简单很完美的方案能够应对所有场景。分布式系统的一个难点就是因为“网络通信的不可靠”,只能通过“确认机制”、“重试机制”、“补偿机制”等各方面来解决一些问题。在综合考虑可用性、性能、实现复杂度等各方面的情况上,比较好的选择是“异步确保最终一致性”,只是具体实现方式上有一些差异。

3、服务间的依赖变得复杂
需要根据业务的重要性进行系统梳理,定义出关键业务和非关键业务;梳理服务调用的主要路径,明确强弱依赖、限流、降级规则等。服务治理就是基于以上规则进行的,否则无法进行系统运维或管理。比如非关键业务被关键业务所依赖,会导致非关键业务变成关键业务,服务链中就会出现“木桶效应”,即整个服务质量由最差的那个服务所决定。

数据库也需要做相应的隔离:避免非关键业务把数据库拖死,进而导致全站不可用。不允许直接读取对方的数据库进行系统交互,只允许通过服务接口进行系统交互。这也是微服务的要求:拆分服务和相应数据库。

应避免服务间的循环调用,如果产生循环引用,需要通过架构层面解决循环问题,避免因循环引用导致的系统奔溃问题。同时要对接口进行降级、限流控制,以应对系统的高并发。

4、微服务运维变得复杂
微服务的架构一般会包含基础层、中间件层、应用层、接入层、安全层,同时需要有相应的团队负责各层的运维。各层之间有比较明确的职责,共同支撑着整个系统的运行。一旦某个环节出现问题,整个系统就会像 “多米诺骨牌”一样倒下。因此需要统一的运维平台,实时监控服务调用链路,及时发现和定位问题。而建立统一的运维平台的成本和难度是相当之大的,目前也只有几家互联网大公司拥有这种能力。

5、系统监控变得复杂
对系统的监控依赖于系统的调用链路,链路中包含:http请求、服务间调用、消息队列、数据库、nosql、线程间调用等,如何将监控整个链路将变得非常困难,可能需要修改各中间件的请求数据包。

6、系统测试变得复杂
由于服务的依赖变得复杂,在进行系统测试时,要考虑服务间强弱依赖、降级、限流等问题。在进行压测时要考虑依赖的服务的性能。在制造测试场景时应充分考虑各服务的数据量,避免出现测试误差。

更多Java学习资料可关注:gzitcast

发布了831 篇原创文章 · 获赞 4 · 访问量 11万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览