架构师这个职位大概是绝大多数想要做技术的程序员的梦想了，当然上面还有一个CTO，但是那个CTO得看缘分了，而这个架构师的职位是使一把劲还是有可能的那种。那么到底是什么是架构师，架构师需要什么要求？下面我就试着解释一下，欢迎各位对号入座，找到自己的薄弱点，查缺补漏，在江湖上的能有一叶扁舟吧。

一、什么是架构师？

Google给出的解释是：系统架构师是一个既要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型任务。一个架构师得需要足够的想象力，能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。

而把这段话翻译成大白话的意思就是：架构师需要负责技术框架及能够进行技术攻关，给出整体架构方案，又能够解决局部的技术问题。能够自己了解明白业务需求，并能够根据自己的经验，完善业务需求。总结成一句话就是：尽自己所能，做正确的事情并把事情做正确。

在不同的行业，架构师可能面对的技术难题不一样，这里只研究软件行业的架构师可能会需要面对的问题。

二、架构师要求

1：必须要不断学习，虚心请教。而这时候的学习是在原有技术经验的基础上，因为已经有了一定的技术深度，现在的学习要着重技术的广度，当出来一种新的技术的时候，需要很快的了解它的优点缺点，进行技术储备等，所以勤奋和一定的学习能力基本上就是能成为架构师的基本素质了。因为软件行业技术的更新换代比较迅速，我还记得我在大学的时候还在学着非常难以理解的EJB，那时候就像学天书一样。而工作之后没用几年的struts2，接着就是Spring+Hibernate+mybatis，现在都开始用SpringBoot，再加上现在都在用springCloud，大数据，云计算等等。但自己终究不是一个人，不能所有的知识自己都能够掌握，不熟悉的一定要向领域的专家多多请教。

2：架构是决定应用的性能的根本因素。在设计前期，开发的整个迭代周期中，都应该是要持续的关注性能问题的，这样就可以在性能的问题上持续的进行检查，如果出现问题，也可以缩小问题的范围，做到快速解决。

    A: 设计的架构性能应该是满足业务的现在及可以看到的将来的一段时间内的需求的，这方面就要跟业务方面频繁沟通了，因为产品可能的推广，产品设想要能够达到怎么的目标等等。
      这些性能不仅是指后台的响应速度，还包括页面的响应速度，从用户有了请求，到最后返回请求的整个时间响应都是要考虑的。在整个开发阶段需要持续关注性能且要求达标。
    B：甚至包括一旦时间超过了，应该怎么响应，是让用户继续等待，还是有别的什么操作。
    C: 再有就是产品的版本不同之后，怎么兼容使用不同版本号的用户的请求。
     D: 非交互组件之间的性能等也在考虑之中。

3：减少架构复杂性。在开发过程中，尽量减少架构的复杂性。如果一件事情本身很难，那就尽量简化，如果因为设计复杂性，而导致解决问题的复杂的情况应该避免。

     在开发的过程中要尽量让开发人员自己做主。但是让开发人员自己做主并不意味着架构师应该完全放手，而应该是进行设计的监督，如有时间可以进行设计及代码的评审，来进行开发规范的实际落地，同时还能够帮助开发人员提升代码质量。

    在设计及开发的过程中应该持续控制项目规模，提倡开发“最简单有用的东西”。

    在开发的过程应该建立一套动态的架构地图，既能够从“高空俯瞰这个架构”，又能够“使用显微镜看到小的问题”。

4：彻底弄清楚业务，并清楚业务的意义。准确的说，整体的技术部都是为了完成业务需求而存在的。而架构师更是业务人员及开发人员的第一桥梁，当然在很多的公司，项目经理也可以担任这个角色。架构师可以多询问客户，分析业务或客户需求及功能的真正意义，也可以提出并客户更好的建议，成本更低的解决方案。

     在与业务人员进行沟通时要使用业务的眼光来看待问题，在与开发人员沟通时要使用技术的眼光来讨论需求，所以在合理的需求转化为技术实现时，架构师就是桥梁了。

     而在架构师是桥梁之前，架构师自身是必须要掌握业务领域知识的。

      在与业务人员讨论时要能够理清楚哪些是合理的需求，哪些是不合理的需求，哪些需求是需要在当前版本中实现中，哪些是要在以后的不同版本中慢慢完善的。同时要能够与业务人员量化那些描述模糊的需求。如：灵活，可维护，速度快，可扩展等。因为没有量化的需求别说开发人员无法开发，再最后验收项目时，业务人员也会觉得没有达到自己的要求。

       而在与开发人员进行讨论量化过的需求时，就必须要明确这是业务需求，需要被执行的。开发人员在提出自己的技术决策时，架构师必须沟通协调，坚持业务目标被实现。

5：架构师也是程序员。架构师是必须要能够参与开发的。不是在自己设计完架构后就可以甩手让开发人员填代码了。

       项目的整体设计是一定要平衡兼顾多方需求的。涉及到的各个部门都会对系统有一定的要求，架构师需要平衡各方的相关利益。确保业务需求的各方能够同意，并能够达到商业价值。

       搭建出来的框架是需要接收检验，开发人员提出建议时一定要认真思考，给出设计的原因，如果建议或者问题不符合或者用起来很麻烦，一定要进行优化。开发人员也是自己团队中成员，大家一起负责架构和开发。千万不可以为自己的架构就是完美的，当然也不要试图搭建一个完美的框架，因为它不存在。只有符合需求的框架。

6：重视数据。数据才是整个项目中最珍贵的部分。完成框架，完成开发，一定要确保数据的正确，且确保数据库中设计的简明，易懂，同开发规范一样，数据库设计规范也一样重要。

    不要忽视不起眼的问题，包括数据库中一个数据没有存，或者开发中的小问题，一定要及时发现，快速处理。

7：持续集成。

8：复用很重要。在开发过程中一定要能够抽出公共部分，并通过合理的方式让大家知道，最好是文档的，说清楚使用方式，什么时候可以使用等。要简单易用，节省大家的时间。

     通用的组件上，架构师必须要亲力亲为的。

9：对自己的产品负责。不要草率的提交任务。这样很不负责任。

10：掌握沟通的技能。这个是情商的部分了。架构师很大一部分工作是在沟通，所以沟通时的心态一定要把握好。任何的沟通对话都不是对抗，不要心存戒备。控制情绪，任何时候都应该以达成共同的目标为前提。目标是一致的，沟通也是学习和了解的过程。千万不可带着自己的情绪，这样会让对方认为你不怀好意。任何情况下都要知道自己是在谈判，是在沟通。在开发组内也要保持开放的氛围。

11：故障终究会发生。所有的你认为都想到的情况，哪怕你想了很多的安全机制，也会出问题的。出了问题不要急着想谁的责任，先把问题解决掉。

这里想引用《Java编程思想第四版》中第七章总结处所说的那句：程序的设计开发是一种增量过程，犹如人类的学习一样，这一点很重要。程序开发依赖于实验，你可以尽自己所能去分析，但当你开始执行一个项目时，你仍然无法知道所有的答案。如果将项目视作是一个有机的，进化着的生命体而去培养，而不是去打算像摩天大楼一样快速见效，就会获得更多的成功和更迅速的回馈。

       以严谨的思维去架构，去开放的心态去学习和讨论，以虚心的心态去请教，尽自己所能的做好这件事，并把它视为自己的一项荣誉。

以上的这些虽说是架构师经常面对的问题，但是哪一位开发人员，项目经理没有遇到过呢。多多学习，努力磨炼自己的性情吧。

公众号：互联网金融训练营。