

首页  思维导图  详情



智能互联网之总体架构设计（下）

2021-10-31 18:35:17   47  举报





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模型的情况下不适合做异步一般典型的金融充值场景才使用

AP模型适合：如微信发消息；因为不用立即返回请求数据

分层设计原则

展示服务-->网关服务分离

网关层-->逻辑服务分离

逻辑服务-->数据服务分离

网关功能

请求鉴权

发布商品、登录鉴权

数据完整性检查

数据包定义长Header+变成Body

协议转换

JSON->HashMap（String.Object）

路由转发

根据CMD转发到不同业务逻辑层

服务治理

限流、降级、熔断等

水平分层架构服务和协议

网关层

Web服务

列如：Spring Boot

通讯协议

HTTPS

数据传输协议

JSON

业务逻辑层

RPC服务

例如：Dubbo

通讯协议

TCP长连接

数据传输协议

二进制协议(例如：Protocol Buffers)

数据访问层

RPC服务

例如：Dubbo

通信协议

TCP长连接

数据传输协议

二进制协议(列如：Protocol Buffers)

SQL2003

缺点

每层粒度过粗(粗粒度)

微服务架构设计与实践

本质

两个维度拆分

业务拆分

结合Balance来拆

功能拆分

目的

快速迭代、持续交付

降本增效

适合场景

需求层面

迭代太慢比如半年~1年迭代一次的场景不适合做微服务、也背离微服务的目的(快速迭代、持续交付)

性能层面

由于节点可无限横向扩展；吞吐量提高；由于节点多链路长响应延迟增加了

数据一致性层面

微服务还是适合使用AP模型；如果使用通过分布式使用强一致性(CP模型)、那么吞吐率就会降低，而微服务就是为了提高吞吐率的。折中的场景就是最终一致性；能够接受一定的延时时间。

最普适的完成微服务架构

微服务框架不是银弹

业务关注服务间“通信”

业务迭代速度变慢

基础设施组件升级困难

影响基础设施团队交付能力和交付速度

微服务网格架构设计与实践

Service Mesh优势

Servcie Mesh独立进程、独立升级

业务团队专注于业务逻辑本身

一套基础设施支持多语言开发

业务团队和基础设施团队物理解耦

服务治理和服务本身的物理剥离

Istio总体架构设计

IStio服务网格逻辑上分为数据面板(执行者) 和控制面板(指挥者)

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

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

服务治理(控制面板和数据面板)和服务本身(srcA/srcB)的物理剥离

最普适的完成服务网格架构

大中台化架构设计与实践

中台组织架构

中台分类

业务架构

个性化业务架构

公共业务架构

数据架构

个性化数据架构

公共数据架构

算法架构

个性化算法架构

公共算法架构

技术架构

技术支撑

业务中台架构

业务中台如何一键连接？

业务中台架构

业务数据和中台数据如何存储？

公共数据表

业务个性化扩展数据表

云生态架构设计与实践

云原生架构

指专门为在云平台部署和运行而设计的架构

云原生架构本质

按需使用和弹性伸缩

无状态化设计(stateless)

自动化部署和管理

秩序集成和持续交付

云原生架构普及

容器技术Docker的成熟

容器管理技术Kubernetes的成熟

云原生态架构更关注应用在云上弹性部署和运行(运维侧)

线上真实案例演进实践

 Collect

Get Started

互联网金融平台业务流程

 Collect

Get Started

互联网高并发系统技术架构

 Collect

Get Started

世界互联网大会

 Collect

Get Started

工业互联网





0 条评论

下一页