架构师的能力模型

架构师的能力模型思维导图，整理了点线面体专业技术能力、专业业务能力、不可或缺的技术管理能力、思维模式的内容，感兴趣的朋友不要错过。

架构师的能力模型

• 点线面体专业技术能力
  • 技术广度、深度和高度
    • 点：能准确理解、分析需求并独立完成一个功能模块的开发
    • 线：能根据系统设计并负责一个项目中多个功能模块的开发，甚至独立负责一个子系统的开发
    • 工程师范畴
    • 面：在其所在的领域内可以负责一个产品的整个研发过程，并对业务和技术发展都有洞察和前瞻性（这点很抽象，什么是洞察力，什么是前瞻性？）
    • 体：能够带领团队负责多个产品线的研发过程，更高阶的话对行业有创新和影响
    • 架构师范畴
    • 广度：即技术事业，所涉及的领域包括：数据库知识、计算机系统、网络知识、应用技术框架、系统安全、涉及模式、精通2门以上开发语言，常用架构方法论，业务领域内的技术应用和发展、文档编写能力，对这些领域要有全面了解，能够评估各种技术的优缺点，能根据业务需要和技术优缺点来做技术选型
      • 60%80%的达标情况
    • 深度：即技术内功，要针对所在领域的核心技术有一定的底层掌握，比如熟读源码和深度测试验证等，就像武林高手一样，有深厚的内功后才能快速融会贯通天下各派武功
      • 我就缺少深度
  • 工程师和架构师的区别
    • 一般工程师具备需求理解、分析和程序设计及开发能力
    • 架构师需要架构设计和架构决策和规划的能力，要能够识别出系统架构中的复杂点、痛点，提供有效的架构解决方案，同时架构师要与人研讨方案的优略，方案的选型，挖掘方案的优缺点，最终选择最合适的方案。
  • 扎实的工程能力
    • 架构师一定是带领或指挥1个团队来共同完成项目目标的，提升研发效率也是架构师的职责之一，那么研发工程流程优化、技术规范、开发工具和架构脚手架等需要架构师制定和落地. 比如开发工具 , 代码审查工具, 项目管理工具的选择、开发流程、技术规范的文档编写制定及最重要的系统架构脚手架的研发落地及维护等等.
  • 架构设计能力
    • 这点是架构师核心职责之一，即是从业务出发，分析准确把握业务对高性能、高并发、高可用、可扩展、安全等系统容量指标的要求，根据这些要求设计对应的系统架构实现，比如满足高并发高性能的系统架构设计有高性能计算和存储架构实现，例如多级缓存、消息队列削峰填谷或解耦异步处理、数据库分库分表，读写分离等设计实现。就是各种架构设计的套路组合搭配。
• 专业业务能力
  • 懂业务
    • 系统架构的核心是为了业务服务的, 是要适应业务更快速的发展, 所以架构要合适且能演进,要做到这点就要充分懂业务，理解把握业务的商业模式、发展前景、趋势等， 根据这些做技术方向布局.
      • 什么是业务？业务的发展趋势是说行业中业务都是怎么做的？
      • 什么新的商业模式或者业务模式出现了？
      • 发展前景
      • 趋势
    • 同时对业务提出的需求, 要多问多思考需求背后的本质是什么, 来帮助我们识别并解决业务真正的痛点. 对业务的理解不会设计出天马行空不切实际的架构, 所以脱离业务的架构设计都是耍流氓。
  • 善于抽象业务
    • 系统架构要设计得好，必须理解业务的基础上有业务抽象建模的能力，也就是最近比较流行的领域驱动设计，只有对业务抽象足够清晰、准确才能设计分解系统的模块、组件以及他们之前如何协作运行。
  • 业务洞察力
    • 业务洞察就是业务进行深入分析、理解，要抓住需求本质，不仅仅是对需求浅层的理解，要不断学习研究业务知识，最好能达到业务专家水平，越靠近越好，这样能提升思维抽象穿透的能力，从而具备有业务和技术发展的前瞻思考，做好一些技术布局等。
      • 洞察力：我理解就是透过现象看本质 也就是说，从用户的需求发现用户真正的痛点
• 不可或缺的技术管理能力
  • 技术决策力
    • 技术方案拍板是架构师最重要的职责，任何需求都有不通的技术实现方案，那么架构师就要从成本收益、持续发展和优先级等方面的权衡取舍进行架构评审及正确决策的能力尤为重要。
  • 团队管理能力
    • 架构师不是一个人战斗，需要带领团队在目标时间内完成项目打胜仗，需要系统分解形成整体架构设计，能够正确地技术选型和制定技术规格说明并有效推动架构设计方案的实施落地。那么管理工作的核心就是管人管事. 管人就要根据团队成员能力特点分工安排. 管事就要管理项目和技术架构方案的落地, 包括项目计划的拆解, 执行进度的追踪, 技术难点的攻克等等.
