智能互联网之总体架构设计（下）
2021-10-31 18:35:17 47 举报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
水平分层架构服务和协议
每层粒度过粗(粗粒度)
缺点
水平分层架构设计与实践
结合Balance来拆
业务拆分
功能拆分
两个维度拆分
本质
快速迭代、持续交付
目的
迭代太慢比如半年~1年迭代一次的场景 不适合做微服务、也背离 微服务的目的(快速迭代、持续交付)
需求层面
由于节点可无限横向扩展；吞吐量提高；由于节点多 链路长 响应延迟增加了
性能层面
微服务还是适合使用AP模型；如果使用通过分布式使用强一致性(CP模型)、那么吞吐率就会降低，而微服务就是为了提高吞吐率的。折中的场景就是最终一致性；能够接受一定的延时时间。
数据一致性层面
适合场景
最普适的完成微服务架构
业务迭代速度变慢
业务关注服务间“通信”
影响基础设施团队交付能力和交付速度
基础设施组件升级困难
微服务框架不是银弹
微服务架构设计与实践
Servcie Mesh独立进程、独立升级
业务团队专注于业务逻辑本身
一套基础设施支持多语言开发
业务团队和基础设施团队物理解耦
服务治理和服务本身的物理剥离
Service Mesh优势
IStio服务网格逻辑上分为数据面板(执行者) 和控制面板(指挥者)
数据面板由一组只能代理(Envoy)组成.代理部署为sidecar，调解和控制微服务之间所有的网络通信
控制面板负责管理和配置代理来路由流量，以及在运行时执行策略
服务治理(控制面板和数据面板)和服务本身(srcA/srcB)的物理剥离
Istio总体架构设计
最普适的完成服务网格架构
微服务网格架构设计与实践
中台组织架构
个性化业务架构
公共业务架构
业务架构
个性化数据架构
公共数据架构
数据架构
个性化算法架构
公共算法架构
算法架构
技术支撑
技术架构
中台分类
业务中台架构
业务中台如何一键连接？
公共数据表
业务个性化扩展数据表
业务数据和中台数据如何存储？
大中台化架构设计与实践
指专门为在云平台部署和运行而设计的架构
云原生架构
按需使用和弹性伸缩
无状态化设计(stateless)
自动化部署和管理
秩序集成和持续交付
云原生架构本质
容器技术Docker的成熟
容器管理技术Kubernetes的成熟
云原生态架构更关注应用在云上弹性部署和运行(运维侧)
云原生架构普及
云生态架构设计与实践
线上真实案例演进实践
架构师交付的内容
智能互联网之总体架构设计
0 条评论
回复 删除
下一页
