这些资深架构师平时需要解决的问题,看看你离资深架构师还有多少距离?
1、技术本身不产生价值,业务才会,论技术和业务的整合
一般会把架构分为技术架构和业务架构,这里我无意对比这两类的优劣,但我只想说,在公司里,是靠业务价值创造盈利点的,所以技术,比如消息队列,内存优化,以及分库分表数据库集群等,只有嵌入到业务里,才能通过提升业务的可扩展性或性能,从而产生价值。
上述似乎是废话,但恰恰是架构师工作的难点,大家可以想象一下,比如通过MyCat搭建个分库分表架构不难,甚至把分库分表组件通过负载均衡搭建成集群也不难,这些网上都有现成的案例。
但如何要在当前的业务系统里实现分库分表,难度就不小了。具体来讲,因为业务系统里或许有冗余数据,而且有各类带join, group by等的查询语句,如何在分库分表系统里兼容这些历史问题,而且在上线新分库系统后迁移历史数据,又如,在产线切换到分库分表时,万一有问题如何回退,这些绝非是知道些Demo案例的高级开发能解决的问题。
所以在技术和业务方面,我自己的感受是(包括我见到的和听到的) :只有接触到业务了,才能用技术解决实际问题,才能更了解这个技术用起来的各类坑,像刚才提到的分库分表是这样,其它的诸如日志组件,消息队列组件都这样。通过下面部分给出的架构师平时要解决的实际问题的讲述,大家能更深刻地体会到这点。
2、资深架构师平时要解决的问题
如下的问题均是来源于实际,出于项目保密的原则,本人隐去了关键性的业务描述,但大家都能看懂,并能感受到架构师平时要解决问题的难度。
问题一,A公司有财务管理人事管理等10个左右的项目,它们在产线上,需要标准化管理,比如用同一个Maven仓库,不论功能业务如何,得用同一套配置管理服务,用同一套日志管理和分析组件,还得用同一套大数据组件来根据不同的业务维度来分析数据。
如果是重新搭建一套系统,这个难度也不小,更何况,对资深架构师的要求是,在历史项目的技术上做标准化管理,否则每个项目各管各的,维护成本大不算,不同项目间的库还很容易产生冲突。架构师要在保持业务稳定的前提下实现这点,大家可以考虑下难度。
问题二,随着B公司业务量的上升,数据库里的数据达到了T级,所以需要通过分库分表来实现优化。这本身不难,但如何在升级的过程中保持业务的稳定?不能说上个功能点,关键业务就挂了,而且,万一上线后出现问题,得提供应急的回退方案。
问题三,C公司是个创业型公司,刚开始的时候,通过SSM外加Oracle,能满足大多数的业务需求,但随着业务量的提升,需要资深架构在短时间里实现针对高并发和大数据的方案,比如并发量高了,系统至少不能垮,而且针对每笔订单,处理可以稍作延迟,但不能丢数据。
问题四,D公司需要在linux上搭建一套和产线一样的测试环境,在平时的开发过程中,各业务组可以通过工具,在测试环境上部署或回退本项目的组件,这里,不仅要搭建测试环境,更要通过jenkins等工具给各业务组搭建一套能便捷部署系统的工具。
除了上述的问题之外,资深架构更像一个救火队员,比如在公司的业务体系里,任何一个团队报出的和架构相关的问题,比如调消息队列有延迟,调分库分表时报内存OOM异常了,或者因Dubbo底层而导致的延迟或OOM,资深架构得能亲自或带领手下解决具体的问题。
3、和高级开发相比,资深架构一定得精通的技能(或素质)
其实高级开发和资深架构在需要掌握的技能方面,并没太大的差别,具体而言,能帮助实现性能优化的分布式组件和数据库组件(或者叫中间件)也就这么多,linux下的操作命令也就这么些,一些系统管理的工具,比如Maven,Jenkins,ant等的用法也不难。但和高级开发相比,资深架构的差别在于如下几点。
第一,资深架构解决的问题种类和数量要比高级开发多很多,所谓神枪手得靠子弹喂出来,有些问题,比如针对Kafka消息中间件的问题,资深架构一看日志就知道该怎么改,或者一看log4j错误信息就知道和其它哪些类有冲突了,又如,在搭建线程池时遇到了OOM问题,资深架构估计也能通过简单地看日志,也能快速定位问题所在。
也就是说,资深架构已经积累了很多处理问题的经验,遇到一般问题时,无需再通过比较耗时的debug看问题根源,往往在脑子里已经存储了大量可能会导致问题的原因,再通过查看关键日志即可定位到具体的代码点,然后就能很快地给出解决方案。
第二,在给出解决方案时,比如要上个分布式redis集群,或者上个消息中间件,对高级开发而言,往往会有很多试错的时间,比如上线后有某些功能点没调通,得通过Debug或查日志来逐一解决问题,或上线某个基于python的大数据分析系统后,虽然能满足基本的功能,但在某个场景(比如写日志线程并发量太多)里,可能会导致OOM异常。
而对资深架构来说,往往之前已经做过同类事情,所以能避免很多坑(少了很多试错成本和时间),而且由于对底层代码比较熟悉,所以哪怕出现比较疑难的问题(比如不能稳定重现),资深架构能通过看日志很快定位到具体的底层类,(而高级开发一般对此就束手无策了)。相比之下,资深架构的中流砥柱效应就能体现出来。
第三,资深架构一般具有对各组件的差别非常了解,比如做分布式队列,该先用Kafka还是rabbitMQ,或者搭建数据库集群时,该用MySQL里的哪种引擎。
4、对于程序员而言,如何高效地升级到架构或资深架构?
5、在升级路上,如何避免一些坑
6、指导技术难于自己实现功能,再论资深架构的协调(或者说扯皮)能力的炼成
7、总结,版权说明
评论