架构师第一职责师理解业务并将其抽象转换为可被研发理解实现的方案。一个好的架构师应该能大概预判业务未来的发展趋势，以便在系统的扩张性上留好一定的空间。因此架构师要有较强的业务理解和抽象能力，能承担分解清楚多个团队的职责，分工清晰化。

　　例如很多系统设计容易遗漏上线环节的细节，导致在上线时发现漏掉了什么考虑，临时解决或只能重来，记得有一年我做的一个设计没有考虑到上线阶段的一个细节，导致上线的时候发现由于网段的问题完全不work，并且没有临时解决方案，只好重来，系统设计不仅仅指导研发同学怎么写代码，也包括指导其他所有相关技术同学的工作；

　　3. 在做系统设计时是否考虑到了未来的一些发展，尽可能不要出现未来的一点变化就导致现在白干或要花大量力气来改造的现象，想当年做服务框架的时候，后来就发现由于当年做设计的时候没有考虑到将来服务调用trace的问题，导致了后来为了弥补这点花了巨大的力气（不是技术上，而是实施上）。

　　全面需要架构师有足够广的技术领域知识和足够多的经验积累，从全面这点就可以看到架构师的工作绝不是画几个框，连几根线那么简单。

　　上面说的全面是架构师在思考时开的过程，而权衡就是收的过程，收的过程结束基本就意味着技术方案的确定，同时也确定了节奏，权衡在两点上会体现的特别突出：

　　通常一个问题都会有多种可解决的技术方案，怎么来决策就至关重要了，而决策通常又和全面相关，大的来说通常决策的原则就是性价比和可持续发展。

　　性价比简单来说是方案的实现成本，这个成本要包括非常多的方面，例如有些场景可能会是用硬件解决看起来是花钱，但最终折算成本是最划算的，很多系统设计在决策性价比时都过于随意，例如一个另外常见的场景就是建设一套新系统替代旧系统，这个时候可能完全没考虑旧系统的迁移代价甚至超过了改造旧系统的代价；

　　可持续发展简单来说就是所选择的技术方案在公司是否可持续，例如简单的案例是公司主体的研发人员都是php，却搞一个其他语言，且只有极少人懂的（当然，这还是要看性价比，如果搞一个其他语言带来的效益超过了语言/人才体系的更换成本），又例如引入一个开源产品，有无专业团队维护这都是要考虑的关键因素。

　　经常我会问做系统设计的同学一个问题：对于这个业务场景而言，在系统设计上最需要把握的一个点是什么；这是一个关键问题，全面意味着考虑到了很多地方的问题，但通常业务需求实现都是有很强的时间要求的，因此在这个时候必须考虑清楚不同点的优先级，同时也包括技术方案在决策时也要做出取舍，有可能选了一个不是那么好的技术方案，但通过留下一些可改造的空间，为以后的重构做好铺垫，那就是很不错的，尤其技术同学有些时候比较容易陷入解决技术问题的场景去，但那个问题其实有可能不是现阶段最重要的。

　　优先级和节奏控制是我认为一个最NB的架构师的最佳体现，优先级意味着把握住了重点，可以确保在所设计的架构指导下业务实现不会出现大问题，节奏控制则意味着全面，知道随着业务发展该在什么时间点做什么事，为将来做好铺垫。

　　架构师有个非常重要的职责是编写整个系统中核心部分的代码，这个部分并一定是技术挑战最高的，但对整个系统的质量/成败与否是具备非常关键的控制作用的，所以架构师必须是从写核心代码的人中诞生出来的。

　　在一个跨多领域的大型系统中，架构师不太可能什么都擅长，不可能写各个部分的核心代码，这种时候架构师一定要知道怎么判断非自己知识领域的部分实现是否OK，以确保各部分组合在一起的时候是符合架构设计预期的，通常这种确保各部分组织在一起work的机制部分的代码应该由架构师自己操刀。

　　编码能力：（一面基础知识）写代码能力是基本功，Java语言本身，从最简单的数据和链表hash数据结构，到泛型，多线程，并发的理解，对JVM，内存使用对理解，对Java运维的理解等等。语言本身外，社区里常用的框架是否可以十分清晰的了解，包括spring，包括他实现的ioc，aop，orm，web机制是否有清楚的认识，有丰富的经验等等。

　　对常用中间件的理解 （一面基础知识）毕竟在一个大系统中，各种中间件是是否常见的，缓存中间件，消息中间件，例如 redis、memcache、rmq这些。要理解常用中间件使用场景，使用姿势（例如redis的常用命令），甚至包括他的一些运维。一旦出了问题，除了专门的运维人员，也需要你参与问题的排查，因为有时候这些中间件出现问题，是不当的使用姿势引起的。

　　架构、业务落地能力 （二面架构能力）前面提到了语言本身，各种中间件。如果你有很好的业务抽象能力和架构思维，就可以把一款部门内部产品很好的设计并实施了。这点蛮难的。想必都有过接手现有项目的经历吧，有时候真恨不得把之前的设计者拿出来批斗。作为一个设计者，你能否做到当下一个接手它的人会说一句，这个系统设计的真好，稳定又可拓展，理解起来也很容易。这需要很多能力，除了对现有系统的理解，还包括对未来可能发生变化的理解

　　如何探查你的架构能力呢？讲一讲你过去项目中你最了解的或者你设计的觉得最负责的系统，1.画一画架构图，2.用到了什么技术。3.遇到什么困难，如何解决。

　　沟通协作毕竟一个部门内部产品，是不可能由一个人完成的，所以需要沟通协作，把设计好的方案，要和2-3个小伙伴一起实施，包括同样身份的后端人员，前端人员，产品等角色。这个级别的人可能会参与带2-3个人，例如应届毕业等，所以你自己对知识的把握，分享精神，leadership都是很好的加分项。