服务到底如何拆、同一个接口为什么用微服务架构模式改造后的响应时间比单体应用的响应时间要长,而且服务变的不稳定。原本使用一个事物注解就能保障数据一致性,是如何保证的?需要什么措施可以保证?
微服务到底如何拆要注意以下两个方面
第一个是划分服务的时候,按照业务流程的步骤进行划分,这是开发人员传统的面向过程的思维定势造成的。也可能是传统的SOA过度而来的一种划分方式。这种划分微服务的最大缺点在于,服务与服务之间存在很强耦合性,服务的优雅降级无从做起,而且还存在大量的跨机事务需要解决。
另外一个问题就是基础功能或是公共代码的问题,开始采用微服务架构时,很多项目喜欢讲基础功能独立成为一个服务,这些基础功能不是业务功能,而是一部分公用的非独立的功能。在项目的初期,这种设计确实是提高了代码的复用,但是随着系统需求的变化,这些基础服务会被频繁修改,导致变得复杂难以维护。这种为了实现代码共享的基础服务,破坏了服务自治的约束,提高了部署和运维的难度,降低了系统的可用性。
服务如何拆分:
按照业务功能分解模式进行分解是最简单的,只需把业务功能相似的模块聚集在一起。比如:
用户管理:管理用户相关的信息,例如注册、修改、注销或查询、统计等。
商品管理:管理商品的相关信息。
业务功能分解模式另外的优势在于在初级阶段服务拆分不会太小 ,等到业务发展起来后可以再根据子域方式来拆分,把独立的服务再拆分成更小的服务,最后到接口级别服务。 以用户管理举例,在初始阶段的做服务拆分的时候,把用户管理拆分为用户服务,且具备了用户的增删改查功能,在互联网中流量获客是最贵的,运营团队通过互联网投放广告获客,用户在广告页上填写手机号码执行注册过程,如果此时注册失败或者注册过程响应时间过长,那么这个客户就可能流失了,但是广告的点击费用产生了,无形中形成了资源的浪费。当用户规模上升之后需要对增删改查功能做优先级划分,所以此时需要按方法维度来拆分服务,把用户服务拆分为用户注册服务(只有注册功能),用户基础服务(修改、查询用户信息)。
分布式后比单体应用时间长了
一个应用功能被拆分成多个服务之后,原本调用一个接口就能完成的功能如今变成需要调用多个服务,如果按顺序逐个调用的话,使用微服务改造后的接口会比原始接口响应时间更长, 因此要把原本串行调用的服务修改为并行调用,同时原本通过 SQL 的 join 多表联合查询操作变成单表操作,然后在聚合层的内存中做拼接。
分布式事物
使用MQ方案,通过柔性事物来解决数据最终一致性。