阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处码农翻身「码农翻身」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

“我怎么才能成为一个软件架构师？”

这是很多小伙伴问我的一个问题，最近看到Kai Niklas讲架构师的一篇文章，其中的真知灼见引起了我的强烈共鸣，尤其是后面的非技术部分。翻译过来（略有删减），分享给大家。

我事先给一位同学看了一下，他说：当个架构师太难了吧，又要精通技术，还得会沟通，平衡，营销..... 我还是争取做个技术专家吧！

扪心自问，我这个架构师在很多方面也做得远远不够，继续学习吧！如果你的未来职业目标是架构师，强烈建议仔细阅读并收藏。

01 什么是软件架构师

在我们一头扎入细节之前，我们先得知道软件架构和架构师到底是什么：

软件架构师是一个软件专家，他可以做出高层的设计决定，规定技术标准，包括编码标准，工具和平台 -- Wikipedia

软件架构是一个系统最基本的组织方式，由其组件，组件之间的关系，组件和环境的关系表达出来。也包括决定设计和系统演化的原则。--Handbook of Software Architecture

02 架构的级别

架构可以在不同的抽象级别上完成，不同的级别要求不同技能，有很多分类标准，我最喜欢的是这三个级别：

Application Level （应用级别）：架构的最低级别，专注于单个应用，有非常具体的设计，沟通通常局限在开发团队

Solution Level （解决方案级别）：架构的中间层，需要关注几个应用来实现一个商业的需求，有部分高层的设计，但大多数还是具体的设计，沟通需要跨越多个开发团队。

Enterprise Level (企业级别)：架构的最高级，关注多个解决方案，这一层的设计比较抽象，需要解决方案架构师和应用架构师去细化。沟通跨越整个企业组织。

有时候，架构师被看作不同利益相关者之间的粘合剂，比如：

水平方向：在业务人员和开发人员建立沟通的桥梁

垂直方向：在开发人员和经理之间建立沟通桥梁

技术领域：集成不同的技术和应用。

03 软件架构师的日常活动

为了理解软件架构师需要哪些技能，我们得先来看看架构师的日常活动

确定开发的平台和技术

确定开发标准和规范：编码标准，工具，评审流程，测试方法等

根据需求，设计系统并且做出架构设计决定

把架构设计和决定文档化，和团队沟通

把高层的设计变成底层设计

检查、评审架构设计和代码，比如看看确定的模式和代码标准是否正确施行

和其他架构师、利益相关者协作

指导开发人员

注: 架构设计是一个持续的活动，所以这些活动会一遍一遍地完成。

软件架构师所需的重要技能

根据我的经验，阅读的书籍，以及参与的讨论，我可以列出这10个技能，每个架构师都必须具备：

设计, 决策，简化, 编码, 文档, 沟通, 估算, 平衡, 咨询, 营销

我们一个个来说，对每个技能我都会列出一些我的见解，你应该采取的行动，以便在这个技能领域持续提高。

04 设计

是什么造就了好的设计？这可能是最重要，并且最具挑战性的问题，让我们先从理论开始。

理解基本的设计模式：为了开发一个可维护的系统，模式绝对是架构师最重要的工具之一，使用模式，你可以复用设计来决定那些通用的问题。“四人帮”的《设计模式：可复用的面向对象软件基础》是每个开发人员的必读书籍。尽管过去20多年了，模式依然是软件架构的基本单元。

比如书中描述的MVC模式被应用在很多领域，也是很多新模式如MVVM的基础。

**深入挖掘模式和反模式：**理解了基本的“四人帮”模式以后，你需要把你知识扩展到更多的软件设计模式中，或者根据自己的兴趣，深入研究，例如Java并发模式。

在应用程序的集成领域，我最喜欢的是《企业集成模式》，这本书适用于各种领域，只要两个应用需要交换数据，不管是很古老的基于文件的交换还是现代的微服务架构，都可以参考本书。

了解软件质量的度量方式：我们希望我们的系统是可以维护的、可靠的、安全的、可以测试的、可以扩展的、可用的...... 为了达成这些目标，必须要把系统架构设计好。你可以参考这个：

理论很重要，实践更加重要，否则你就会变成一个象牙塔架构师。

