什么样的架构师是一个好的架构师呢？

第一，程序员的基本功扎实到位。

了解常用平台、语言、数据库的特点；能够根据需求搭配出最适用的开发配置方案；知道怎么写代码性价比最高；知道判断一个程序员是否在工作，有可能不是看他写了多少行代码，也可能是看他减少了多少行代码。这是深度。

我觉得架构师跟职位和位置等并没有必然的联系， 任何人在任何场景都可以是架构师， 无非架构的粒度和自我的架构认知不同而已。

我一直在强调一名合格的架构师， 但如果非要我划分更高一档的架构师的话，还有一档卓越的架构师， 而责任， 是走向卓越架构师的必经关卡。

随便打开某招聘网站：系统架构师、搜索架构师、前端架构师、iOS/Android 架构师、平台架构师、（大）数据架构师、JAVA/PHP/.NET 架构师、高级架构师、资深架构师、BI 架构师，这些是大家常见的，君不见还有后台架构师、MIS/ERP/OA 系统架构师、金融系统架构师、搜索架构师、总线架构师、运维架构师，安全架构师...... 林林总总，不一而足。

仅仅是上面这些岗位名称，就能看到架构师岗位的差异之大，方向不同、技术栈不同、行业不同，即便同一个岗位，水平差距也是天壤之别，如果仅以架构师一个称谓来描述，显然是不合适的，所以我觉得今天在行业内这个称谓还有点”虚”。

架构师都做些什么？

1. 架构设计

架构师，顾名思义，第一职责就是在软件设计阶段，做好软件「骨架」的设计。架构师需要把产品的需求翻译成软件工程的设计文档，确定各个系统与模块的边界，评估系统的量级。

2. 技术选型

从前端到后端，从缓存到数据库，面对为数众多的第三方组件，架构师需要作出合理的选择。

前端页面选择模板引擎还是动静分离？服务端选择 Java 还是 Node.js？

服务治理选择 DubboX 还是 Spring Cloud？

消息队列选择 RocketMQ 还是 Kafka？

分布式缓存选择 Redis Cluster 还是 Codis？

数据库选择 Mysql 还是 Oracle？

全文检索选择 Solr 还是 ES？

技术没有绝对的好坏之分，关键看是否适用于公司的业务场景。

现在的大公司，有没有专门的架构师团队，要不要搞个这样的组织形式？

我认为可能最终是看技术负责人的治国思路；但有一点是需要澄清的：很多大公司到最后基本上架构组织就退化掉了，因为复杂系统到了一定程度，只靠架构组织是搞不定一个复杂组织的发展的，但前期架构组织如果奠定了很好的基础，比如强大的中后台，那么， 对于大型组织来说， 组织演化就会平滑的多。架构师团队和架构部（平台部，基础架构部等等）不见得对等，而且架构设计是一个角色（可由个人或团队承担），而架构师是一个职位。

Twitter机器学习平台组负责人郭晓江：

机器学习在业界应用的两大目标是规模化(Scalability)和灵活性(Flexibility)。规模化是系统方面的要求，强调高并发、稳定性、高可复用性等，是应用到产品中的关键；而灵活性是要求能够快速迭代，不断尝试新的算法。

组织结构上一般会有两个平行的团队，一个偏重算法研究，比如Google和Facebook都有专门做机器学习研究的团队，主要是解决灵活性的问题；另一个团队是偏重机器学习平台，和产品应用结合的比较紧密，主要解决规模化的问题。

架构评估的两种方式

第一种通过性能建模来评估吞吐量和伸缩性，通过失效树模型来评估可靠性和可访问性。其他类型的模型包括复杂性和耦合指标，用于评估可变性和可维护性。

第二种就是通过对架构师提出质询来评估架构，质询方法的另一种变体是架构折中分析方法，它寻找架构不能满足品质关注点的风险。

好的架构师，一定是好的程序员

• 没写过N年代码，何来指点江山？

• 没做过N年架构实践，何以指导避坑？

• 只有框架，没有细节，何以服众？

bad case：项目失败了，架构师点评技术团队“能力差”

bad case ：项目失败了，技术团队点评架构师“只会忽悠”

所以架构师可以力排众议，但不能成为千夫所指。

比如我们经常遇到时间紧迫要做临时方案，不考虑扩展性，如果同类的业务模式重复出现，再做临时方案虽然大家都轻车熟路，却不是一个好的选择。

因为有再一再二，就会有再三再四，只要把握住这一点，尽早进行架构改造，实现后就能快速响应后续的同类需求，这也体现了架构师的价值。

架构师=前端工程师+后端程序员+系统分析师+关键技术解决+各种技术搭配+设计模式+部署调优+其他，可见架构师是多面手，在项目当中起到连接管理与项目成员的重要角色。因此，在通往大神级的架构师的道路上，你需要懂需求、设计、代码、部署、架构、服务器、运维、调优等等。