请选择 进入手机版 | 继续访问电脑版

架构设计(一) 架构演变

[复制链接]
小小海 发表于 2020-12-31 18:10:36 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
一、什么是架构

架构的第一性原理:降本增效
1. 对业务场景抽象后得出的支撑骨架
2. 架构因业务场景而生被业务场景所扬弃
3.架构没有最好只有最符合
  1. - 研发的技能本领- 业务的复杂度- 数据规模巨细- 时间成本- 运维本领
复制代码
4.最符合的架构都是业务场景Balance的效果,场景驱动架构增长,架构是天时地利人和的融合效果  
二、互联网软件架构演变


1.单体架构

客户端 
APP, H5,小步调
服务端
1. App端请求发给单体服务
2.单体服务担当请求
3.单体服务从数据库读取数据
4.单体服务对数据库返回的数据进行逻辑处置处罚
5.单体服务对返回的效果进行封装,返回效果给App端
例子:查询个人主页 - 获取个人详细信息 

 单体架构的优点
  1. 1.开发简单2.测试简单3.发布简单4.扩容简单- 单体应用可以结合Nginx部署多个节点实现扩容 
复制代码
 单体架构的使用场景
  1. 1. 业务场景简单,功能不复杂,研发人员较少    - O2O2.创业公司初期3.性能要求及其苛刻 - 量化交易 - 高频交易 - 股票 债券 外汇交易 
复制代码
单体架构的毛病
耦合-所有服务都放在一起(如下图:用户服务,商品服务,交易服务全都放在一起)
如何办理?
- 数据库存储量大/请求量大拆分
  1.垂直拆分(分库)
  2.水平拆分(分表)- 单表数据量比力大 ~ 取模算法
- 拆分架构
  1.垂直方向拆分(业务维度)
  2.水平拆分(功能维度)

2.面向服务架构 

SOA - 按照业务将单体应用垂直拆分
1个历程变3个历程

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

 SOA缺点
  1. - 业务方向垂直拆分1.每个服务照旧单体服务  
复制代码
3.水中分层架构

水平方向拆分 

分层设计原则
  1. 前后端分离的架构1.数据服务与业务逻辑服务分离2.业务逻辑服务与网关服务分离3.网关服务与展示服务分离
复制代码
网关层功能(业务无关)
  1. 功能1: 请求鉴权 - 发布商品,登岸鉴权功能2:数据完整性查抄 - 数据包定长Header和变长Body1.定长Header: 数据的属性字段有没有缺失功能3: 协议转换 - JSON  to HashMap(String, Object)1.FastJson2.Jackson3.Mapstruct功能4:路由转发 - 根据CMD转发到差别的业务逻辑层功能5:服务治理 - 限流,降级,熔断等
复制代码

 业务逻辑层功能
  1. 功能1:业务逻辑判断 - 案例:微信黑名单查抄 - 案例:微信挚友删除
复制代码
 数据访问层功能
  1. 功能1:CRUD - 业务增删改查接口(批量)功能2:ORM - JPA功能3:Sharding(分表分库) - Shardingsphere分库分表(NewSQL时代分库分表已颠末时了)功能4: 屏蔽底层存储差别性 - PostgreSQL/MongoDB - Redis
复制代码

 同步架构 OR 异步架构
  1. 异步目地: 提升吞吐量异步手段: 消息队列(Kafka, RocketMQ)场景1:请求范例 - 写请求 (不关注语义效果,读请求应为要返回效果,所以不适合异步)场景2:业务范例 - 充值,转帐不适合异步场景
复制代码

 层次划分
  1. 同步架构(四层)-网关层-业务逻辑层-数据访问层-数据存储层异步架构(五层)-网关层-异步消息队列层-业务逻辑层-数据访问层-数据存储层
复制代码
 水平拆分架构的缺点
每层粒度过粗
4.微服务架构

微服务架构 =  SOA架构 + 水平拆分的架构
简而言之,微服务体系结构风格是一种将单个应用步调开发为一组小型服务的方法,每个服务在自己的流程中运行,
并与轻量级机制(通常是HTTP资源API)通信。这些服务是围绕业务功能构建的,而且可以通过完全自动化的部署机制独立部署。
这些服务可以用差别的编程语言编写,使用差别的数据存储技能,对这些服务进行去中心化的会合管理。
 下面link是微服务的完整定义:https://martinfowler.com/articles/microservices.html
业务的垂直拆分 + 功能水平拆分 

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

 微服务架构本质
  1. 1.两个维度的拆分(垂直拆分,水平拆分)2.业务架构3.组织架构-信用卡事业部-基金事业部-贷款事业部   
复制代码
 微服务架构适用场景
  1. 1.需求层面 - 需求不停变动(如果需求半年或一年变革一次则不适合微服务架构)2.性能层面 - 提升吞吐量
  2. - RT要求苛刻的场景不适用微服务架构3.数据一致性层面 - 最终一致性
复制代码
 微服务架构适用目的
1.项目的快速迭代
2.项目的持续交付
 完整的微服务架构
  1. 1.DNS分析2.静态资源3.动态接口数据
复制代码

 微服务架构毛病
1.业务服务需要关注非业务的功能
- 业务迭代速度变慢
2.根本设施组件升级困难(一般以Jar包的形式引入)
- 影响根本设施团队的交付本领和交付速度
3.多编成语言之间的通信问题
- 业务每种语言一套根本设施,成本大

 


 微服务架构演进
  1. 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服务网格逻辑上分为数据面板(执行者)和控制面板(指挥者)

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

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

 完整的服务网格架构

案例: 微服务的演进

微服务1.0
开发初期人力受限
  1. 1.网关层 1个2.业务逻辑层 1个3.数据访问层 多个4.DB/ Cache 多个
复制代码

微服务1.0存在问题
  1. 业务逻辑层1.粒度粗-所有业务逻辑耦合在一个物理历程内部2.迭代效率低下办理方式:业务逻辑垂直拆分
复制代码
微服务2.0

 微服务2.0存在问题
  1. 公共逻辑层1.组建化-引用jar,导致迭代效率下降 (应该将其服务化 -下沉为独立服务,提供兼容接口)办理方式:水平方向拆分 
复制代码
微服务3.0
 

1. 3.0 架构中,所有的到用都是从上到下的调用,不允许同层调用,制止交错调用出现
2. DB 只对数据访问层可见,对业务逻辑层不可见

来源:https://blog.csdn.net/u011323949/article/details/111992698
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

发布主题

专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )