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