多研究些架构,少谈些框架——一名阿里架构师的微服务笔记
Posted 训练营资料福利官
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了多研究些架构,少谈些框架——一名阿里架构师的微服务笔记相关的知识,希望对你有一定的参考价值。
微服务架构和SOA区别微服务现在辣么火,业界流行的对比的却都是所谓的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不是无限制的小。
微服务和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这些技术框架,而是服务的边界、职责划分,划分错误就会陷入大量的服务间的相互调用和分布式事务中,这种情况微服务带来的不是便利而是麻烦。 DDD给我们带来了合理的划分手段,但是DDD的概念众多,晦涩难以理解,如何抓住重点,合理的运用到微服务架构中呢? 我认为如下的几个架构思想是重中之重
- 充血模型
- 事件驱动
上文我们聊了微服务的DDD之间的关系,很多人还是觉得很虚幻,DDD那么复杂的理论,聚合根、值对象、事件溯源,到底我们该怎么入手呢? 实际上DDD和面向对象设计、 设计模式 等等理论有千丝万缕的联系,如果不熟悉OOA、OOD,DDD也是使用不好的。不过学习这些OO理论的时候,大家往往感觉到无用武之地,因为大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的(Action、Service、Dao),在这种分层理论中,我们基本没有啥机会使用那些所谓的“行为型”的设计模式,这里的核心原因,就是J2EE经典分层的开发方式是“贫血模型”。 Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”,这两种开发分别对应了“贫血模型”和“充血模型”。
事务脚本开发模式
事务脚本的核心是过程,可以认为大部分的业务处理都是一条条的SQL,事务脚本把单个SQL组织成为一段业务逻辑,在逻辑执行的时候,使用事务来保证逻辑的ACID。最典型的就是存储过程。当然我们在平时J2EE经典分层架构中,经常在Service层使用事务脚本。 使用这种开发方式,对象只用于在各层之间传输数据用,这里的对象就是“贫血模型”,只有数据字段和Get/Set方法,没有逻辑在对象中。 我们以一个库存扣减的场景来举例:
- 业务场景
- 贫血模型的设计
1 2 3 4 5 6 | public class Stock private String spuId; private String skuId; private int stockNum; private int orderStockNum; |
- Service入口
1 2 3 4 5 6 7 | count = select stocknum from stock where spuId=xx and skuid=xx if count>num update stock set stocknum=stocknum-num, orderstocknum=orderstocknum+num where skuId=xx and spuId=xx else //库存不足,扣减失败 insert stock_log set xx=xx, date= new Date() |
- ok,打完收工,如果做的好一些,可以把update和select count合一,这样可以利用一条语句完成自旋,解决并发问题(高手)。
- 马丁福勒定义的“贫血模型”是反模式,面对简单的小系统用事务脚本方式开发没问题,业务逻辑复杂了,业务逻辑、各种状态散布在大量的函数中,维护扩展的成本一下子就上来,贫血模型没有实施微服务的基础。
- 虽然我们用Java这样的面向对象语言来开发,但是其实和过程型语言是一样的,所以很多情况下大家用数据库的存储过程来替代Java写逻辑反而效果会更好,(ps:用了Spring boot也不是微服务),
领域模型的开发模式
- 领域模型是将数据和行为封装在一起,并与现实世界的业务对象相映射。各类具备明确的职责划分,使得逻辑分散到合适对象中。这样的对象就是“充血模型” 。
- 在具体实践中,我们需要明确一个概念,就是领域模型是有状态的,他代表一个实际存在的事物。还是接着上面的例子,我们设计Stock对象需要代表一种商品的实际库存,并在这个对象上面加上业务逻辑的方法
- 充血模型的缺点
领域模型和微服务的关系
上面讲了领域模型的实现,但是他和微服务是什么关系呢?在实践中,这个Inventory是一个限界上下文的聚合根,我们可以认为一个聚合根就是一个微服务进程。 不过问题又来了,一个库存的Inventory一定和商品信息是有关联的,仅仅靠Inventory中的冗余那点商品ID是不够的,商品的上下架状态等等都是业务逻辑需要的,那不是又把商品Sku这样的重型对象引入了这个微服务?两个重型的对象在一个服务中?这样的微服务拆不开啊,还是必须依靠商品库?!
接上文,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。
事务一致性
事务一致性的问题在Monolithic下面不是大问题,在微服务下面却是很致命,我们回顾一下所谓的ACID原则
- Atomicity – 原子性,改变数据状态要么是一起完成,要么一起失败
- Consistency – 一致性,数据的状态是完整一致的
- Isolation – 隔离线,即使有并发事务,互相之间也不影响
- Durability – 持久性, 一旦事务提交,不可撤销
推荐一个交流学习群:688583154里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多:
事件驱动实现最终一致性
事件驱动架构在领域对象之间通过异步的消息来同步状态,有些消息也可以同时发布给多个服务,在消息引起了一个服务的同步后可能会引起另外消息,事件会扩散开。严格意义上的事件驱动是没有同步调用的。 例子: 在订单服务新增订单后,订单的状态是“已开启”,然后发布一个Order Created事件到消息队列上 库存服务在接收到Order Created 事件后,将库存表格中的某sku减掉可销售库存,增加订单占用库存,然后再发送一个Inventory Locked事件给消息队列 订单服务接收到Inventory Locked事件,将订单的状态改为“已确认” 有人问,如果库存不足,锁定不成功怎么办? 简单,库存服务发送一个Lock Fail事件, 订单服务接收后,把订单置为“已取消”。
好消息,我们可以不用锁 ! 事件驱动有个很大的优势就是取消了并发,所有请求都是排队进来,这对我们实施充血模型有很大帮助,我们可以不需要自己来管理内存中的锁了。取消锁,队列处理效率很高,事件驱动可以用在高并发场景下,比如抢购。
是的,用户体验有改变 , 用了这个事件驱动,用户的体验有可能会有改变,比如原来同步架构的时候没有库存,就马上告诉你条件不满足无法下单,不会生成订单;但是改了事件机制,订单是立即生成的,很可能过了一会系统通知你订单被取消掉。 就像抢购“小米手机”一样,几十万人在排队,排了很久告诉你没货了,明天再来吧。如果希望用户立即得到结果,可以在前端想办法,在BFF(Backend For Frontend)使用CountDownLatch这样的锁把后端的异步转成前端同步,当然这样BFF消耗比较大。
没办法,产品经理不接受 , 产品经理说用户的体验必须是没有库存就不会生成订单,这个方案会不断的生成取消的订单,他不能接受,怎么办?那就在订单列表查询的时候,略过这些cancel状态的订单吧,也许需要一个额外的视图来做。我并不是一个理想主义者,解决当前的问题是我首先要考虑的,我们设计微服务的目的是本想是解决业务并发量。而现在面临的却是用户体验的问题,所以架构设计也是需要妥协的:( 但是至少分析完了,我知道我妥协在什么地方,为什么妥协,未来还有可能改变。
多个领域多表Join查询
- 我个人认为聚合根这样的模式对修改状态是特别合适,但是对搜索数据的确是不方便,比如筛选出一批符合条件的订单这样的需求,本身聚合根对象不能承担批量的查询任务,因为这不是他的职责。那就必须依赖“领域服务(Domain Service)”这种设施。
- 我们的查询任务往往很复杂,比如查询商品列表,要求按照上个月的销售额进行排序; 要按照商品的退货率排序等等。但是在微服务和DDD之后,我们的存储模型已经被拆离开,上述的查询都是要涉及订单、用户、商品多个领域的数据。如何搞? 此时我们要引入一个视图的概念。比如下面的,查询用户名下订单的操作,直接调用两个服务自己在内存中join效率无疑是很低的,再加上一些filter条件、分页,没法做了。于是我们将事件广播出去,由一个单独的视图服务来接收这些事件,并形成一个物化视图(materialized view),这些数据已经join过,处理过,放在一个单独的查询库中,等待查询,这是一个典型的以空间换时间的处理方式。
限界上下文(Bounded Context)和数据耦合
除了多领域join的问题,我们在业务中还会经常碰到一些场景,比如电商中的商品信息是基础信息,属于单独的BC,而其他BC,不管是营销服务、价格服务、购物车服务、订单服务都是需要引用这个商品信息的。但是需要的商品信息只是全部的一小部分而已,营销服务需要商品的id和名称、上下架状态;订单服务需要商品id、名称、目录、价格等等。这比起商品中心定义一个商品(商品id、名称、规格、规格值、详情等等)只是一个很小的子集。这说明不同的限界上下文的同样的术语,但是所指的概念不一样。 这样的问题映射到我们的实现中,每次在订单、营销模块中直接查询商品模块,肯定是不合适,因为
- 商品中心需要适配每个服务需要的数据,提供不同的接口
- 并发量必然很大
- 服务之间的耦合严重,一旦宕机、升级影响的范围很大。
保证最终一致性
最终一致性成功依赖很多条件
- 依赖消息传递的可靠性,可能A系统变更了状态,消息发到B系统的时候丢失了,导致AB的状态不一致
- 依赖服务的可靠性,如果A系统变更了自己的状态,但是还没来得及发送消息就挂了。也会导致状态不一致
推荐一个交流学习群:688583154里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多:
使用本地事务
还是以上面的订单扣取信用的例子
- 订单服务开启本地事务,首先新增订单;
- 然后将Order Created事件插入一张专门Event表,事务提交;
- 有一个单独的定时任务线程,定期扫描Event表,扫出来需要发送的就丢到MQ,同时把Event设置为“已发送”。
使用Event Sourcing 事件溯源
事件溯源对我们来说是一个特别的思路,他并不持久化Entity对象,而是只把初始状态和每次变更的Event记录下来,并在内存中根据Event还原Entity对象的最新状态,具体实现很类似数据库的Redolog的实现,只是他把这种机制放到了应用层来。 虽然事件溯源有很多宣称的优势,引入这种技术要特别小心,首先他不一定适合大部分的业务场景,一旦变更很多的情况下,效率的确是个大问题;另外一些查询的问题也是困扰。
我们仅仅在个别的业务上探索性的使用Event Souring和AxonFramework,由于实现起来比较复杂,具体的情况还需要等到实践一段时间后再来总结,也许需要额外的一篇文章来详细描述
关注微信公众号:“Java架构师学习”获取学习资源
以上是关于多研究些架构,少谈些框架——一名阿里架构师的微服务笔记的主要内容,如果未能解决你的问题,请参考以下文章