29

一起玩转微服务(8)——服务拆分原则

 4 years ago
source link: http://www.cnblogs.com/skyme/p/13171742.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

服务拆分

拆分粒度不应该过分追求细粒度,要考虑适中不能过大或过小。按照单一职责原则和康威定律,在业务域、团队还有技术上平衡粒度。拆分后的代码应该是易控制,易维护的,业务职责也是明确单一的。 AKF扩展立方体,是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式,可以将一个单体系统,进行无限扩展。AKF扩展立方如图所示。

bmAnAne.png!web

•X 轴 :水平复制,即在负载均衡服务器后增加多个web服务器。•Y 轴 :功能分解,将不同职能的模块分成不同的服务。从y轴这个方向扩展,才能将巨型应用分解为一组不同的服务,例如订单管理中心、商品信息管理中心、库存管理中心等等。•Z 轴 :对数据库的扩展,即分库分表(分库是将关系紧密的表放在一台数据库服务器上,分表是因为一张表的数据太多,需要将一张表的数据通过hash放在不同的数据库服务器上)。

三个维度的扩展对比如表所示:

ZV7NNvF.png!web

AKF

业界对于可扩展的系统架构设计有一个朴素的理念,就是: 通过加机器(水平扩展)就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。

段子:( 世界上没有什么事是一顿烧烤不能解决的。如果有,那就两顿 。)

这一理念在“云计算”概念疯狂流行的今天,得到了广泛的认可!对于一个规模迅速增长的系统而言,容量和性能问题当然是首当其冲的。但是随着时间的向前,系统规模的增长,除了面对性能与容量的问题外,还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。而许多系统,在架构设计时并未充分考虑到这些问题,导致系统的重构成为常态,从而影响业务交付能力,还浪费人力财力!对此,《可扩展的艺术》一书提出了一 个更加系统的可扩展模型—— AKF 可扩展立方(Scalability Cube)。这个立方体中沿着三个坐标轴设置分别为:X、Y、Z。

下面看一下AKF的拆分实践:

拆分应用

•X轴:从单体系统或服务,水平克隆出许多系统,通过负载均衡平均分配请求。•Y轴 :面向服务分割,基于功能或者服务分割,例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分,每一组服务再进行X轴的扩展。•Z轴 :面向查找分割,基于用户、请求或者数据分割,例如可以将不同产品的SKU分到不同的搜索服务,可以将用户哈希到不同的服务等。

拆分数据库

•X轴:从单库,水平克隆为多个库上读,一个库写,通过数据库的自我复制实现,要允许一定的读写时延。•Y轴 :根据不同的信息类型,分割为不同的数据库,即分库,例如产品库,用户库等。•Z轴 :按照一定算法,进行分片,例如将搜索按照MapReduce的原理进行分片,把SKU的数据按照不同的哈希值进行分片存储,每个分片再进行X轴冗余。

总结

要做好微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。 对于服务的拆分,要使用迭代演进的方式,不能一次性完成所有的服务的拆分,需要确保团队可接受,粒度适中,同时需要优先考虑API的版本兼容性。不能够单纯以代码量来对服务拆分的成果进行评估。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK