大量阅读别人的系统实现文章(
架构= 模块图 + 模块流程图(启动 和 主流程 ,可以用拟物 tag) 或者 模块时序图)
动态+静态 .对象很重要,模块很重要. 从产品角度,用户很重要
脑图不需要按空格,收缩行
https://www.processon.com/view/link/58c7cbbfe4b020bb58b2e0d6
架构脑图
编辑脑图
我理解的架构师需要掌握的知识
-
用例收集能力,业务模块切分能力.领域设计能力.
功能设计,非功能设计.
没有用例图的实体图就是耍流氓.
实体生命轴
对于builder设计模式,其实就是基于用例抽象出方法后自然就实现了. 对复杂的代码,先看理解,然后思考行为,用例.然后再重构. 三步法.
-
规划能力,分解能力,抓手和指导能力.
人角度切割(乘客,客服,司机,运营),视图层业务. 将用户角度的视为前台主业务.
基础服务抽取的时候,存储和计算分离也很自然. 积分和积分计算,帐户和营销加款
-
类设计和编程落地能力. 能写高可读和应对变化,可维护代码.
熟悉java锁源代码,readwritelock.
缓存策略代码写. 分层.
jvm各命令含义. jmap -heap jstack
jvm paral cms g1垃圾回收算法.特别是g1
锁力度
for 1w问题
分页问题,两次查询分库分页.
方法同层次
try 重试. 单次可用性,dubbo check
tcp nagle . http://blog.csdn.net/ithzhang/article/details/8520026 .
国际路线问题,数据双活.
type类化,字段类化(map等)可带走一大堆相关逻辑到对象中.
-
看别人代码能力,可重构点能力. 分层不合适,方法抽取, 重复代码合并下层 ,类型接口化. 见面向领域设计p203的闭合运算重构
-
承担系统重构和切分的方案和项目推进落地.
dao不动,先动service.
各层次接口化,杜绝依赖.
包依赖插件检查.
-
高可用,高并发,可扩展性.各场景方案的了解.
稳定性(n个接口1个失败) 链路error日志统计归类,基于结构化日志.,可用性(). 可靠性(持续一段时间不可用是最悲剧的)
单行极限和可用性互斥. 高并发的方案就是拆拆拆.
zk不可扩展.把他认为是单机.前面搭建一个proxy 一致性hash集群.
超时解决方案是环.(超时30秒,格30个,误差1秒),两各数组切换.误差 30-59秒.(从启动,到切换,再切换,三次画图可知.)
分布式自增id .
架构. ngnix前面是智能dns. 双活和cdn基础.
SNow(并发太高可能重复)和腾讯的序列号自增方案.
高并发io相关技术,io中断多核并行.达到几万tps. 不然才1w tps. io超时回收, 环.
算法,B+树,hadoop排序(数据预清洗). mysql 多行高并发和单行高并发改造.
AB Test指标可配置接口化系统,流式计算接口化系统.
一键降级系统
低耦合配置系统(低耦合,依赖本地文件存储) kdiamond 开源其他
全链路压测,
计算同城双活(跨城专线通信,增加用户体验),数据同城双活(类version,cas保障,虚拟ip可随时切换.),依据人变动可切换该人主数据的双活.
可伸缩的DBproxy中间件,codis.
弹性计算云,kubernoter coker
kop
redis进化为zk. 同时复制两台. 客户端1访问redis1,客户端2访问redis2.无法解决,zk通过master来解决.
-
业务growth能力和对应体系了解和搭建能力.
AB TEST平台.
-
系统见识.
kop 规则引擎 流程引擎
快速开发框架 crm快速web设计系统.
T5+(P6+)
1、实现一个带超时功能的connect函数
考察点:linux网络编程、non-blocking、select/poll/epoll的使用、对底层库的了解程度
默认的connect为阻塞,通过设置socket为non-blocking、监听写事件来做到非阻塞超时connect。
参考点:大多数网络库都有相关或类似实现,最直接的可以看golang net库源代码,其DialTimeout的底层实现即是此问题。
引伸点:
(1)若面试者能答出用select或epoll实现,进一步考察select、epoll工作原理,如epoll是如何存储fd的,如何做到用“回调机制”将就绪的fd返回,select和epoll区别等;
(2)linux网络编程的其他要点或其他函数的使用,如shutdown、reuseaddr,进而可引伸出TCP协议状态机、TCP协议粘包处理、TCP协议滑动窗口机制、TCP包重发机制等;
(3)IO多路复用处理并发网络连接的基本模型、要点;
(4)对boost asio、libevent、libev或其他库的了解程度;
(5)线程池的实现以及要点。
2、实现一个简单的内存池管理,要求在多线程环境中高效使用
考察点:内存模型、内存分配过程、内存碎片处理、对tcmalloc之类的库的了解程度、对STL了解程度
参考点:主要可参考tcmalloc实现,golang内存分配和gc机制也是类似原理。
引伸点:
(1)若面试者能大概答出tcmalloc的架构,可进一步考察用户空间如何从内核空间申请内存,包括相关的系统调用;
(2)默认的库函数malloc/free(new/delete)的不足之处在哪?为什么要引入这样的东西?STL默认的内存分配器是如何工作的,有没有什么问题?
(3)若能答出golang或其他语言的内存分配和gc的类似机制,进一步考察对实现细节的了解程度;
(4)可引伸至fork、vfork、copy-on-write、无锁队列等问题进一步考察。
3、实现一个线程安全的单例模式
考察点:c++基础、设计模式、多线程编程、各种同步机制
参考点:遍地可找到,如果此问题都答不出,在架构组基本不用考虑继续面
引伸点:
(1)单例模式的“懒汉”和“饿汉”的区别,如其实现的是“懒汉”模式(通常答的都是这个),考虑让其以“饿汉”模式实现,可以适当提示,同时,两种模式各有什么优缺点?
(2)进一步考察c++基础问题,考察其对c++的理解程度,包括RTTI、c++对象模型、虚函数工作原理、虚表结构等问题;
(3)基于(2),进一步考察如java语言或go语言都填了c++的哪些坑,这样做的目的是什么?
(4)c++的一些经典内存问题,如构造函数异常、非线程安全的析构等,进一步可引伸出智能指针的原理及使用要点;
(5)进一步考察其对boost、c++0x等对此问题相关的支持及面试者的了解程度;
(6)进一步考察多进程、多线程的各种同步机制及其差异,可进一步要求其实现一个经典的生产消费者模型;
4、实现hash表动态扩容缩容的过程
考察点:经典数据结构、多线程编程、“双缓冲buffer”的类似思想
参考点:redis的hash table动态扩容缩容过程
引伸点:
(1)此问题通常是面试者提到“了解、熟悉甚至精通redis”的情况下问出,如其能答出,进一步考察redis其他核心实现的要点,如事件驱动机制、如何写rdb,redis如何做持久化,持久化的时候又有什么问题?进而的解决方案是什么?
(2)进一步可引伸出redis代理,如twemproxy、codis的相关原理及实现;
(3)进一步了解其对底层数据结构的掌握程度,如跳跃表、RB树、B树等各种对比,进一步可引伸出LSM树和基于LSM树的各种DB,如level DB,列式存储等,进一步可考察mysql架构、mysql各种存储引擎的对比,mysql如何做分库分表、sharding、主从同步以及不足之处在哪?
(4)进一步了解其对其他第三方开源组件的了解程度,如常用的消息队列。
5、实现一个简单的3份数据冗余同步复制过程或双机热备主从同步过程
考察点:分布式存储经典问题、分布式原理、各种分布式协议
参考点:hadoop的相关实现
引伸点:
(1)GFS及类似GFS的分布式存储系统的架构及其实现,NWR、CAP、paxos、raft、二阶段提交等协议,以及这些协议到底解决了什么问题?
(2)可引伸出类似zookeeper、etcd等分布式协调服务的同步、选举过程
(3)如何做基于tcp长连接的心跳服务?
(4)实际工程中使用这些分布式系统的经验及了解程度
6、求和的绝对值最大的连续子序列 如{-5,4,-20,16,-2,-3}
考察点:算法
参考点:遍地是
引伸点:
(1)通常能给出O(n^2)算法即为OK,可进一步提示其优化至O(n )算法;
(2)进一步考察常用的算法分析方法,即分治、动态规划、回溯等,可进一步考察某些排序算法,如快排,但如果问到了快排,可进一步考察各种库如何实现了快排,做了哪些优化来避免最坏情况的发生?
(3)分析问题能力,是否用比较合适的方法来解决一个问题。
==其他人见解
转至元数据起始
1.意识(下意识,条件反射式的修养,训练成与生俱来的能力)
(1)化繁为简(抽象建模,模型)
主要体现在对系统的控制力上,能够一针见血的发现系统主要问题并给出具体可行的方案
高级抽象能力(利用生活中的例子来思考与理解面临的各种问题),高速公路中通停车道划分(系统上线后维护时一部分服务器保持现状,一部分服务器进行维护,一点一点地完成系统的修改)
至繁----->至简(抓住主要问题,能够使用简单的方法实现就绝对不会把系统复杂化)
(2)运营(保证系统的可持续发展)
不管系统UI好不好、代码结构好不好,只要能够满足基本功能需求,就先把系统搭起来并上线,然后慢慢的优化一步步地调整,这充分考验了架构师设计架构考虑问题的预判性与专业性
根据产品、运营与市场的动态功能需求与变化,需要实现对系统整体结构进行不断地调整,决定了架构的设计需要满足可变化的要求
产品再上线运营以后功能以及策略随时都会发生变化(游戏里面策划就经常改变主意,这是由产品的用户体验导向性决定的,因为用户对产品的感觉是难以一步确认的,需要在交互的过程中不断的改变),持续改进
没有做过运维,做不好运维的架构师不是好架构师
(3)有损(意外随时都会发生)
应该对一切不可抗力做好万全准备,因为任何事情都有可能发生,所以要做好系统服务的降级准备,保证最基本的功能可用性(最高级别对应最强方案),保证用户能够忍受灾难对系统的影响
要努力平衡好自尊心与事实情况,什么事情都不能说的太过于绝对,因为没有人能够保证自己不是犯错,也不敢保证可能性非常低的事情不会发生,虽然概率只有0.001%,但它也有发生的可能性
有用法则:倾尽全力(对待系统面临问题的态度,尽量避免所有情况对系统造成的打击,做好充分的容灾,在意外情况下可以降低体验,但是一定要保证系统可用) 高可用的基本原则
2.能力(是量的积累与升华沉淀的过程,需要不断的回顾与总结) 基本功,是一切的根源
(1)技术能力
初级:
网络编程
IPC通信
Posix(信号量、线程同步)
数据结构(理论与经典实现的代码阅读)
面向对象思想(保证代码结构设计的可控)
数据库(掌握基本原理,完整性、范式)
操作系统(文件系统,主要瓶颈就在I/O)
中级:
网络知识(物理拓扑、网络协议原理、设备理论及相关算法)
内核态(操作系统,内存管理、时钟中断(定时器、红黑树实现大批量)
设备管理(字符设备、套接字、文件等)、进程调度管理(switchto文件))
高级:
机器学习算法(浅层算法的实现原理及代码阅读,以分类为例,贝叶斯、极大似然相似、决策树) 互联网(工程(计算机应用)+科学(人工智能算法,数学理论性强))
(2)架构能力
初级( 达到上线水平):
性能(刚性需求,主要体现在系统的抗打击能力上)
安全(意识和想法,尽量减少安全漏洞和隐患,安全机制健全(4联单))
过载(服务能力,保证系统在高流量冲击的情况下可以有序解决流量冲击)
灰度(先让一部分用户优先体验并验证有无问题,即所谓的公测,利用他们充当测试工具)
中级:
平滑扩容(做到后可达到初级架构师水平,一般来说添加master,上线过程中不停机不停服务实现服务能力提升)
部署(通过为产品制定的策略、制度等来反推架构、配置甚至代码,也包括系统的部署方案)
set模型(要对系统进行规划,实现有序的发展,将系统划分成很多可以描述整个系统的独立单元,麻雀虽小五脏俱全,集装箱)
染色(能够将一组操作旁路出来,抽取具有异常行为的特定用户,跨机Debug、4联单、区分用户行为,以搜集具有不良行为的用户样本,分析应对方案。做到数据流与信令流(信号流转switch doNext,回调机制(好莱坞模式)、c++ ddget(委托))分离)
高级:
分布(机房、地域,具体到不同行业分别需要以不同的方法来处理) 、
柔性(应对意外情况,对系统功能进行优先级标记,优先级高的功能采用最强方案,实现倒金字塔服务应对方案)
(3)产品能力(产品意识,对产品的敏感程度,抓大去小)
主次矛盾(如果没有一个很好的产品,架构会做得非常复杂,良好产品可以更好的帮助架构师做取舍,而架构师的主要能力则体现在取舍上)
理解产品诉求的能力,选择合适的交互次数以缓解用户的厌烦程度
当系统不可用之时,首先给一个替代方案(甚至可以采用善意的谎言,制定一定的假象都可以,滴滴可以虚拟几车辆让用户以为运气不好叫不到车),缓解用户的心理落差(平缓一下用户的激动情绪)
让用户多试几次也无妨,对一些不太重要的数据没必要保证系统的强一致性,可以提供操作接口让用户主动去刷新,使得系统更加稳健,简化系统所要处理问题的复杂度
要真正地作为一个用户去使用产品(更好的体验产品的真正诉求,通过角色转换能够更好的做好各方面的取舍)
(4)行业认知(对通用架构的补充)
首先要具有广泛的互联网产品使用,以提取通用的精华的策略流程等内容,学习并体会人家的取舍过程与结果
跨域快速学习(在陌生领域具有无限的上升空间)
(5)管理能力(技术管理)
团队融合沟通、自我认识与管理(抓细节还是抓大放小,放不放权,对细节了然)
团队认知(团队的匹配程度,如何平衡各成员实现最合适的搭配,都是牛人反而不好管理)
- 胸怀
(1)大局观(前瞻性)
保证系统的可控,对系统具有极强的驾驭能力
(2)大将之风 (无畏,气度)
遇事沉稳(因经历太多而锻炼出来对于处理重大问题的丰富经验,快速成长,遇事不慌,敢于尝试)
遇到未曾遇到过的重大问题,能够将强的熬过去(强大内心,能够熬过去非常重要),积极尝试解决方案,结果导向,一切要以解决问题为形式之根本原则
(3)好学(不耻下问)
敢于向职位级别低的人讨教问题
(4)乐于分享(成就他人)
突破个人天花板的关键,因为在分享的过程中才能发现自己到底有没有掌握,而且互相分享以后自己能力的提升速度会变的快
4.经验
(1)过载应对方案(学习海关)
蛇形阵(多加几个简单的流程,保证流量的均衡分载)
限流(先承认自己响应不过来,提醒用户服务器忙稍后再试,给服务器增加缓冲时间)
预期(根据总量及当前访问人数,大致预先判定不良后果,提醒用户有可能出现的结果,通过减少非急迫访问需求用户来降低访问流量)
注:队列也是一种方法,不过队列有可能超时(想象一下在银行取钱时排到自己时取款机没钱时或者打饭时轮到自己就没饭了是一种什么样的感受)
要敢于丢弃应付不过来的流量,并且提供一个很好的UI来减少用户的烦躁与忧虑感,提升用户的忍耐程度
流量控制(类似于TCP,流量越大则队列长度应该越短,以防系统处理不过来造成拥堵)
(2)下一层永远不相信上一层,上一层要充分保护下一层(即优先在最前端机绝大部分问题,越往后处理的代价就会越大)
(3)协程
(4)协议及通讯不受易购系统的影响
(5)边重构边生活是架构师的常态(要勇于重构,勤于重构,以防积重难返导致重构难度巨大)
(6)MCP
作者:个人渣记录仅为自己搜索用
来源:CSDN
原文:https://blog.csdn.net/fei33423/article/details/61934514
版权声明:本文为博主原创文章,转载请附上博文链接!