架构设计(一) 架构演变

一、什么是架构

架构的第一性原理：降本增效

1. 对业务场景抽象后得出的支撑骨架

2. 架构因业务场景而生被业务场景所抛弃

3.架构没有最好只有最合适

- 研发的技术能力
- 业务的复杂度
- 数据规模大小
- 时间成本
- 运维能力

4.最合适的架构都是业务场景Balance的结果，场景驱动架构增长，架构是天时地利人和的融合结果　　

二、互联网软件架构演变

1.单体架构

客户端 

APP, H5，小程序

服务端

1. App端请求发给单体服务

2.单体服务接受请求

3.单体服务从数据库读取数据

4.单体服务对数据库返回的数据进行逻辑处理

5.单体服务对返回的结果进行封装，返回结果给App端

例子：查询个人主页 - 获取个人详细信息 

 单体架构的优点

1.开发简单
2.测试简单
3.发布简单
4.扩容简单
- 单体应用可以结合Nginx部署多个节点实现扩容　

 单体架构的使用场景

1. 业务场景简单，功能不复杂，研发人员较少
    - O2O
2.创业公司初期
3.性能要求及其苛刻
 - 量化交易
 - 高频交易
 - 股票 债券 外汇交易　

单体架构的弊端

耦合-所有服务都放在一起（如下图：用户服务，商品服务，交易服务全都放在一起）

如何解决？
- 数据库存储量大/请求量大拆分
　　1.垂直拆分（分库）
　　2.水平拆分（分表）- 单表数据量比较大 ～ 取模算法
- 拆分架构
　　1.垂直方向拆分(业务维度)
　　2.水平拆分（功能维度）

2.面向服务架构 

SOA - 按照业务将单体应用垂直拆分

1个进程变3个进程

 SOA架构

- 多个独立的服务

- 通过ESB交互

 SOA缺点

- 业务方向垂直拆分
1.每个服务还是单体服务　　

3.水平分层架构

水平方向拆分 

分层设计原则

前后端分离的架构
1.数据服务与业务逻辑服务分离
2.业务逻辑服务与网关服务分离
3.网关服务与展示服务分离

网关层功能（业务无关）

功能1： 请求鉴权 - 发布商品，登陆鉴权
功能2：数据完整性检查 - 数据包定长Header和变长Body
1.定长Header: 数据的属性字段有没有缺失
功能3： 协议转换 - JSON  to HashMap(String, Object)
1.FastJson
2.Jackson
3.Mapstruct

功能4：路由转发 - 根据CMD转发到不同的业务逻辑层
功能5：服务治理 - 限流，降级，熔断等

 业务逻辑层功能

功能1：业务逻辑判断
 - 案例：微信黑名单检查
 - 案例：微信好友删除

 数据访问层功能

功能1：CRUD - 业务增删改查接口（批量）
功能2：ORM - JPA
功能3：Sharding(分表分库) - Shardingsphere分库分表（NewSQL时代分库分表已经过时了）
功能4： 屏蔽底层存储差异性 - PostgreSQL/MongoDB - Redis

 同步架构 OR 异步架构

异步目地： 提升吞吐量
异步手段： 消息队列（Kafka, RocketMQ）

场景1：请求类型 - 写请求 （不关注语义结果,读请求应为要返回结果，所以不适合异步）
场景2：业务类型 - 充值，转帐不适合异步场景

 层次划分

同步架构（四层）
-网关层
-业务逻辑层
-数据访问层
-数据存储层

异步架构（五层）
-网关层
-异步消息队列层
-业务逻辑层
-数据访问层
-数据存储层

 水平拆分架构的缺点

每层粒度过粗

4.微服务架构

微服务架构 =  SOA架构 + 水平拆分的架构

简而言之，微服务体系结构风格是一种将单个应用程序开发为一组小型服务的方法，每个服务在自己的流程中运行，

并与轻量级机制(通常是HTTP资源API)通信。这些服务是围绕业务功能构建的，并且可以通过完全自动化的部署机制独立部署。

这些服务可以用不同的编程语言编写，使用不同的数据存储技术，对这些服务进行去中心化的集中管理。

 下面link是微服务的完整定义：https://martinfowler.com/articles/microservices.html

业务的垂直拆分 + 功能水平拆分 

经典的微服服架构
网关层 1个
业务逻辑层 多个
数据访问层 多个
DB/Cache 多个

 

 微服务架构本质

1.两个维度的拆分（垂直拆分，水平拆分）
2.业务架构
3.组织架构
-信用卡事业部
-基金事业部
-贷款事业部　　　

 微服务架构适用场景

1.需求层面 - 需求不断变更（如果需求半年或一年变化一次则不适合微服务架构）
2.性能层面 - 提升吞吐量<br>- RT要求苛刻的场景不适用微服务架构
3.数据一致性层面 - 最终一致性

 微服务架构适用目的

1.项目的快速迭代

2.项目的持续交付

 完整的微服务架构

1.DNS解析
2.静态资源
3.动态接口数据

 微服务架构弊端

1.业务服务需要关注非业务的功能
- 业务迭代速度变慢

2.基础设施组件升级困难（一般以Jar包的形式引入）
- 影响基础设施团队的交付能力和交付速度

3.多编成语言之间的通信问题
- 业务每种语言一套基础设施，成本大

 

 微服务架构演进

1.业务团队专注于业务逻辑本身
2.服务通信交给基础团队
3.物理解耦业务研发团队和基础设施团队
4.一套基础设施支持多语言开发
5.基础设施能力从应用程序下推
6.真正做到快速迭代快速交付

5.服务网格架构

ServiceMesh的定义

服务网格是一个基础设施层，用于处理服务间通信。元原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。
在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。

ServiceMesh架构

实现业务服务与基础服务解耦，业务团队仅仅关注业务开发即可，基础服务交给基础服务团队完成

ServiceMesh优点

1 2 3 4

1.ServiceMesh独立进程，独立升级 2.业务团队专注于业务逻辑本身 3.一套基础设施支持多语言开发 4.业务团队和基础设施团队物理解耦

Istio总体架构

1 2 3

1.Istio服务网格逻辑上分为数据面板（执行者）和控制面板（指挥者）<br> 2.数据面板由一组智能代理（Envoy）组成，代理部署为Sidecar,调解和控制微服务之间所有的网络通信<br> 3.控制面板负责管理和配置代理来路由流量，以及在运行执行策略

 完整的服务网格架构

案例： 微服务的演进

微服务1.0

开发初期人力受限

1.网关层 1个
2.业务逻辑层 1个
3.数据访问层 多个
4.DB/ Cache 多个

微服务1.0存在问题

业务逻辑层
1.粒度粗
-所有业务逻辑耦合在一个物理进程内部
2.迭代效率低下
解决方式：业务逻辑垂直拆分

微服务2.0

 微服务2.0存在问题

公共逻辑层
1.组建化
-引用jar，导致迭代效率下降 （应该将其服务化 -下沉为独立服务，提供兼容接口）
解决方式：水平方向拆分　

微服务3.0

 

1. 3.0 架构中，所有的到用都是从上到下的调用，不允许同层调用，避免交叉调用出现

2. DB 只对数据访问层可见，对业务逻辑层不可见