架构师成长之路

架构师已经被叫烂了。

似乎是个人都可以叫架构师。

但真的是这样吗？答案是否定的。

架构师源自于建筑工程，原始释义为建筑师。从工程学上看，我们在搭建一栋房子时需要先从图纸开始，建模、制图、刻度、精细化等；然后才是验证：验证可靠性、安全性、稳定性等，之后才是构建。前两步都属于建筑师需要考虑的范围。目前其他领域或行业的需要执行类似操作的人也都被冠名为架构师，突然之间架构师就多了起来。

在IT领域，随着企业架构框架的不断发展，架构师的细分也越来越复杂，但是不论怎样，架构师需要具备的几项技能是一个也不能少。初步总结如下：扎实的理论基础、 逻辑思维及抽象能力、相关知识的储备、架构设计能力以及软技能。其中最重要的还是逻辑思维及抽象能力。架构就是要将需要实现的现实的事物通过抽象变成可以通过简单描述和进行建模的对象的过程。

图一 架构师技能

做到了以上几方面后就可以成为架构师吗？答案是不一定。

你需要在某一个领域有丰富的经验以及一定的建树。目前在IT方面，由企业架构框架定义的领域包括业务、系统（应用、数据）、技术、安全等，当你在某一个领域成熟后，才能被称之为领域架构师，之上还有解决方案架构师、企业架构师、CTO等，都需要你逐步的去沉淀自身的各项专业能力。

而在架构逐步成长的过程中，你会发现技术与业务的比重也在逐步的发生变化，也就是说越往上层走，业务的比重会越大，越来越多的是对业务的领悟，对业务模式的思考，对运营模式的总结。或者换一个角度描述：大道至简，有时在技术上很难实现的需求可能在业务上可以轻易的绕开，或者很难实现的需求实际就是不懂业务人员的假想敌。

图二 架构师成长阶梯

不论怎样，有志往上走的人员都不约而同的会经历以上几个阶段。

下面给大家分享一个我亲自经历的案例，也算是一种磨练的乐趣。我取名为“N进N出”。

 

案例名称：存储选型的N进N出：

 

一进：

考虑该课题下的对存储的要求：吞吐量IOPS以及相应时间要求；

考虑目前市面上的集中式存储以及分布式存储的优缺点；

考虑历史项目使用的存储总体情况以及未来存储的发展情况；

选择分布式对象存储-- ceph

一出：

领导一句话就给批回来了： 没有考虑后期的运维。

二进：

在之前的基础上进一步考虑的点：

考虑设备成本以及存放空间；

考虑实施可行性以及运维可行性；

主要考虑目前三产单位的对存储的运维能力，发现对传统的集中式GFS比较熟悉；

选择集中式存储---GFS，采用分文件系统集群的方式，我们梳理了需求，归纳了6、7套文件系统集群

二出：

领导又是一句话：你们的20T怎么来的？

三进：

是啊，我们从来没有想过这个问题，

在之前梳理的拆分文件系统集群的需求基础上，进行了用户的调研，讨论，最终将20T文件降到了3T。

同时对比较成熟的存储产品做了POC的验证：ceph、glusterFS、Netapp、宏杉、GFS等，同时发现了GFS的局限性，集群不能大于16节点

选择集中式存储：NAS

三出：

没有考虑存储的最重要的一部分：安全性

四进：

系统可以支撑未来10年发展

存储的备份、 异地多活、 未来的可扩展性、等

四出：

领导要求协调集团及子公司各领域专家进行最终的评审

成长的路上少不了汗水，让我们撸起袖子再出发。

 

个人网站：文凡小筑（http://www.wenfans.com）同步发布，敬请关注。