我研发领域也从事了一些年，期间也做过一些架构设计工作，包括C#单体转型为Java微服务、Python单体转型为Java微服务等，
也尝试着从自己的经验角度，来汇总一些知识点，同时描述一下如何成长为一个合格的软件架构师，仅供参考，也欢迎跟我一起探讨。

一、架构师的定义

顾名思义，架构师就是指在某个公司/团队里，从事系统架构工作的人。
首先要明确的一点，本文讲的架构师并不是一个职位，而是指一个角色，就是从事架构工作的人。

每个公司、甚至一个公司的不同团队，对架构师的认知都不一样，对架构师的定义及承担的职责也各不相同；
每个团队，都有人或多或少的在做架构的工作，比如团队主程、资深开发人员；

所以不是说你的职位是架构师，你就达到了架构师的标准；同理，你的职位不是架构师，但是你可能就是这个团队公认的架构师。
作为架构师要注意的点：
架构师不能脱离现有的开发环境、项目的现状、公司的资源投入等，不能坐在空中楼阁里，指挥团队作战。

架构师分类

根据不同领域的细分，架构师也有一些细分的定义，一般会有：

软件架构师：负责设计和规划软件系统的整体架构，涵盖需求分析、技术选型、领域划分、应用部署等；
数据架构师：负责数据系统的设计和规划，含数据仓库、数据收集和治理等；
网络架构师：负责系统整体网络的设计和规划，含互联网接入、路由交换、VPN和网络安全等；
云架构师：在云计算盛行的当前，负责云计算的部署和规划，含云平台选型、容器管理能力、虚拟化、自动化等；
安全架构师：负责软件系统的安全架构规划，包括全局的安全策略、访问控制、漏洞管理、审计策略等；
前端架构师：一般特指浏览器应用架构师，负责前端应用的整体架构设计，包括前端框架、技术栈、跨浏览器兼容和统一能力封装、性能优化等；
移动应用架构师：一般指Android/iOS应用架构师，负责移动应用的整体架构设计，包括移动安全、技术栈、跨平台兼容、测试方案设计、性能优化等；
后端架构师：主要负责应用的后端架构设计，包括数据库设计、API设计、性能优化、数据安全等。

以上细分并不一定全面，而且很多领域的边界其实是不够清晰的，比如：

软件架构师一般涵盖整个软件系统，对各个领域都应该有一定的了解，并有一定的侧重（后端居多）
前端架构师和后端架构师，都应当对API进行规范化和输出评审；
比如软件架构师和数据架构师，都要关注数据的安全、跨系统的消息传输协议等。

软件架构师的职责

1、全面了解业务需求
作为架构师，最重要的是精通业务，甚至要求成为领域专家，在系列第一讲就说了：发现问题比解决问题更重要
如果不了解业务，设计出来的架构是不可信赖的。
2、能简化和抽象问题
这是架构师设计和开发高质量软件系统的关键能力，可以帮助团队在复杂的环境中更好地理解业务需求和进行设计、开发。
以用户登录系统为例：
- 可以简化登录问题为：接收用户提交的登录类型、接收用户提交的凭证、校验用户凭证是否有效，
- 抽象为一个接口，提供3个方法：
  matchLoginType(HttpServletRequest request) 是否当前类处理的登录类型
  readCredential(HttpServletRequest request) 根据登录类型，读取登录凭证
  validCredential(UserCredential info) 验证登录凭证
- 添加不同的实现，比如账号密码登录实现、微信登录实现、LDAP登录实现、Token登录实现等等
- 至于前端展现、用户交互方式，这些都是相对不重要的细节，约定好标准的前后端接口交互规则就可以了
3、在有限资源内提出合适可行的解决方案
我们的软件/硬件/人力/时间等资源都是有限的，架构师要权限这些限制，在有限资源下寻求最优解决方案。
比如：工期有限时，架构师要能评估业务实际情况，拆解模块/功能，选择符合需要的最低功能组合进行优先设计实现；
比如：新旧系统重构时，架构师要根据团队人员、擅长技能情况进行技术选型，要衡量如何对业务最小影响的情况下，平滑过渡和人员分配的能力。
4、满足业务需求，保证系统质量
要求架构师能正确理解业务需求，并输出系统所需的非功能性需求，包括可靠性、性能、容错性等；
然后设计合适的技术方案，并持续跟踪过程，以保证质量。
5、在可预测的时间段内的可扩展性
这个一般分2方面：
- 架构师要深度理解需求，能预估一定时间内的需求变化情况
  比如用户登录系统，不应只设计账号密码登录，应根据用户群体特征，增加微信扫码登录、Google身份登录等；
- 架构师要考虑系统的伸缩性，包括水平扩展和垂直扩展，同时要兼顾成本，避免过度设计：
  - 水平扩展：系统在访问量增长的情况下，能快速扩容节点，分散旧节点的负载能力应对；
  - 垂直扩展：系统的单节点有足够的扩展能力，如CPU增强、内存增加、网络带宽增长等。
