架构课程要求
空杯心态
认知冲突的情况、要学会吸收;不要轻易杜绝不认可的技术方案；要认真思考他存在的场景 一定是有原因的。
多思；结合自己的经历来碰撞；这样既有被动、也有主动 学习就更深刻、以达到深度加工变成自己的东西。
坚持看直播+录音至少两遍
每次直播最好来看、并且一次吸收没办法到达百分百；所以录播要多看；每多看一次 收获多一点；一般至少看三次
深度思考、大胆提问、刻意练习
大胆提问 ；脸皮要厚 脸皮厚决定你的认知高度；一定要刻意练习；做测试题；做做作业 以及大作业。
老师讲是被动push/把知识真正掌握还是比较难的、要自己主动去思考、去质疑；老师讲的不一定都对。是不是有一些思路可能比老师更好。有一种批判的观点。总而言之一定要有自己的一些思想。
35岁之前靠智力、35岁之后靠体力
多锻炼；把自己的体力加强；时间作息调整好；这样才能够有更好的精神状态来学习。
架构师交付的内容
互联网三高架构演进之道
架构是什么
对业务场景抽象后得出来的支撑骨架、<u><b>最合适的架构都是各方面折中(Balance)的结果</b></u>、<br>并朝着【降本增效】的目标走。
架构设计考虑指标包含：业务复杂度、数据规模大小、人员技术研发能力、时间成本、运维能力等.....
互联网架构演进
Monoliths<br>单体架构
水平分层架构
Microservices<br>微服务架构
Service Mesh<br>服务网格架构
Middle<br>中台架构
Cloud Native<br>云原生架构
SOA<br>面向服务架构
不变的就是道(7种思维模型)、变的只有场景而已。
演进案例 单体架构遇到瓶颈
数据库拆分
分表
功能水平拆分：如用户表超过1个亿、需要把一张表拆成多张表；可以用户UID%64 分成64张表来分散存储
可能带来 join count 问题
单体架构设计与实践
单体架构(优点)
容易开发(Develop)
容易测试(Test)
容易部署(Deploy)
容易扩展(Scale)
业务场景简单、功能服复杂、研发人员少、O2O、初创公司、性能要求积极苛刻(金融案例)、毕竟单实例不用外部网络通讯、可节省网络通讯耗时。
单体架构破局、何时破局？
迭代很慢、就算加人的情况下还是迭代很慢、可能还会降低效率
怎么破局，就算拆。那拆的方式 可结合水平拆分、垂直拆分。
如何拆分
数据库存储量大/请求量大破局
垂直拆分(分库)
水平拆分(分表)
架构设计的哲学：术(领域、场景)不同、道相通。(抓住不变的道、就能以不变应万变)
面向服务架构设计与实践
面向服务拆分、包括DB、按照业务领域来拆、缺点虽然有个服务总线来治理、但本质每个服务还是单体应用。
水平分层架构设计与实践
同步架构
网关层
业务逻辑层
数据访问层
数据存储层
异步架构
注意点：吞吐量会增加、延时也会增加
CP
CP模型的情况下不适合做异步 一般典型的金融充值场景才使用
AP
AP模型适合：如微信发消息；因为不用立即返回请求数据
分层设计原则
展示服务-->网关服务分离
网关层-->逻辑服务分离
逻辑服务-->数据服务分离
网关功能
数据完整性检查
数据包定义长Header+变成Body
协议转换
JSON->HashMap（String.Object）
水平分层架构服务和协议
业务逻辑层
数据传输协议
二进制协议(例如：Protocol Buffers)
数据访问层
数据传输协议
二进制协议(列如：Protocol Buffers)
SQL2003
微服务架构设计与实践
微服务网格架构设计与实践
大中台化架构设计与实践
云生态架构设计与实践
线上真实案例演进实践
