智能互联网之总体架构设计(上)
2021-10-14 11:07:05 28 举报
AI智能生成
架构学习笔记
作者其他创作
大纲/内容
架构课程要求
空杯心态
认知冲突的情况、要学会吸收;不要轻易杜绝不认可的技术方案;要认真思考他存在的场景 一定是有原因的。
多思;结合自己的经历来碰撞;这样既有被动、也有主动 学习就更深刻、以达到深度加工变成自己的东西。
坚持看直播+录音至少两遍
每次直播最好来看、并且一次吸收没办法到达百分百;所以录播要多看;每多看一次 收获多一点;一般至少看三次
深度思考、大胆提问、刻意练习
大胆提问 ;脸皮要厚 脸皮厚决定你的认知高度;一定要刻意练习;做测试题;做做作业 以及大作业。
老师讲是被动push/把知识真正掌握还是比较难的、要自己主动去思考、去质疑;老师讲的不一定都对。是不是有一些思路可能比老师更好。有一种批判的观点。总而言之一定要有自己的一些思想。
35岁之前靠智力、35岁之后靠体力
多锻炼;把自己的体力加强;时间作息调整好;这样才能够有更好的精神状态来学习。
交互目标
主要交付7大思维模型
狭义架构
业务需求分析
业务需求至简抽象分析思维模型
需求背后的真实需求
架构设计
掌握哲学本质架构设计思维模型
结合场景选架构、结合一些定律供给我们来选择
CAP架构设计思维模型
BASE架构设计思维模型
架构选型
有dubbo/有spring boot/有 grpc 要结合场景Balance来选
根据场景Balance架构设计思维模型(非常重要)
给出“合适”架构设计思维模型
适度超前架构设计思维模型
架构以6个月~2年的考虑就行 避免过度设计
容量规划
根据场景来折中
选择硬件、还是云、还是私有云 结合实际情况来考量
代码落地
架构师还是要写核心代码;每周抽出一些时间来写;目的 保持对技术的敬畏;和敏感性
架构治理
对服务做一些监控、注册 服务发现;
架构设计能力
以不变应万变的能力
不变:7个思维模型
万变:场景
在任何公司下能给出优雅的架构设计方案
给出优雅的架构设计方案
优雅=适合=适度超前
架构设计终止之道
降本增效
增效
开发效率
运维效率
部署效率
沟通效率
降本
人力成本
机器成本
运维成本
团队沟通成本
企业级真实案例驱动
一切不以真实场景案例来讲的都是耍流氓
架构师交付的内容
互联网三高架构演进之道
架构是什么
对业务场景抽象后得出来的支撑骨架、最合适的架构都是各方面折中(Balance)的结果、
并朝着【降本增效】的目标走。
并朝着【降本增效】的目标走。
架构设计考虑指标包含:业务复杂度、数据规模大小、人员技术研发能力、时间成本、运维能力等.....
互联网架构演进
Monoliths
单体架构
单体架构
水平分层架构
Microservices
微服务架构
微服务架构
Service Mesh
服务网格架构
服务网格架构
Middle
中台架构
中台架构
Cloud Native
云原生架构
云原生架构
SOA
面向服务架构
面向服务架构
不变的就是道(7种思维模型)、变的只有场景而已。
演进案例 单体架构遇到瓶颈
数据库拆分
分库
按照业务领域来垂直拆分
分表
功能水平拆分:如用户表超过1个亿、需要把一张表拆成多张表;可以用户UID%64 分成64张表来分散存储
可能带来 join count 问题
服务拆分
功能水平拆分
根据请求生命周期来拆
业务领域垂直拆分
单体架构设计与实践
单体架构(优点)
容易开发(Develop)
容易测试(Test)
容易部署(Deploy)
容易扩展(Scale)
单体架构扩展
做集群服务
业务场景简单、功能服复杂、研发人员少、O2O、初创公司、性能要求积极苛刻(金融案例)、毕竟单实例不用外部网络通讯、可节省网络通讯耗时。
单体架构破局、何时破局?
迭代很慢、就算加人的情况下还是迭代很慢、可能还会降低效率
怎么破局,就算拆。那拆的方式 可结合水平拆分、垂直拆分。
如何拆分
数据库存储量大/请求量大破局
垂直拆分(分库)
水平拆分(分表)
架构拆分同理
垂直方向拆分(业务维度)
业务领域
水平方向拆分(功能维度)
功能拆分请求的生命周期
架构设计的哲学:术(领域、场景)不同、道相通。(抓住不变的道、就能以不变应万变)
面向服务架构设计与实践
面向服务拆分、包括DB、按照业务领域来拆、缺点虽然有个服务总线来治理、但本质每个服务还是单体应用。
水平分层架构设计与实践
同步架构
网关层
业务逻辑层
数据访问层
数据存储层
异步架构
异步的目的
提升吞吐量
异步手段
消息队列
适用场景
一、请求类型
写请求适合、读请求不适合。
二、业务类型
CP模型不适合、AP模型是适合的。
注意点:吞吐量会增加、延时也会增加
CP
CP模型的情况下不适合做异步 一般典型的金融充值场景才使用
AP
AP模型适合:如微信发消息;因为不用立即返回请求数据
分层设计原则
展示服务-->网关服务分离
网关层-->逻辑服务分离
逻辑服务-->数据服务分离
网关功能
请求鉴权
发布商品、登录鉴权
数据完整性检查
数据包定义长Header+变成Body
协议转换
JSON->HashMap(String.Object)
路由转发
根据CMD转发到不同业务逻辑层
服务治理
限流、降级、熔断等
水平分层架构服务和协议
网关层
Web服务
列如:Spring Boot
通讯协议
HTTPS
数据传输协议
JSON
业务逻辑层
RPC服务
例如:Dubbo
通讯协议
TCP长连接
数据传输协议
二进制协议(例如:Protocol Buffers)
数据访问层
RPC服务
例如:Dubbo
通信协议
TCP长连接
数据传输协议
二进制协议(列如:Protocol Buffers)
SQL2003
缺点
每层粒度过粗(粗粒度)
微服务架构设计与实践
微服务网格架构设计与实践
大中台化架构设计与实践
云生态架构设计与实践
线上真实案例演进实践
0 条评论
下一页