刚又看到阿里JAVA技术大牛毕玄的《架构师画像》一文，总结一下一个合格的架构师应该具备哪些能力。
- 业务理解和抽象能力。
-
架构师第一职责师理解业务并将其抽象转换为可被研发理解实现的方案。一个好的架构师应该能大概预判业务未来的发展趋势，以便在系统的扩张性上留好一定的空间。因此架构师要有较强的业务理解和抽象能力，能承担分解清楚多个团队的职责，分工清晰化。
-
- 全面、技术广度
-
全面是架构师最关键的素质之一，不仅要技术全面，还要考虑足够多的方面，并考虑未来的一些发展。
1. 在面对业务问题上，架构师脑海里是否会浮现出多种技术方案，这点其实挺重要的，否则可能就会出现明明有一个简单成熟的方案，但由于不知道而做了其他复杂不成熟的方案，所以广阔的技术视野是架构师的必备，另外架构师不可能全部擅长，在自己不擅长的点上，需要知道找哪个专业的人是靠谱的，这点也非常重要；
2. 在做系统设计时是否考虑到了足够多的方方面面：
例如很多系统设计容易遗漏上线环节的细节，导致在上线时发现漏掉了什么考虑，临时解决或只能重来，记得有一年我做的一个设计没有考虑到上线阶段的一个细节，导致上线的时候发现由于网段的问题完全不work，并且没有临时解决方案，只好重来，系统设计不仅仅指导研发同学怎么写代码，也包括指导其他所有相关技术同学的工作；
3. 在做系统设计时是否考虑到了未来的一些发展，尽可能不要出现未来的一点变化就导致现在白干或要花大量力气来改造的现象，想当年做服务框架的时候，后来就发现由于当年做设计的时候没有考虑到将来服务调用trace的问题，导致了后来为了弥补这点花了巨大的力气（不是技术上，而是实施上）。
全面需要架构师有足够广的技术领域知识和足够多的经验积累，从全面这点就可以看到架构师的工作绝不是画几个框，连几根线那么简单。
-
决策能力，技术方案的拍板是一个架构师最重要的职责。
上面说的全面是架构师在思考时开的过程，而权衡就是收的过程，收的过程结束基本就意味着技术方案的确定，同时也确定了节奏，权衡在两点上会体现的特别突出：
1. 技术方案决策原则
通常一个问题都会有多种可解决的技术方案，怎么来决策就至关重要了，而决策通常又和全面相关，大的来说通常决策的原则就是性价比和可持续发展。
性价比简单来说是方案的实现成本，这个成本要包括非常多的方面，例如有些场景可能会是用硬件解决看起来是花钱，但最终折算成本是最划算的，很多系统设计在决策性价比时都过于随意，例如一个另外常见的场景就是建设一套新系统替代旧系统，这个时候可能完全没考虑旧系统的迁移代价甚至超过了改造旧系统的代价；
可持续发展简单来说就是所选择的技术方案在公司是否可持续，例如简单的案例是公司主体的研发人员都是php，却搞一个其他语言，且只有极少人懂的（当然，这还是要看性价比，如果搞一个其他语言带来的效益超过了语言/人才体系的更换成本），又例如引入一个开源产品，有无专业团队维护这都是要考虑的关键因素。
2. 优先级和节奏控制
经常我会问做系统设计的同学一个问题：对于这个业务场景而言，在系统设计上最需要把握的一个点是什么；这是一个关键问题，全面意味着考虑到了很多地方的问题，但通常业务需求实现都是有很强的时间要求的，因此在这个时候必须考虑清楚不同点的优先级，同时也包括技术方案在决策时也要做出取舍，有可能选了一个不是那么好的技术方案，但通过留下一些可改造的空间，为以后的重构做好铺垫，那就是很不错的，尤其技术同学有些时候比较容易陷入解决技术问题的场景去，但那个问题其实有可能不是现阶段最重要的。
优先级和节奏控制是我认为一个最NB的架构师的最佳体现，优先级意味着把握住了重点，可以确保在所设计的架构指导下业务实现不会出现大问题，节奏控制则意味着全面，知道随着业务发展该在什么时间点做什么事，为将来做好铺垫。
-
架构师有个非常重要的职责是编写整个系统中核心部分的代码，这个部分并一定是技术挑战最高的，但对整个系统的质量/成败与否是具备非常关键的控制作用的，所以架构师必须是从写核心代码的人中诞生出来的。
在一个跨多领域的大型系统中，架构师不太可能什么都擅长，不可能写各个部分的核心代码，这种时候架构师一定要知道怎么判断非自己知识领域的部分实现是否OK，以确保各部分组合在一起的时候是符合架构设计预期的，通常这种确保各部分组织在一起work的机制部分的代码应该由架构师自己操刀。