（一）、架构拆分方式

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

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

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

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

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

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

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

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

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

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

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

（二）、SOA的架构落地

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

1.SOA

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

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

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的顺序写）

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

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