不断尝试和理解不同的技术栈：我认为这是成为架构师非常重要的事情，你很难从抽象的PPT中学到真东西，你得尝试不同的、新的技术栈，亲自感受一下它带来的好处和引发的“疼痛”。另外也可以尝试不属于你所在领域的技术，例如你对SAP R/3 非常擅长，那你应该也试试JavaScript。

分析、理解那些应用良好的模式：看看你当前使用的框架，例如Angular，你可以研究很多以及付诸实践的模式，如观察者。看看它是怎么在框架中使用的，为什么要这么使用。如果你愿意投入更多的精力，那就深入源代码看看它是如何实现的。

保持好奇心，参加一些公司之外的社团活动：比如Java User Group会讨论很多主题，从最底层的编码到高层的架构，我很喜欢这样的活动，因为它会让我跳出工作来思考，并且加强个人社交网络。

05 决策

架构师需要能够做出架构决定，引导项目和组织走在正确的方向。

确定优先级：有些决策非常关键，如果没有在早期确定下来，就会出现一些变通的临时措施，导致后续难以移除，变成维护的噩梦。更差的情况是，程序员需要停止工作，等你做出决策。

为了避免这种情况，必须要把这些决策按优先级排序，我建议看一看敏捷软件开发中非常流行的Weighted Shortest Job First (WSJF) 模型。

了解你的能力：不要在你的能力之外做决定，这非常关键，如果你不遵循的话可能会毁掉你架构师的岗位。

所以一定要和你的同伴明确你承担的职责和你的角色。作为低级别的架构师，你可以提出对高层架构的建议，但是不要擅自做主。我建议要经常和同伴审视那些关键的架构决定。

评估多个选项：涉及到决策时，要列出多个选项。在我参与的大多数决策中，都有不止一个可能（好的）选择。仅仅提供一个选项说明你没有完成自己的工作，没法完成决策。各种选项要通过可以度量的事实（如许可证费用，成熟度）而不是个人感情来比较，这样才能真正完成决策。

06 简洁

要谨记解决问题的奥卡姆剃刀原则：如无必要，勿增实体。

对于一个问题，如果你有太多的假设，很可能会走向一个错误的方向，导致不必要的、复杂的解决方案。一定要精简假设来生成好的解决方案。（可见架构工作也是一门艺术）

“摇动”你的架构设计：为了让架构设计更加简单，可以从多个角度去审视解决方案，不但要以自顶向下的方式思考，还要自底向上的方式再来一遍，如果你有数据流或者业务流程，先从左向右看，然后再从右往左看。

经常问自己：“在一个理想的环境中，架构设计会是怎么样呢？” “如果是那些大公司，它们会怎么做呢？” 这些问题会促使你减少假设。

退后一步：经常长时间的密集讨论，通常会得到一个高度复杂的设计，你绝对不能把它们当作最终结果，退后一步，从抽象的级别看看全局的图景，这设计还是有意义的吗？

有时候停止讨论，第二天再继续会有帮助，至少我的大脑需要时间来处理这些信息，然后提出更好的，更优雅的，更简单的方案。

分而治之：将大问题分成小块儿，逐个解决，然后看看小块儿解决方案能不能匹配起来。

重构并不邪恶：如果找不到更好的设计，从一个复杂的解决方案开始也是可以的。如果后面遇到了问题，你需要回过头来再想一想，重构并不是邪恶的，但是再开始重构之前要确保：

