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