江苏龙网

  1. 主页 > 生活百科 > >

架构师的技术升级之路

这篇文章更多的是从沟通角度分析架构师的升级之道 。但我们知道，架构师更多是靠技术拿高薪 。
在本文里，我将列些我见到的技术架构平时需要解决的问题，有技术的，也有沟通协调方面的，以这些实实在在的案例，来列举些技术架构需要具备的技能，以此来分析下高级开发如何更高效地升级到技术架构 。好了，开场白结束，正文开始 。

架构师的技术升级之路

文章插图
 
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等的用法也不难 。但和高级开发相比，资深架构的差别在于如下几点 。
1 资深架构解决的问题种类和数量要比高级开发多很多，所谓神枪手得靠子弹喂出来，有些问题，比如针对Kafka消息中间件的问题，资深架构一看日志就知道该怎么改，或者一看log4j错误信息就知道和其它哪些类有冲突了，又如，在搭建线程池时遇到了OOM问题，资深架构估计也能通过简单地看日志，也能快速定位问题所在 。


推荐阅读


上一篇：演员黄圣依近照 黄圣依童年照

下一篇：梦到自己上不了厕所 梦见想上厕所却上不出来