Java高级架构:微服务架构的核心概念

作者 : 开心源码 本文共2299个字,预计阅读时间需要6分钟 发布时间: 2022-05-12 共189人阅读

微服务现在辣么火,业界流行的比照的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者者说SOA(面向服务架构)是什么区别呢?

我们先看相同点:

  • 需要Registry,实现动态的服务注册发现机制;
  • 需要考虑分布式下面的事务一致性,CAP准则下,两段式提交不能保证性能,事务补偿机制需要考虑;
  • 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息;
  • 都需要统一的Gateway来汇聚、编排接口,实现统一认证机制,对外提供APP使用的RESTful接口;
  • 同样的要关注如何再分布式下定位系统问题,如何做日志跟踪,就像我们电信领域做了十几年的信令跟踪的功能;

不相同点:

  • 是持续集成、持续部署?对于CI、CD(持续集成、持续部署),这本身和敏捷、DevOps是交织在一起的,我认为这更倾向于软件工程的领域而不是微服务技术本身;
  • 使用不同的通讯协议是不是区别?微服务的标杆通讯协议是RESTful,而传统的SOA一般是SOAP,不过目前来说采用轻量级的RPC框架Dubbo、Thrift、gRPC非常多,在Spring Cloud中也有Feign框架将标准RESTful转为代码的API这种仿RPC的行为,这些通讯协议不应该是区分微服务架构和SOA的核心差别;
  • 是流行的基于容器框架还是虚拟机为主?Docker和虚拟机还是物理机都是架构实现的一种方式,不是核心区别;

微服务架构的精髓在切分

服务的切分上有比较大的区别,SOA本来是以一种“集成”技术出现的,很多技术方案是将原有企业内部服务封装为一个独立进程,这样新的业务开发即可重用这些服务,这些服务很可能是相似供应链、CRM这样的非常大的颗粒;而微服务这个“微”,就说明了他在切分上有讲究,不妥协。无数的案例证实,假如你的切分是错误的,那么你得不到微服务承诺的“低耦合、更新不影响、可靠性高”之类的优势,而会比使用Monolithic有更多的麻烦。

不拆分存储的微服务是伪服务:在实践中,我们常常见到一种架构,后台存储是一律和在一个数据库中,仅仅把前台的业务逻辑拆分到不同的服务进程中,本质上和一个Monolithic一样,只是把板块之间的进程内调用改为进程间调用,这种切分不可取,违背了分布式第一准则,板块耦合没有处理,性能却受到了影响。

分布式设计第一准则 — “不要分布你的对象”

微服务的“Micro”这个词并不是越小越好,而是相对SOA那种粗粒度的服务,我们需要更小更合适的粒度,这种Micro不是无限制的小。

假如我们将两路(同步)通信与小/微服务结合使用,并根据比方“1个类=1个服务”的准则,那么我们实际上回到了使用Corba、J2EE和分布式对象的20世纪90年代。遗憾的是,新生代的开发人员没有使用分布式对象的经验,因而也就没有认识到这个主意多么糟糕,他们正试图重复历史,只是这次使用了新技术,比方用HTTP取代了RMI或者IIOP。

微服务和Domain Driven Design

一个简单的图书管理系统一定无需微服务架构。既然采用了微服务架构,那么面对的问题空间必然是比较宏大,比方整个电商、CRM。

如何拆解服务呢?

使用什么样的方法拆解服务?业界流行1个类=1个服务、1个方法=1个服务、2 Pizza团队、2周能重写完成等方法,但是这些都缺乏实施基础。我们必需从少量软件设计方法中寻觅,面向对象和设计模式适用的问题空间是一个板块,而函数式编程的理念更多的是在代码层面的微观上起作用。

Eric Evans 的《领域驱动设计》这本书对微服务架构有很大借鉴意义,这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来说,这是一个最正当的处理拆分问题的方案,透过限界上下文(Bounded Context,下文简称为BC)这个概念,我们能将实现细节封装起来,让BC都能够实现SRP(单一职责)准则。而每个微服务正是BC在实际世界的物理映射,符合BC思路的微服务互相独立松耦合。

微服务架构是一件好事,逼着大家关注设计软件的正当性,假如原来在Monolithic中领域分析、面向对象设计做不好,换微服务会把这个问题成倍的放大

以电商中的订单和商品两个领域举例,按照DDD拆解,他们应该是两个独立的限界上下文,但是订单中一定是包含商品的,假如贸然拆为两个BC,查询、调用关系就耦合在一起了,甚至有了麻烦的分布式事务的问题,这个关联如何拆解?BC理论认为在不同的BC中,即便是一个术语,他的关注点也不一样,在商品BC中,关注的是属性、规格、介绍等等(实际上商品BC这个领域有价格、库存、促销等等,把他作为单独一个BC也是不正当的,这里为了简化例子,大家先认为商品BC就是商品基础信息), 而在订单BC中更关注商品的库存、价格。所以在实际编码设计中,订单服务往往将关注的商品名称、价格等等属性冗余在订单中,这个设计解脱了和商品BC的强关联,两个BC可以独立提供服务,独立数据存储

小结

微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念,也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架,而是服务的边界、职责划分,划分错误就会陷入大量的服务间的相互调用和分布式事务中,这种情况微服务带来的不是便利而是麻烦。

【文章福利】

小编推荐一个Java交流群:937053620,群内提供设计模式、spring/mybatis源码分析、高并发与分布式、微服务、性能优化,面试题整理合集等免费资料!

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » Java高级架构:微服务架构的核心概念

发表回复