• 思维模式
  • 分层思维
    • 分层是系统设计的经典范式，也是康威定律的具体实现。典型的互联网系统从上到下分别为表现层，业务层，服务层，持久层和数据层，每一层再根据具体功能做模块拆分。分层架构有几点需要重点关注：
    • 1，偏底层部分要设计的职责相对单一，功能相对简单，偏上层的部分去贴近业务需求，同时为业务发展预留不断迭代变化的空间。层级与层级之间要有良好的隔离和抽象，上层业务的多样性不要透传到底层，日常开发不需要底层系统有太多变化，让底层更多的关注性能和稳定性等非功能性需求。
    • 2，保证上层调用下层和同层之间单向调用，避免上下层反向调用和同层的双向调用，出现了这种不清晰的层级关系时，要考虑服务职责的重新分配。
    • 低层次只提供服务，不会反向调用上层，低层次之间尽量不要做同层相互调用，同层相互调用那是上层的事情
  • 边界思维
    • 一个系统对外的接口体现了自身对外提供的能力和职责边界，接口需要设计的简洁优雅，内部的具体实现不影响其他系统，可以把风险和不确定性封闭在单一服务中。
    • 1，遵守单一责任原则，一个方法只负责一个基本功能的实现，一个类的所有方法处在同一个抽象层次，一个模块的所有类在同一个抽象层次。
    • 2，设计接口的时候先不要考虑怎么实现，优先考虑按照什么策略进行接口拆分，每一个接口的参数，返回值什么，哪些参数是可选的，哪些参数的必选的，站在使用者的角度去设计和思考，然后再去想如何进行实现。
  • 系统化思维
    • 马克思告诉我们，普遍联系和永恒发展是客观世界存在的两个总的基本特征 系统设计的工作也是如此，要站在系统的角度考虑问题，比如这个需求需要有哪些团队来协作完成，每个部分承担什么样的职责，互相之间的数据流动是什么样子，下层系统的稳定性怎么样，上层系统需要设定什么样的重试策略和超时时间，被调用方有没有幂等设计，调用方需要做什么样的防重入设计，各个系统之间通过什么样的机制保证数据的一致性等等
      • 就是站在更高的抽象层次去看问题，看外面，不要只停留在内部
  • 公式思维
    • CTR=实际点击次数 / 展示量，广告展示量一定的情况下，为了提升点击通过率，可以思考采用创意优化和用户重定向等手段去提升实际点击次数。 ROI = △GMV / △COST，为了提升投入产出比，可以从提升增益，降低成本两个方面考虑。PM常说的 用户价值=新体验-旧体验-替换成本，公式思维也是产品经理的常用思维范式。解决问题没有思路的时候，把核心目标的计算方法写出来，根据数学公式来寻找解决问题的方向。
      • 比如说：核心目标是可用性指标，那么列出可用性指标的公式，分解每一部分因子，看看从哪一个因子可以更好的达成最终的目标。
  • 精益思维
    • 精益生产使日本的汽车制造业突飞猛进，其核心支撑使just in time和build in quality，对应到软件工程领域，具体体现在两个方面：
    • JIT：做恰如其分的架构设计，架构的本质是通过一系列的技术决策来降低系统复杂度，拒绝糙快猛，也不做过度设计，不能在因为需求时间紧张，就随意设计接口，粗略拆分模块，也不能上来就分布式和微服务。要随着业务的发展需要，做渐进式的演进，做最适合当下最可落地的决策。
    • biq：工作过程中需要不断思考通过自动化的手段去提升效率，DAO层很多情况下是相对简单的CRUD，可以用代码生成器去自动生成这部分代码。回归测试成本太高，可以通过持续集成介入自动化测试的方式去提升人效等等，从大量简单重复的工作中找到提升效率的方法，再用总结的方法去指导实践，再在新的实践中寻找出新的提升效率的手段，如此循环往复是归纳和演绎循环往复的过程，也是螺旋式上升的过程。
• Other
  • 架构的本质：满足公司多业务场景的需求，最终达到公司层面要降本增效这样一个终极目的
  • CAP架构设计思维模型，CAP本身是一个定律，你能不能根据一些需求一层一层的抽象，一层一层的分析，最后把你的架构设计映射到一批定律。如果你能一步一步通过需求做抽象分析，然后对架构进行拆解，最后映射到CAP定律，那么你就具备了CAP的架构设计思维模型。
    • CAP是三个英文单词的首字母，分别是consistency、availability、partition tolerance。即强一致性、可用性、网络分区容忍性
  • BASE架构设计思维模型：ASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。在很多情况下，我们是没办法用CAP定律来进行映射的，但是可以通过映射到BASE的思维模型来去做
  • Balance架构设计思维模型，在大厂你可以用这样的分布式架构，但是去了一个小厂以后，不一定要用分布式架构，可能用一个单体架构是一个比较好的方向。这是一个非常重要的思维模型。什么叫合适，还是比较抽象
  • 适度超前架构设计思维模型：给出的架构能满足一定时间内业务的发展，比如说，满足半年到一年的发展需求，这样一个架构设计思维模型就是适度超前的。
  • 具备以不变应万变的架构设计能力：这个不变就是架构设计的思维模型，这个万变就是各种场景。有了这种能力，你就一定可以给出优雅的架构设计方案
  • 架构设计哲学本质：降本增效