6、在系统的生命周期内持续演进
架构师根据业务的增长情况，对系统进行持续的监控、评估和迭代改进。
最终目标就是在不影响业务增长的情况下，持续提升系统的可靠性和吞吐量。

软件架构师的能力要求

作为一名合适的软件架构师，一般应该拥有的能力：

1、技术能力
架构师首先一定是一名出色的技术人员，可以说没体验过分库分表的架构师确实不太合格，他应该是：
- 高级程序员：
  架构师一定要有丰富的程序开发经验，什么设计模式、HashMap原理、B+树等等，都不在话下；
  一些核心系统或通用框架设计，通常也需要架构师进行代码编写和指导；
- 多技术领域知识：
  架构师应该拥有足够的技术广度，了解不同的技术领域知识，如了解前端浏览器渲染过程、客户端开发技术栈、kafka收发原理、分布式相关理论和一些产品实现、容器和K8S、负载均衡技术等等，才能在面对具体问题的时候，提出合适的技术选型、部署方案和实现；
- 问题解决专家和救火员：
  架构师一定要有丰富的问题解决经验，能解决很多一般技术人员无法解决的疑难杂症；
  有完善的问题解决流程经验，如生产事故优先安排恢复，再进行故障定位解决的一整套处理方案；
- 合适的运维工程师：
  一些紧急或特殊的问题，需要架构师进行线上诊断；在线下重现时，需要部署相应服务；
  架构师也应当有一些常见服务的部署/运维/监控经验，如Centos、Windows、supervisor、crontab、redis、mysql、kafka等等；
  另外，在一些中小型团队，一般没有专职的运维人员，也是由架构师负责运维；
2、业务分析和抽象能力
架构师应该深入了解行业知识，要让自己成为领域专家，才能更准确、清晰的把用户需求转化为技术需求，
同时架构师应该要有抽象能力，即把技术需求转化为抽象的具体良好可扩展性的架构；
比如一个商城系统，能抽象为：
登录 -> 购物车 -> 下单 -> 支付 -> 发货
同时可以抽象出通用的认证服务、订单服务、支付服务、库存管理服务，以及各服务间的消息传输协议等；
同时，看到商品，就知道要设计分类表、SPU数据表和SKU数据表，商品的评价要剥离成独立的评论服务等。
注：六大设计原则，其实也适用于软件架构设计，在划分领域边界、模块拆分时也要考虑单一职责、开闭原则、接口隔离等等。
3、管理能力
这个点比较大，通常来说，架构师也应该具备团队管理能力，包括较强的沟通和理解能力、项目进度管理和资源调配能力、团队协作与氛围激励能力；
最重要的是沟通和理解能力，如果不能理解别人提出的问题，无法清晰的表达自己的想法，连问题都无法清晰发现和定义，更不要谈后续的动作了。
还有一点我认为是坦诚，团队成员天天交流，不够坦诚，成员很容易感知，就会反感和不坦诚，很多问题就无法暴露，最终可能导致项目失败。
4、学习能力
架构师要有比较好的学习能力和适应能力，以及较强的前瞻性，应当经常参加各种线上线下的培训或交流，以了解和跟上不断变化的技术和行业发展趋势。
同时，架构师也要有较好的总结归纳能力和沉淀能力，包括技术经验的总结、技术规范的整理与输出、运维runbook的编写、培训文档输出等。

这些能力，基本都需要通过持续的学习和锻炼，比如抽象能力，就是要长期做需求分析、划分领域边界，并对比同类项目的设计，找出自己设计的不足点，进行学习和重构。
一定要记住，技术不是全部，很多场景，都可以通过需求优化来解决，而不是通过复杂的技术方案处理，后面我会有一些文章来举例。

这里分享一张极客时间的“架构师技能图谱”，可以参考：
在这里插入图片描述

再分享2张来自https://roadmap.sh/的：前端能力路线图和后端能力路线图
在这里插入图片描述 —

二、如何成长

分享一张图：
在这里插入图片描述
上图，来自吴军老师的《格局》，可以认真一读：

基线：你掌握的工程知识，因人不同，比如专家的基线高、新手的基线低；
我们要做的第一件事，就是自我定位，找到自己的基线，并持续学习，以提高自己的基线。
很多民间科学家用一辈子做出的发明不被认可，就是因为他的基线低于这个时代的基线，没有去学习，直接利用自己的旧有知识。
极限：受制于物理、环境、甚至个人认知，可达到的极限，如光速、单机的最大连接数、单机的最大吞吐量等；
我们在学习和改进时，要明确这个方向的极限，避免无效的折腾
阶梯：通往极限的路径、方法，需要你通过学习获取晓或自行探索适合你的方法。
注：受限于每个人的个人认知、配备的资源不等、以及探索方法是否行之有效，能达到极限的人是越来越少，所以阶梯是呈收敛的。

所以，总结一下，怎么让自己持续成长，没有捷径：

不断学习，提升自己的基线
很多时候，你以为的顿悟，只是别人的基本功。 by:刘润
实践，持续不断的实践，归纳，总结，领悟
不要认为没时间，在推荐书籍里的5分钟商学院，有专门一节教你做时间管理，只要听5分钟。

