架构设计与拆分的哲学

Posted 2021-04-23 大魏分享

大魏的学习理念

"是故本派武功,以积蓄内力为第一要义.内力既厚,天下武功无不为我所用,犹之北冥,大舟小舟无不载,大鱼小鱼无不容.是故内力为本,招数为末。"

----《北冥神功》

架构拆分方式

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

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

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

但是上面的应用将是一个“巨无霸”，我们无法对其中一个功能组件单独升级。而且，如果想给单体应用增加新的功能模块，需要重新开发，整体替换。

因为，要对这个单体应用进行解耦。

那么，单体应用如何解耦？

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

随着用户数量化的增加，单一数据库表已经不成了，需要分表。

拆表的时候，以常用的列作为主键，例如UID，然后将表拆分，也就是数据库水平拆分：

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

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

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

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

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

SOA的架构落地

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

SOA

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

那么，ESB与MQ有什么区别呢？

在微服务架构中，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.微服务治理（熔断限流等）

数据访问层的作用：

1. 批量的CRUD接口

2. ORM

3. Sharding的工作（分布分表）。这步最难，如果用NewSQL就可以规避。

4. 屏蔽底层DB差异性

微服务架构的异步实现

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

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

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