Home | 简体中文 | 繁体中文 | 杂文 | 知乎专栏 | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 视频教程 | 打赏(Donations) | About
知乎专栏多维度架构 微信号 netkiller-ebook | QQ群:128659835 请注明“读者”

13.4. 多维度架构之微服务拆分

最近在群里有人问关闭分布式事务的话题,详细听了他们需求后。我呵呵一笑,大约在15年前我就遇到过这种问题。

起因是这样的,这是一个电商系统,架构师给出的架构是这样的:

		
用户中心:负责用户注册,登录,用户信息,钱包管理……
商品中心:负责商品的管理,包括展示,价格和库存管理……
广告中心:负责商品推广,促销……
物流中心:负责订单的物流……
等等中心:负责等等……		
		
		

每个中心都有一个独立域名例如:

		
user.domain.com
product.domain.com
ad.domain.com
search.domain.com
m.domain.com
……		
		
		

这种架构设计会存在一个问题,用户每下一个订单,都需要连接多个中心,做一连串调用,最终完成下订单这个功能。因为用户可能操作过程中终止购物流程,或者不可抗因素导致流程无法继续。为此需要设计了一种分布式事务系统,用来解决事务回滚的问题。

所谓的分布式事务,是指跨服务器实现数据库生成与回滚操作,例如:用户购物,浏览商品,添加购物车,选择物流方式…… 这些数据产生在不同服务器上,如果用户取消订单,数据将依次反向回滚。

无独有偶,另一个跨境电商公司的同事也遇到了这种问题,苦苦找不到解决方案,想起了我,询问我的意见。

有时候你会发现,人们会陷入思维边界的陷阱,全力以赴在错误的方向上,无法自拔。

首先,划分中心的架构思维,之所以会出现这种划分方法,我认为跟我们的教育方式有关,导致了多数人都会沿用这种思维定式。

其次,分布式服务的确能解决他们遇到的问题,能想到分布式事务,证明他们智商没有问题。但分布式事务不是最优解,是最差解决方案。

最后,出现了南辕北辙,在错误方向的道路上越走越远。

13.4.1. 分布式事务之路

大约在15年前我们也遇到了这个问题,幸好我及时出手纠正了架构设计的误区,从而没有走上分布式事务之路。

那时还没有微服务的概念,也没有容器技术,我们主要使用物理服务器,在服务器上运行多个实例。从BAT高薪挖来的架构师的思路跟上面一样,将应用划分成各种中心,并且要求每个中心都部署在独立物理机上。划分中心这种方式也与当时的开发模式有关,采用敏捷开发,分成多个小组,每个小组负责一个中心,小组间定义好信通接口,然后所有小组马力全开,活就一起开干了。现在想想简单又粗暴,就如人体器官一样,五脏六腑的联系不是通过一条神经实现的,他们的联系十分复杂。所以我们不能单独思考每个中心,然后就认为把它们合起来就是一个整体。

如果再继续下去,我们一定会去研发分布式事务。

此时有一个更好的机会等着我,于是我提出了离职申请,反正是准备离开了,也不怕得罪人,我想我应该在离职之前把这些问题跟公司说一下。

13.4.2. 微服务拆分法则

我向公司反映了目前面临的所有问题,并且提出了两个概念:

  1. 基于工作流拆分服务:服务的拆分法则,基于工作流拆分服务,确保该工作流运行在一个实例中。
  2. 服务器即是服务池:所有物理机应该是一个服务池,根据我们的需求,可以将它部署成任何服务。

13.4.2.1. 基于工作流拆分服务

上面提出的两点,直到今天也仍然适用,例如在微服务的拆分中。在我的职业生涯中,这两个概念始终在指导我的团队。下面我详细说明两个概念怎样应用到实际的工作中。

我们还以电商系统举例,用户下单购物的工作流,如果是按照中心划分,流程可能是这样的:

				
用户 —> 商品中心(浏览) —>  搜索中心(过滤)—> 用户中心(添加购物车)—> 物流中心 (物流方式) —> 结算中心(支付结算/扣积分)—> 商品中心(扣库存)—> 用户中心 (完成)
				
				

数据流在,商品中心,搜索中心,用户中心…… 服务器中不断传递,网络延迟,网络超时,网络故障等等任何错误都可能影响用户体验。

如果是运行在一个实例中呢?确切的说,我们需要让工作流运行在一个服务器上,一个CPU、内存和硬盘上。这样就没有分布式事务的需求了,数据库的事务处理解决了所有的问题,就这么简单!!!

基于这种法则,我们将几套工作流归类,放在一个实例中,放在今天就是微服务。同样微服务的拆分也尽量满足一套工作流在一个微服务客户端上,避免请求过程出现,一个微服务调用另一个微服务的情况。

13.4.2.2. 服务池的概念

服务器即是服务池的意思是,做到服务于服务器无关,与IP地址无关,通过运维手段,可以将服务器部署成任何服务,这样可以最大化利用硬件资源,不至于一些服务器资源闲置,而另一些则满负荷工作。这样更容易调配服务器资源。

这种概念在今天的容器中得到了更好的实现。

13.4.3. 最后总结

还是那句话架构设计是做减法,不是堆技术。你需要从整体考虑,整体不等于个体的总和,这就是多维度思维。

分布式事务目前有成熟的解决方案,但是能不用在高并发,长工作流的需求上,这种方案增加了系统的复杂度。导致开发复杂,测试难度大,运维难,故障多。