行业资讯

帮助中心 >  产品文档 >  架构 >  构架设计与拆分的哲学

(一)、架构拆分方式

我们谈架构,架构分为:服务和数据两部分(DB、Cache、ES等等)。架构设计要适度,要能否满足企业未来6-24个月的业务需求增长,避免过度设计。


架构设计与拆分的哲学1.webp_副本.jpg


接下来,我们先看单体应用。单体应用遵循MVC结构。典型的单体应用组网拓扑如下所示:


架构设计与拆分的哲学2.webp_副本.jpg


在单体应用中,有三个模块,每个模块都有各自的MVC层。同样,在数据库中,针对三个模块,也会有三个表。如果单体应用能做到无状态化,也能做到横向扩展。


架构设计与拆分的哲学3.webp_副本.jpg


但是上面的应用将是一个“巨无霸”,我们无法对其中一个功能组件单独升级。而且,如果想给单体应用增加新的功能模块,需要重新开发,整体替换。因为,要对这个单体应用进行解耦。那么,单体应用如何解耦?

按照领域,对数据库进行纵向切分,也就是分库,如下图所示:


架构设计与拆分的哲学4.webp_副本.jpg


随着用户数量化的增加,单一数据库表已经不成了,需要分表。拆表的时候,以常用的列作为主键,例如UID,然后将表拆分,也就是数据库水平拆分:


架构设计与拆分的哲学5.webp_副本.jpg


当然,我们可以使用NewSQL,屏蔽数据库分库分表的操作。

随着业务访量的继续增加,需要拆分应用。

首先根据业务领域对应用进行垂直拆分,即把一个大的单体应用,拆成三个小的单体应用:


架构设计与拆分的哲学6.webp_副本.jpg


接下来,按照功能对小的单体应用按照功能进行水平拆分:


架构设计与拆分的哲学7.webp_副本.jpg


拆分后的应用变成了微服务架构。这时网关包含两部分内容:网关业务逻辑、通信部分(限流、熔断等)。而Service Mesh,相当于对微服务进行进一步拆分,将业务逻辑层和通讯部分拆开。

(二)、SOA的架构落地

1.多个单体服务 2、多个单体服务之前用ESB连接。


架构设计与拆分的哲学8.webp_副本.jpg


1.SOA

SOA的缺点是:仅按照垂直方向拆分业务,每个服务还是单体的。ESB实现服务间的异步调用。

那么,ESB与MQ有什么区别呢?


架构设计与拆分的哲学9.webp_副本.jpg


2.在微服务架构中,API网关都做什么事情?

(1).请求鉴权

(2).即通用参数检查(只看参数填没填)。

App到网关的通信协议是https、传输协议是Json。Json是放在Http body中的。传输数据包=定长header(占24个字节uid、cmd、sessionid、body length)+变长body(k1v1;k2v2)。
其中边长body时候具体的语义,不需要API做检查。定长header会被网关检查,即通用参数检查。

(3). 协议转换:将文本协议Json转化为二进制协议,如PG,Mgmpak,hashmap(string,object)等。扩展性更好。

(4).通信协议转换:App到网关的http请求是一个短链接。网关将其转化为TCP(如RPC)。

(5).路由转发

(6).微服务治理(熔断限流等)

3.数据访问层的作用:

(1)、批量的CRUD接口

(2)、ORM

(3)、Sharding的工作(分布分表)。这步最难,如果用NewSQL就可以规避。

(4)、屏蔽底层DB差异性

(三)、微服务架构的异步实现

此外,如果我们要提升微服务的性能,可以在API网关和业务逻辑层之间增加MQ。这样,虽然网关到MQ是同步调用、MQ到业务逻辑层是同步调用,但网关到业务逻辑实现也异步调用。这样虽然增加了业务请求的延时,但大幅提升了吞吐量(即把同步方式对数据库的随机写,变成异步方式的对MQ的顺序写)


架构设计与拆分的哲学10.webp_副本.jpg


需要注意的是,并不是所有的请求场景都适合异步,具体可以参照下图:

架构设计与拆分的哲学11.webp_副本.jpg


我们将同步请求和异步请求用画笔标识流量路径


架构设计与拆分的哲学12.webp_副本.jpg

提交成功!非常感谢您的反馈,我们会继续努力做到更好!

这条文档是否有帮助解决问题?

非常抱歉未能帮助到您。为了给您提供更好的服务,我们很需要您进一步的反馈信息:

在文档使用中是否遇到以下问题: