架构设计(一) 架构演变

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

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

场景驱动架构增长，架构是天时地利人和的融合结果　　

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

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

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

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

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

- 多个独立的服务
- 通过ESB交互

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

按请求的功能进行拆分

前后端分离的架构
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

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

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

场景2：业务类型
 - 充值，转帐不适合异步场景

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

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

每层粒度过粗

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

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

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

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

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

1.两个维度的拆分（垂直拆分，水平拆分）

2.业务架构
3.组织架构
-信用卡事业部
-基金事业部
-贷款事业部　　　

1.需求层面
- 需求不断变更（如果需求半年或一年变化一次则不适合微服务架构）

2.性能层面
- 提升吞吐量
- RT要求苛刻的场景不适用微服务架构

3.数据一致性层面
- 最终一致性

1.项目的快速迭代

2.项目的持续交付

1.DNS解析

2.静态资源

3.动态接口数据

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

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

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

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

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

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

1.Istio服务网格逻辑上分为数据面板（执行者）和控制面板（指挥者）

2.数据面板由一组智能代理（Envoy）组成，代理部署为Sidecar,调解和控制微服务之间所有的网络通信

3.控制面板负责管理和配置代理来路由流量，以及在运行执行策略

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

业务逻辑层
1.粒度粗
-所有业务逻辑耦合在一个物理进程内部
2.迭代效率低下

解决方式：
业务逻辑垂直拆分

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

解决方式：
水平方向拆分