架构演进(上)

哲学

一个人事业的高度很大程度上取决于他人生哲学的高度，《干法》-稻盛和夫。

架构原则

1. 简单原则

2. 合适原则

3. 演化原则

简单原则即不要生搬硬套，合适的即是最好的，合适优于业界领先。合适原则即简单优于复杂。演化原则即不要贪大求全，演化优于一步到位。

淘宝和手机QQ两个典型的互联网业务发的架构发展历程表明即使现在非常复杂、非常强大的架构，也并不是一开始就进行了复杂的设计，而是首先采取了简单的方式(简单原则)，满足了当时的业务需要(合适原则)，随着业务的发展逐步演化而来的(演化原则)。罗马不是一天建成的，架构也不是一开始就设计成完美的样子，然后可以一劳永逸一直用下去。

架构认知

对于软件系统的架构设计来说，第一性原理我认为是增效降本，即想尽一切合适的办法增加效能并且降低成本。

架构与场景

所有脱离场景(业务需求、时间、团队技能储备等)谈架构都是耍流盲！

1. 单体架构

2. 面向服务架构

3. 水平分层架构

架构演进时间表

单体架构

单体架构，一般业界内称为Monoliths或者又称ALL IN ONE。即系统所有功能最终会打成一个jar或war包，最后丢到web中间件(一般是tomcat)运行起来，这就是单体架构。一般由以下几部分组成:

• 客户端

• App/小程序/H5/网站

• 服务端

• 客户端请求发给单体服务

• 单体服务接收请求

• 单体服务从数据库读取需要的数据

• 单体服务对数据库返回的数据进行逻辑封装

• 单体服务对返回结果进行封装，返回结果给客户

• 数据库

单体架构的优点

1. 容易开发

2. 容易测试

3. 容易部署

4. 容易扩容

对于单体架构来说，所有的功能都在一个jar或者war包里面，开发、测试、部署都很简单，就都写在一块就行了。至于扩容也很容易，整个应用做冗余，前面拦一层nginx做软负载就行了。架构图如下:

适合的业务场景

• 业务场景简单、功能不复杂、研发人员较少

• 创业公司初期

• 性能要求及其苛刻

• 金融业务

单体架构的缺点

耦合，不管你是否进行扩展，不管你冗余多少份，一个不变的事实就是单个服务进程内都包含了所有的功能，一个功能出问题整个服务进程就得挂。那怎么去改进呢？一个字，拆。

如何破局

要解决单体架构的耦合痛点，我们可以将其拆成多个服务。那从什么维度去拆呢？我们先看看数据库拆分的原则:

• 垂直拆分(分库)

• 水平拆分(分表)

        架构的拆分我们可以类比数据库拆分原理:

• 垂直方向拆分(业务维度)

• 水平方向拆分(代码功能维度，非业务功能维度)

所以最后基于业务维度的拆分发展出来了面向服务架构，而基于架构功能维度拆分演化出了水平分层架构。

面向服务架构

面向服务的架构是在单体架构的基础上基于垂直方向拆分出来的，架构演化图如下:

当单体架构演化称为面向服务的架构之后，不同的业务都从原来的单体架构中单独剥离出了服务，解决了所有业务功能都耦合在一个服务进程内的问题，但是随着服务越拆越多，不同服务之间的通信又变的混乱，架构图如下:

那么一般出现这种多方耦合的问题常规的解决办法都是借助第三方来解耦，所以这个时候就出现了SOA的ESB。

面向服务架构的缺点

业务垂直拆分，但是每个服务还是Monoliths。

水平分层架构

        水平分层架构是在单体架构的基础上基于水平方向拆分出来的，架构演化图如下:

设计原则

• 展示服务与网关服务分离

• 网关服务与逻辑服务分离

• 逻辑服务与数据服务分离

网关层的功能

• 请求鉴权

• 商品发布鉴权，登陆鉴权(根据业务分析可考虑下沉)

• 数据完整性检查

• Header(只检查是否存在)

• uuid

• sessionid

• bodylength

• urlid

• Body(没有办法检查，因为是变长的)

• 协议转换

• 文本格式——>二进制格式(protobuffer、msgpack)

• 提升转换效率

• JSON——>HashMap(String, Object)

• 序列化

• 路由转发

• 根据urlid转发到不同的业务逻辑层

• 服务治理

• 限流、降级、熔断

网关选型

业务逻辑层的功能

• 逻辑判断

• 逻辑执行

数据访问层的功能

•  CRUD

• 业务增删查改

• ORM

• MyBatis、SpringData、Hibernate

• Sharding

• Sharding-JDBC

• 屏蔽底层存储差异

• MySQL/MongDB

• Redis

• TiDB
  

同步或异步选择

• 异步架构的目的(提升吞吐量)

• 异步手段

• 消息队列

• 适用场景：请求类型

• 读

• 写

• 适用场景：业务类型

• 充值(处理中状态)

• 社交场景

水平分层过多

• 请求路径变长

• 平均响应延迟变高

• 定位问题变的复杂化

• 运维成本增加

水平分层过少

• 回到Monoliths

适中的分层选择

• 同步架构

• 网关层

• 业务逻辑层

• 数据访问层

• 数据存储层

• 异步架构

• 网关层

• 异步消息队列层
  

• 业务逻辑层

• 数据访问层

• 数据存储层

水平分层缺点

水平分层其实在业务功能达到一定量之后还是会出现服务粒度过粗的问题，对于网关层来说其实还好，因为我不同的业务在网关层的处理基本一致。但是对于业务逻辑层来说，水平分层的每一个服务进程还是包含了不同业务的业务逻辑处理。