当年我靠着这个回答,顺利应聘了架构师岗位
文章首发公众号『风象南』
我曾经在一家小企业担任技术一号位,由于公司的规模及业务发展缓慢与我个人对成长的强烈渴望之间产生了矛盾,于是我选择去市场上寻找新机会。
经过筛选,我把目标锁定在了一家做物联网方面的公司,选择的原因也是因为对我来说这是个全新的行业,里面一定有我之前没遇到过的技术挑战,而我选择投递的职位是架构师。
当时面试我的技术副总在与我沟通完所有技术问题后,他最后问了我一个问题
你认为做架构设计最难的是什么 ?
思考10秒钟,如果是你,你会怎么回答这个问题
我的回答
我认为,架构最难的就是做权衡取舍,在有限的资源、有限的时间等条件约束下如何选择符合当下最优的解决方案。
最终经过4轮面试,从3个候选人中顺利杀出(当然最终公司选择我的原因肯定也不是这一个回答,而是结合前面的技术面试综合后的结果),最终以架构师岗位入职公司。
今天,我想就这个问题再进行一些展开,把自己关于系统架构、设计方面的一些感悟进行一些简单梳理
那么,首先要知道什么是架构设计,基于个人理解先对架构设计下个定义
系统架构是指在特定环境下,通过合理的组织各个元素(如业务服务、数据库、缓存、消息队列等)及其之间的依赖关系,来支撑业务运行的解决方案。
下面展开聊一聊个人的思考
核心原则
首先,我一直秉持的一个架构核心原则是 "保持简单" ,好的架构、好的设计一定是易于理解的,结构是清晰的。如果你在设计过程感觉到了复杂、别扭,别怀疑,你很有可能进入了误区,这时候一定要跳出当前的思维从全局重新审视当前的设计。
没有银弹
记得刚入行那几年,做了一些项目后,有时候我就在想,为什么不能设计一套通用的架构去解决所有问题,这样不就可以重复利用了 ?
后来发现,真的没有银弹,核心点就是前面定义系统架构时所说的特定场景,不同场景下对同一个功能的需求是不一样的,比如安全性需求、性能需求,而这些需求决定了架构的设计。
同一个功能在 2000 QPS 与 20000 QPS 下的设计一定是有区别的。
说到底,技术最终是为了更好的支撑业务,抛开业务场景谈架构设计没有意义。
虽然架构不能复用,但是技术组件、业务组件是可以复用的。
关注约束条件
这个也是架构设计中容易忽略的问题,可能会导致原先已经设计好的方案要进行返工或推倒重做。
这些约束条件可能来自政策、可能来自客户、可能来自技术组件本身。
所以设计初期一定要对这些约束条件进行收集,避免无谓的成本浪费。
避免盲目堆砌技术栈
之前面试过很多同学,一看简历上面写着,负责某某系统的架构设计,一般我就会比较感兴趣,但是通常了解下来,大部分同学并没有太多思考,他们所说的架构设计就是技术堆砌。
比如我用了Spring Cloud Alibaba全家桶,但是连接了同一个数据库、用户量只有几万、甚至QPS高峰期就几十。
但我其实理解,因为我早期也这样,出现了新技术总想引入到项目中秀一下,然后觉得自己很牛X。
技术堆砌有问题吗,能解决问题不就行了 ?
当然有,编码一时爽,接下来呢 ?
多一种技术组件就多一种故障的可能,本地测个新增功能服务起了一大堆,新人入职找不到北环境搞不起来,如果系统整体要求高可用,那么所有引入的组件都需要做集群或者冗余方案,数据不一致了怎么办,调用链路复杂,一个问题需要多个成员参与分析,另外,所有的组件团队成员是否都熟悉,组件出现故障是否能够快速定位,出现性能问题是否能够分析优化等等。
所以,你以为你只引入了一个组件,其实你可能给下一个环节的同事增加了一倍的工作量。
奥卡姆剃刀原则"如无必要,勿增实体",所以,每一个组件的引入一定要有它的实际意义,不要徒增成本。
每次引入一个组件我们都应该想
- 引入的组件为了解决什么问题,引入后就一定能解决吗
- 基于现有的组件确实解决不了吗,稍微调整下技术方案呢
- 有没有与其他同类型组件进行横向预研对比呢,引入后会增加多少开发、运维成本
收起你的锋芒
大部分技术人好像有个通病,会下意识的会保护自己的劳动成果,比如我设计的方案、我做的功能别人提了不同意见,第一反应是防御、是反驳,而没有反思是不是真的不合理。
这个可能需要在工作中一点一点调整,先尝试忍住不要着急反驳,至少听别人说完他的建议,实在忍不住可以回一句 "我再想想",然后下来试着把别人的不同意见进行认真思考。
比如,是不是别人的意见在我看来其实是对的,但是因为增加了我的工作量,让我产生了抵触情绪,所以我要反驳他。
这条从表面看好像跟主题没什么关系,但是为什么我会写在这里,我认为这是一个阻碍技术人成长的一个因素。
每个人的经历不同,看问题的角度不同,多学习,多听他人的意见来丰富我们的知识框架。
即使不认同也是一种思考。
形成自己的方法论
比如今天我写的这些内容实际是我在做架构设计的一套方法论,方法论的作用就是在信息交会、参杂在一起面对一些复杂情况的时候,你仍能有自己清晰的判断,果断的做出决定。
因此,我们应在日常工作和生活中多加思考与总结。我认为,这一点至关重要,至关重要,至关重要。最终形成的方法论将成为你个人独一无二的秘密武器。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
表访问方法:PostgreSQL 中数据更新的处理方式
作者:Cary 前言 本文将详细探讨 PostgreSQL 如何处理更新操作。在 PostgreSQL 中,成功的更新可以被视为"插入一条新记录",同时"标记旧记录为不可见",这是因为 PostgreSQL 使用了 MVCC 技术。这个过程听起来简单,但实际上有许多因素需要考虑,以确保更新的成功。 涉及的 API 在执行更新操作时,主要涉及两种表访问方法的 API: tuplefetchrow_version():此函数用于查找给定 TID 的元组的最新版本。我们需要使用给定的 TID 查找特定的元组进行更新。此外,如果适用,可以提供一个快照结构来执行可见性检查。该函数会提取元组并将其转换为 Tuple Table Slot,如果成功提取元组,则返回 true,否则返回 false。 tuple_update():这是处理元组更新请求的主要处理函数。此函数会接收多个参数来执行更新操作: 旧元组的 TID:待更新的旧元组的位置 新元组(以 Tuple Table Slot 表示):PostgreSQL 将其转换为 HeapTuple 进行更新 命令 ID 和快照:用于对待更新的旧元组执行...
- 下一篇
RXThinkCMF 敏捷开发框架 Laravel10+AntdVue 版本 v2.2.0 发布
v2.2.0 更新内容:1、优化性能,提升使用体验;2、优化模块功能,增强编码规范;3、修复近期用户反馈的问题; 一款 PHP 语言基于 Laravel10、Vue3、ElementUI、MySQL 等框架精心打造的一款模块化、插件化、高性能的前后端分离架构敏捷开发框架,可用于快速搭建前后端分离后台管理系统,本着简化开发、提升开发效率的初衷,目前框架已集成了完整的 RBAC 权限架构和常规基础模块,前端 Vue 端支持多主题切换,可以根据自己喜欢的风格选择想一个的主题,实现了个性化呈现的需求;为了敏捷快速开发,提升研发效率,框架内置了一键 CRUD 代码生成器,自定义了模块生成模板,包括后端 PHP 文件模块和前端 Vue 端个性化模板,可以根据已建好的表结构 (字段注释需规范) 快速的一键生成整个模块的所有代码和增删改查等等功能业务,真正实现了低代码开发,极大的节省了人力成本的同时提高了开发效率,缩短了研发周期,是一款真正意义上实现组件化、低代码敏捷开发框架。 软件信息 软件名称:RXThinkCMF 敏捷开发框架 Laravel10+EleVue 版本 官网网址:https://w...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Hadoop3单机部署,实现最简伪集群
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池