(1）足够的自动化的测试用例，保证系统的功能不被破坏

(2) 获取利益相关者的认可。

07 代码

即使是贵为企业级架构师，也就是抽象级别最高的架构师，你也得知道程序员日常工作在做些什么。否则你会遇到两个问题：

(1) 开发人员不会接受你的想法、说辞

(2) 你不会理解开发人员面临的真正挑战和真正的需要。

做一个副业项目：目的是尝试新的技术和工具，以了解当前和将来的开发方式。阅读一些教程确实不错，但仅仅是“书本”知识。只有自己亲自尝试一遍，体验一遍，你才能获得真正的经验：它为什么好？为什么差？你和一门技术呆的时间越长，你的体验就会越多，就越能帮助你做出好的决策。

找到正确的技术来尝试：你不可能尝试所有的东西，我最近发现了ThoughtWorks的技术雷达，它们把技术，工具，平台，语言和框架分为四类：采用，尝试、评估和保留。

采用的意思是“适合企业采用”。

实验指的是“企业可以在一个风险可控的项目中尝试”

评估的意思是“研究下如果对企业产生影响”

暂缓意思是“谨慎推行”

通过这种分类，你就可以找到你想尝试的新技术了。

08 文档

Clean Code：简洁优雅的代码是最好的文档，架构师一定得能区分开什么是好代码，什么是坏代码。有一本很好的书来介绍好代码和坏代码：

在可能的时候尽量自动生成文档： 对于一些较为详细的文档，由于系统变化迅速，很难及时更新，所以尽可能自动生成文档：如果你是Model Driven的话可以从定义文件中自动生成文档，SWagger 和RAML都是很好的起点。

该多就多，该少就少： 无论是什么文档，在同一时刻只应该把注意力放在一件事情上，只包含这件事情的必要信息，额外的信息应该保留在附录中，因为大量的文字是很难阅读和理解的。仔细看看你的文档，问问自己：“为了理解整个东西，是不是所有的信息都在其中了？” ,“哪些信息是必须的，哪些是可以忽略的？”

09 沟通

根据我的观察，这是最被低估技能，如果你在设计方面特别出色，但是却无法和别人沟通，你的想法就没啥影响力，很可能失败。

演讲：向一个小组或大组做演讲是一个架构师常见的工作，如果你刚开始觉得不舒服，可以从你的最好的朋友开始，慢慢扩大的更多的人，这件事只能通过不断地实践来学习，是个需要花费时间的过程，还需要离开舒适区，所以要保持耐心。

找到正确的沟通级别：不同的人看待事物的角度是不同的，所以你需要在他们的级别和他们交流。比如开发人员对技术细节感兴趣，经理更倾向于知道哪个选项更加省钱。

所以在沟通之前，你要看看你想交流的东西是不是在合适的级别，包括抽象度，内容，目标，动机等

经常沟通： 如果无人知晓，一个出色的架构毫无意义，要经常沟通你的架构设计以及背后的想法，定期在每个组织级别（小组，部门，公司）进行沟通，安排和开发人员，架构师，管理人员的会议，展示你的架构思路。

保持透明：定期沟通只能部分缓解缺少的透明度，你还得确保决策背后的原因透明化，特别是对那些不参加决策的过程的人，他们很难理解为什么要这么做，有什么理由。

随时准备好做一个演讲：总会有人问架构师问题，你也想快速地给出正确答案，这该怎么办呢？你可以把最重要的PPT挑出来，放在一起，随时展示并且给他们做展示，避免在一堆资料中找来找去，那样会浪费太多时间。

10 估算和评估

理解基本的项目管理原则： 作为架构师或者首席开发，你经常会被要求对你的设计进行估算：多长时间能完成？需要多少人？需要什么技能？

刚开始，你可以提供粗略的估算：几天，几个月。请记住估算的时间可不仅仅是编码实现，要有需求分析，测试，改正Bug。因此你需要知道软件开发过程中的各个步骤。获得更好估算的一个方法是基于历史数据给出预测。如果你没有历史数据，可以试试COCOMO方法，如果你在做一个敏捷项目，这本书非常有帮助：

评估架构：作为一个架构师，你应该能够架构设计在当前和未来上下文中的适应性，这件事不容易，你可以准备一组问题来对架构设计进行“质询”，例如：

(1) 设计实践: 架构遵循了哪些模式？是否正确地被使用了?是否有清晰的设计和关注点分离?

(2) 开发实践: 制定代码规范了吗？被遵循了吗？代码有版本控制吗

(3) 质量保证: 自动化测试的覆盖率如何? 有静态代码分析到位了吗? Peer review做到位了吗?

(4) 安全: 架构设计中有哪些安全概念? 内置安全性如何? 渗透测试和自动化安全分析是否做到位？是否定期使用？

11 平衡

质量是有代价的：前面聊过系统质量和非功能性需求，如果你在架构设计上做得过度，就会增加开销，降低开发的速度。你需要平衡架构设计和功能需求，过度设计应该被避免。

解决相互矛盾的目标：一个经典的例子就是短期目标 vs 长期目标。项目通常倾向于构建最简单的方案，而架构师脑海中有长期的愿景。通常，简单的方案不适合长期的目标，并且有可能被丢弃（沉没成本）。为了避免走向错误的方向，应该注意两件事情：

(1) 开发人员和业务人员都需要理解长期的愿景及其收益。

(2) 负责预算的经理也需要参与其中，了解财务影响。

冲突管理：由于团队有着不同背景，冲突难免发生，为了找到一个相互能接受的、平衡的解决方案，架构师需要充当粘合剂，来解决这些冲突。关于沟通的理论，我是从Schulze von Thun的Four-Ears Model开始的：

12 咨询和指导

拥有愿景： 不管你是在一个什么样的项目中，不管是传统的瀑布模型还是敏捷模型，你必须需要有一个愿景，也就是你想获得的短期和长期目标，并且清晰地传递给团队成员。

由于不可能一下子达成所有的目标，我通常倾向于建立成熟度模型，让团队清楚地得知我们当前处于哪一级别。开发有很多方面，得使用不同的成熟度模型，例如开发实践成熟度模型，持续交付成熟度模型。这些模型的每个级别都有清晰的定义，团队可以轻松地度量自己在什么级别。

对于持续交付，我个人倾向于这个模型

建立社区：例如，把JavaScript程序员和架构师组织起来，每个月讨论一次，主题可以是如何解决过去和现在的技术挑战，新的技术和方法。架构师可以分享、讨论他们的愿景，程序员可以分享他们的经验，这样的会议能帮助建立一个更强大的团伙，对企业和个人都极具价值。

进行开诚布公的讨论：误解和模棱两可的根源是缺乏沟通，所以你可以安排一个固定的时间段，如每周30分钟，和同伴交换一些热门的话题，什么都可以讨论，不用刻意安排讨论的议程。可以当场解决一些小事，对于复杂的主题，安排后续的跟进。

13 营销

你的想法很棒，并且和大家做了很好的沟通，但是没人愿意去做，那可能是缺乏了营销的技巧。

激励并说服：公司是怎么说服你购买他们产品的？他们肯定展示了价值和好处，但不仅如此，他们还做了漂亮的包装，使其尽可能地容易消化

(1)原型：带界面的原型非常直观，会很吸引人。有很多创建软件原型的工具，如果你喜欢SAP的话可以事实build.me ，使用它可以轻松快速地创建漂亮的UI5应用。

(2) 视频: 除了无聊的PPT之外，用一个视频可以更好地展示你的想法。但是请不要过度营销，从长期看，内容为王，如果你满嘴跑火车，损伤的是你的声誉。

捍卫你的想法并且坚持不懈：如果你真的对自己的想法深信不疑，你应该捍卫它，为之战斗，这是非常必要的，因为具备长期目标的架构决策是不容易被人接受的：开发人员不喜欢它因为开发起来太难，经理不喜欢它因为短期来看代价太高。所以坚持不懈地去说服是你的本职工作。

找到同盟军：独自去建立并且执行你的想法几乎是不可能的，你需要盟友的支持来说服别人。这时候需要使用你的社交网络，如果你还没有的话，马上去建吧！

你可以先去和那些具备开放心态的同事去谈你的想法，如果他们喜欢（或者部分喜欢），当别人问起的时候，他们很有可能会支持你：X的想法很有趣。如果他们不喜欢你的想法，问问为什么，你是不是漏掉了什么东西？你的故事不够吸引人？

下一步就是找到具备决策权力的盟友，请求他进行一个开放的讨论，如果你害怕这种讨论，你需要反思一下，是不是应该离开舒适区了。

重复它，相信它： 研究显示重复的展示一个观点会使人们相信这是一个普遍的观点，即使该观点仅仅来自一个人。如果你经常发过某个消息，更容易说服别人。但是要当心：应该明智地使用这种策略，因为它可能适得其反。

芋道源码 —— 纯源码解析博客

我怎么才能成为一个架构师？