所以在技术和业务方面,我自己的感受是(包括我见到的和听到的) :只有接触到业务了,才能用技术解决实际问题,才能更了解这个技术用起来的各类坑,像刚才提到的分库分表是这样,其它的诸如日志组件,消息队列组件都这样。通过下面部分给出的架构师平时要解决的实际问题的讲述,大家能更深刻地体会到这点。
二、资深架构师平时要解决的问题
如下的问题均是来源于实际,出于项目保密的原则,本人隐去了关键性的业务描述,但大家都能看懂,并能感受到架构师平时要解决问题的难度。
问题一,A公司有财务管理人事管理等10个左右的项目,它们在产线上,需要标准化管理,比如用同一个Maven仓库,不论功能业务如何,得用同一套配置管理服务,用同一套日志管理和分析组件,还得用同一套大数据组件来根据不同的业务维度来分析数据。
如果是重新搭建一套系统,这个难度也不小,更何况,对资深架构师的要求是,在历史项目的技术上做标准化管理,否则每个项目各管各的,维护成本大不算,不同项目间的库还很容易产生冲突。架构师要在保持业务稳定的前提下实现这点,大家可以考虑下难度。
问题二,随着B公司业务量的上升,数据库里的数据达到了T级,所以需要通过分库分表来实现优化。这本身不难,但如何在升级的过程中保持业务的稳定?不能说上个功能点,关键业务就挂了,而且,万一上线后出现问题,得提供应急的回退方案。
问题三,C公司是个创业型公司,刚开始的时候,通过SSM外加Oracle,能满足大多数的业务需求,但随着业务量的提升ÿ