架构师，这个title就和总监之类的title同样，已经完全被用烂了，但在一个软件产品的生命周期中，架构师是实实在在的一个极度重要的角色，这篇文章就来说讲我以为的架构师的画像，到底具有什么素质的同窗是贴合架构师形象的，同时欢迎你们回复下在你心目中NB的架构师的画像是怎么样的呢。php
业务理解和抽象能力 架构师的第一职责是理解业务，并转换为可被研发理解的实现方案，所以业务理解能力是架构师的必备技能，一般来讲一个资深的业务架构师，对业务会有很是深的认识和积累，一个极好的业务架构师应该能大概预判业务将来的发展趋势，以便在系统的可扩展性上留好必定的空间，因此也会很天然的出现有些业务架构师作着作着就干脆转为PD类型的角色。 抽象能力是经过对业务的理解转换为系统实现的模型，这显然也是重要的能力，抽象不少时候也承担了分解清楚多个团队的职责，分工清晰化。架构
NB的代码能力 之因此如今不少的架构师都会被认为是大忽悠，就是有一堆顶着架构师头衔，又不干活的人（甚至会出现对技术几乎不太懂的人），光说不干，再加上说的不靠谱的话天然很容易被认为是大忽悠，就我本身而言，我一直认为架构师有个很是重要的职责是编写整个系统中核心部分的代码，这个部分并必定是技术挑战最高的，但对整个系统的质量/成败与否是具有很是关键的控制做用的，因此架构师必须是从写核心代码的人中诞生出来的。 在一个跨多领域的大型系统中，架构师不太可能什么都擅长，不可能写各个部分的核心代码，这种时候架构师必定要知道怎么判断非本身知识领域的部分实现是否OK，以确保各部分组合在一块儿的时候是符合架构设计预期的，一般这种确保各部分组织在一块儿work的机制部分的代码应该由架构师本身操刀。负载均衡
全面 全面是一个架构师展示出来的最关键素质，全面会体如今三点上：框架
在面对业务问题上，架构师脑海里是否会浮现出多种技术方案，这点其实挺重要的，不然可能就会出现明明有一个简单成熟的方案，但因为不知道而作了其余复杂不成熟的方案，因此广阔的技术视野是架构师的必备，另外架构师不可能所有擅长，在本身不擅长的点上，须要知道找哪一个专业的人是靠谱的，这点也很是重要；架构设计
在作系统设计时是否考虑到了足够多的方方面面： 例如不少系统设计容易遗漏上线环节的细节，致使在上线时发现漏掉了什么考虑，临时解决或只能重来，记得有一年我作的一个设计没有考虑到上线阶段的一个细节，致使上线的时候发现因为网段的问题彻底不work，而且没有临时解决方案，只好重来，系统设计不只仅指导研发同窗怎么写代码，也包括指导其余全部相关技术同窗的工做； 又例如我2008年在作服务框架设计的时候，集群和集群之间经过硬件负载均衡设备来访问的，链接的方式是单个长链接，这个设计致使了运行过程当中若是要发布被调用的服务方，很容易出现压力都集中在前面重启的机器上，这也是典型的整个链路没有考虑清楚形成的设计问题； 再例如2013年我在作一个比较大范围的系统改造的设计时，因为对其中一部分的软件了解的不够，判断错误，致使后来这个改造在进行过程当中才发现有些须要改造的关键软件的设计作的太粗糙，最后上线进度差很少推迟了一个多月，并且那些后来补的设计都是紧急作的，风险很是高； 回顾本身设计过的软件，发如今这个点上犯的错能够讲好几天，看来我应该整理另一篇文档《我在系统设计上犯过的xxx个错误》，里面有些其实靠一份好的系统设计模板也许就能避免掉，一份好的系统设计模板是能够帮助架构师思考全面些的。设计
在作系统设计时是否考虑到了将来的一些发展，尽量不要出现将来的一点变化就致使如今白干或要花大量力气来改造的现象，想当年作服务框架的时候，后来就发现因为当年作设计的时候没有考虑到未来服务调用trace的问题，致使了后来为了弥补这点花了巨大的力气（不是技术上，而是实施上）。生命周期
全面须要架构师有足够广的技术领域知识和足够多的经验积累，从全面这点就能够看到架构师的工做毫不是画几个框，连几根线那么简单。文档
对架构师全面这点的挑战，会随着系统的范围越大（一个系统的设计，和100个系统组成的大系统的设计挑战是彻底不一样的）而变得越难，不管是知识的广度、考虑的点的覆盖度、仍是将来趋势，更复杂的状况甚至会出现架构的调整对应着组织结构的调整，这种也要考虑到，例如服务化这种大的架构改造，就意味着专职的专业领域服务团队的成立。产品
全局 全局观一般是指在系统设计时是否考虑到了对上下游的系统的影响，毕竟一般所设计的系统不是一个孤立的系统，若是没有足够好的全局观，有可能会致使本身的系统作完上线，其余上下游系统（尤为有些连上下游是谁，怎么用的都不知道的状况下）出现问题，这种案例一样很多。it
权衡 权衡一样也是架构师极度重要的能力，或者也能够认为是决策能力，技术方案的拍板是一个架构师最重要的职责。 上面说的全面是架构师在思考时开的过程，而权衡就是收的过程，收的过程结束基本就意味着技术方案的肯定，同时也肯定了节奏，权衡在两点上会体现的特别突出：
技术方案决策原则 一般一个问题都会有多种可解决的技术方案，怎么来决策就相当重要了，而决策一般又和全面相关，大的来讲一般决策的原则就是性价比和可持续发展。 性价比简单来讲是方案的实现成本，这个成本要包括很是多的方面，例若有些场景可能会是用硬件解决看起来是花钱，但最终折算成本是最划算的，不少系统设计在决策性价比时都过于随意，例如一个另外常见的场景就是建设一套新系统替代旧系统，这个时候可能彻底没考虑旧系统的迁移代价甚至超过了改造旧系统的代价； 可持续发展简单来讲就是所选择的技术方案在公司是否可持续，例如简单的案例是公司主体的研发人员都是php，却搞一个其余语言，且只有极少人懂的（固然，这仍是要看性价比，若是搞一个其余语言带来的效益超过了语言/人才体系的更换成本），又例如引入一个开源产品，有无专业团队维护这都是要考虑的关键因素。
优先级和节奏控制 常常我会问作系统设计的同窗一个问题：对于这个业务场景而言，在系统设计上最须要把握的一个点是什么；这是一个关键问题，全面意味着考虑到了不少地方的问题，但一般业务需求实现都是有很强的时间要求的，所以在这个时候必须考虑清楚不一样点的优先级，同时也包括技术方案在决策时也要作出取舍，有可能选了一个不是那么好的技术方案，但经过留下一些可改造的空间，为之后的重构作好铺垫，那就是很不错的，尤为技术同窗有些时候比较容易陷入解决技术问题的场景去，但那个问题其实有可能不是现阶段最重要的。
其实优先级和节奏控制是我认为一个最NB的架构师的最佳体现，优先级意味着把握住了重点，能够确保在所设计的架构指导下业务实现不会出现大问题，节奏控制则意味着全面，为未来作好了铺垫