架构需要由人去设计，这些人被称为架构师。或许很多人并未授予架构师的头衔，但自己却从事着架构的工作。我们认为，架构这项工作永远都需要由人去完成，可能短期内都无法由机器来取代。如果我们不理解什么是架构，或者对架构师的职责感到疑惑，那么很难让架构这项工作有效地落地。我们将在本节重新认识架构，并重新定义架构师的职责。此外，架构演进是一个曲折的过程，但我们却不难看出架构的发展规律，甚至还能推测出架构将来的发展趋势。我们相信，微服务一定不是架构的终点，它或许只是架构从重量级转型为轻量级的桥梁，我们正是设计并建造这座桥梁的工程师。
现在我们从架构与架构师的角度开始出发，开启轻量级微服务的架构探险之旅。
1. 架构与架构师
可能绝大多数的程序员都想成为一名优秀的架构师，每天都能从事技术架构的相关工作，编点框架代码，画点架构图，写点PPT，帅气地站在讲台上给程序员们进行技术培训。大家普遍认为，架构师的代码比别人写得少，但是工资却比别人拿得多，架构师是技术团队中技术最牛的人，别人搞不定的技术问题，在架构师眼中都是小菜一碟。
这样的人真的是架构师吗？
我们认为，他们不是架构师，而是技术专家。其实架构师与技术专家有着本质的区别，从他们所关注的技术方向来看，架构师更偏向技术广度，而技术专家更偏向技术深度，如图1-1所示。
换句话说，架构师需要有较强的综合能力，他们需要接触的技术领域较广，但他们所掌握的技术专业能力却没有技术专家那么深。如果我们想成为一名架构师，那么就不应该把所有的精力都投入在某个技术领域上，而是要学会分散自己所关注的层面，做到在众多技术领域上都要有一定的深度。
架构师除了需要具备在技术上所需的“硬技能”，还需要不断完善自己的“软技能”，比如沟通、组织、学习等技能。有时候软技能可能比硬技能更加重要，甚至软技能还会影响自己的职业发展。如果没有较好的软技能，架构师将无法将自己所设计的架构顺利地移交到程序员们手中，并指导他们将其真正落地。架构师正是通过他们所具备的综合能力来带领技术团队，解决不断出现的技术挑战。
架构师的职责是什么？
我们的回答是：制定规范 + 指导落地。
架构师根据业务需求所制定的合理且可落地的技术规范，我们将这样的规范称为架构。
将架构工作做好犹如我们用两条腿走路一样，左腿迈出去表示“制定规范”，右腿跟上来表示“指导落地”，如图1-2所示。
如果左腿迈出去，右腿没跟上来，那不是架构师，可能是需要拄拐的人。然而，我们身边却有一些这样的不合格的架构师，他们只懂得制定规范，却忽略了指导落地。如果架构无法落地，那么就无法称为架构了。
此外，还有一些架构师认为，架构只是技术层面上的问题，自己设计的架构应该用到市面上最为流行的新技术，比如别人公司在用微服务，那么自己公司也要用起来。如果将架构工作脱离于业务需求，我们认为这不是做架构，而是玩技术。脱离业务来设计架构是对架构的不尊重。微服务是一种应用系统架构，需要架构师围绕业务进行设计。
但是，我们绝不要为了微服务而去微服务。
从事微服务架构工作的架构师，相比传统架构的架构师而言，所要求的技能更加全面。他们不仅仅是系统架构师，也是业务分析师，他们的责任重大且挑战艰巨。
从大的方向来看，微服务架构师需要具备以下基本职责。
（1）分析业务需求并切分微服务边界。
（2）定义架构规范与文档标准。
（3）确保微服务架构顺利落地。
（4）改善微服务架构并提高开发效率。
职责与挑战往往是无法分离的，微服务架构师必须面对并克服这些挑战。
（1）架构需要适应不断变化的业务需求。
（2）架构具备稳定性、扩展性、安全性、容错性等。
（3）使技术团队深刻理解微服务思想。
（4）展现微服务架构的价值。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