理论与实践相结合，我们知道，有2种知识：
1、别人告诉你或书上学到的，这是理论；
2、自己亲身经历的，这是实践；
只有理论，很容易遗忘；只有实践；你不知道要提升什么。

我的经验：
1、自己踩过的坑，要进行复盘，了解为什么出问题，本质原因是什么
2、别人踩过的坑，我会去尝试在测试环境踩一遍，加深印象，并探究本质

最后分享一个在知乎看到的学习问题，挺有意思的：
知乎有人问过一个问题：古人有上策中策下策，为啥很多都选下策？
有个高赞回答是这么说的，以学习为例，上中下三策：

上策：严密的学习计划，悬梁刺股、闻鸡起舞；
很显然，太难了，没几个人能做到；
中策：宽松的学习计划，一周/月看一本书；
这个中策还不错，很多人会选择，甚至做时间计划，就是执行过程很容易中断，什么手机很想我，抖音看一看，跟朋友喝个酒，持续不了1，2个月就结束了
下策：随机学习，想到就去学
绝大多数人选择了这个，包括我在内，知识碎片化很严重，而且很容易遗忘

三、推荐书籍

技术领域

这三本书，阅读起来确实会比较枯燥，可以看一遍有个印象，再实践一段时间，回来再阅读一遍
在这里插入图片描述

非技术领域

同时，我们也不要只关注技术领域，要关注一些技术领域之外的知识；
尤其强烈推荐刘润的5分钟商学院，这是一个音频系列，每个音频5分钟左右，涵盖了商业知识、产品创新、自我管理、团队管理、绩效提升等全方面的知识，
在知乎上有些人对他评价不高，但是对于技术领域的我来说，很多知识几乎是醍醐灌顶的作用，自然也对我的成长、工作都提供了很大的帮助，强烈推荐学习。
在这里插入图片描述

四、扩展资料

这里介绍2个关于架构师的认证考试，有志于提升自己的架构能力的同学，可以去尝试一下，
认证涉及的内容，是比较全面的，能在整体上提升个人能力，所以千万不要抱着应付考试的目的去学习，甚至只学习，不考试也是相当OK的。

TOGAF认证

TOGAF是The Open Group Architecture Framework的缩写，它由The Open Group开发，并在持续更新中，The Open Group是一个非盈利的技术行业联盟。
The Open Group 将 TOGAF 定义为“企业架构的全球标准”，它提供了一整套方法论和最佳管理实践。
TOGAF已被80%的福布斯50强公司使用，并得到HP、IBM、Kingdee（金蝶）、Oracle、SAP等国际领先IT企业的高度认同和积极推动。在中国企业架构实践中，TOGAF认可度超过50%。
TOGAF官方介绍：https://www.opengroup.org/togaf
百度百科介绍：https://baike.baidu.com/item/TOGAF/9832356

TOGAF认证的能力模型简要概述如下：

1、通用技能：领导力、团队合作、人际交往、口才、写作、逻辑分析、干系人管理、风险管理；
2、业务技能和方法：业务案例、业务情景、组织结构、业务流程、战略规划、预算管理、战略愿景、业务指标、业务文化、遗留的投资、业务功能；
3、企业架构技能：业务流程设计、角色设计、组织结构设计、数据设计、应用设计、系统集成、IT行业标准、服务设计、架构原则设计、视图和视角设计、构建块设计、解决方案建模、效益分析、业务交互、系统行为、项目管理；
4、方案和项目管理技能：方案管理、项目管理、管理业务变更、变更管理、价值管理；
5、通用IT知识技能：IT应用开发方法和工具、编程语言、代理应用、信息消费应用、信息提供应用、存储管理、网络、基于Web的服务、信息技术基础设施、资产管理、服务等级协议、系统、商用现成品、企业连续体、迁移规划、管理工具、基础设施；
6、IT技能：软件工程、安全、系统和网络管理、事务处理、位置和目录、用户界面、国际化操作、数据交换、数据管理、图形与图像、操作系统服务、网络服务、通信基础设施；
7、法律环境：合同法、数据保护法、采购法、诈骗、商业法

软考之系统架构设计师

系统架构设计师，是计算机技术与软件专业技术资格的一项高级认证，参考官方介绍：https://www.ruankao.org.cn/platform/details?code=03_03

它的考试要求：
（1）掌握计算机硬软件与网络的基础知识；
（2）熟悉信息系统开发过程；
（3）理解信息系统开发标准、常用信息技术标准；
（4）熟悉主流的中间件和应用服务器平台；
（5）掌握软件系统建模、系统架构设计基本技术；
（6）熟练掌握信息安全技术、安全策略、安全管理知识；
（7）了解信息化、信息技术有关法律、法规的基础知识；
（8）了解用户的行业特点，并根据行业特点架构合适的系统设计；
（9）掌握应用数学基础知识；
（10）熟练阅读和正确理解相关领域的英文文献

可见需要了解的内容还是比较多的。