架构师是怎样炼成的

这是我参与更文挑战的第25天，活动详情查看：更文挑战

软件架构师定义

• 软件工程师的职业发展方向:

• 软件架构师:
  • 制定高级设计决策,并肯定技术标准,包括编程标准,工具和平台的软件专家
• 软件架构:
  • 系统的基本组织构成,这种组织主要体如今其组件,组件之间关系,组件与环境之间的关系,以及决定系统设计与演化原则
  • 架构是系统的蓝图,描述了系统的结构和关键决策
  • 架构包含系统的功能和非功能性需求:
    • 系统如何实现的?
    • 系统与子系统是如何划分的?
    • 系统之间是如何通讯的?
    • 系统功能如何设计和交互的?
    • 包含重要的架构决策,系统组成,功能设计,技术选型,成本分析等等
  • 架构的基础是设计知足客户需求的系统,其中包含功能性,非功能性以及质量和约束

• 架构师必定要负责整个系统中最核心和最难的地方编写,而且设计好团队合做开发方式,能根据编程经验看到将来的变化
• 若是一个团队里须要一个架构师,必定是一位代码能力最好的,可以负责核心业务的开发,而且不能脱离实际业务

项目中包含哪些角色:

• 客户: 为系统开发买单的人,关注系统的业务价值
• 用户: 使用系统的人,关注是否知足功能需求,提高效率和易用性等
• 项目经理: 负责项目管理,组织,协调,沟通等管理工做
• 需求分析师: 负责需求相关工做,好比业务分析,需求获取,需求调研,需求管理,编写需求规格说明书等
• 系统架构师: 负责总体的系统分析,架构规划,技术选型,核心功能需求和非功能性需求的架构设计
• 系统设计师: 在架构模型的基础上,进行核心功能和非核心功能的详细设计
• 开发人员: 根据架构设计和详细设计完成编码和单元测试,达到提测标准
• 测试人员: 验证开发功能是否知足需求,好比进行功能测试,集成测试,性能测试,压力测试,安全性测试,回归测试等
• 运维人员: 负责部署环境搭建,部署和平常维护

架构师职责

• 架构师须要创建高效卓越的体系,在规定的时间内完成项目
• 架构师须要:
  • 识别定义并确认需求
  • 进行系统分解造成总体架构
  • 正确地技术选型
  • 制定技术规格说明并有效推进落地
• 架构师的角色:
  • 理解并解析需求
  • 建立有用的模型
  • 确认并细化扩展模型
  • 管理架构

软件架构层级

应用级

• 最低层级的架构
• 层级低,可是很详细
• 这种层级的交流通常是在一个开发团队内展开

解决方案级

• 架构的中间层
• 关注一个或多个知足业务需求的应用,即商业方案
• 这之中有些设计是高层次的,但大部分仍是低层次的设计
• 这种层级的交流开始涉及多个开发团队

企业级架构

• 架构的最高层级
• 关注多个设计方案
• 这种架构的设计层次高且抽象,所以也须要方案级和应用级的架构师对此进行细化
• 这种层级的架构须要多个组织进行沟通

• 架构师能够被看做是不一样工做组之间的粘合剂:
  • 横向: 在业务部和开发人员或者不一样的开发团队之间架起沟通的桥梁
  • 纵向: 在管理者和开发人员之间架起桥梁
  • 技术: 将不一样的技术或应用整合在一块儿

解决方案架构师

工做方式理解

• 了解和挖掘客户痛点,项目定义,现有环境管理
• 梳理明确高阶需求和非功能性需求
• 对客户问题已经存在什么解决方案
• 沟通,方案建议,屡次迭代,交付整体架构
• 架构决策

职责

• 从客户视图看:
  • 坚决客户高层信心: 利用架构和解决方案能力,帮助客户选择相关解决方案
  • 解决客户中层问题: 利用相关解决方案,帮助客户解决业务问题,得到业务价值
  • 引领客户IT员工: 技术引领,方法引领,产品引领
• 从项目视图看:
  • 对接管理部门: 汇报技术方案,进度,技术沟通
  • 对接PM,项目PM: 协助项目计划,人员管理等.负责全部技术交付物的指导
  • 对接业务部门和需求人员: 了解和挖掘痛点,帮忙梳理高级业务需求,指导需求工艺
  • 对接开发: 产品支持,技术指导,架构指导
  • 对接测试: 配合测试计划和工艺制定.配合性能测试或者非功能性测试
  • 对接运维: 产品支持,运维支持
  • 对接配置和环境: 产品支持
  • 其他资源整合

软件架构师职责

• 定义和肯定所需的开发技术和平台
• 定义开发标准,如编程标准,工具,审核流程,测试方法等
• 对肯定和理解业务需求提供技术支持
• 设计系统并根据需求做出决策
• 对架构定义,设计和决策进行讨论记录
• 检查并审核架构和代码,好比检查前期肯定的模式与编程标准是否被正确实施
• 与其余部门和架构师合做
• 对开发人员的引导和咨询
• 将高级设计细化,并转化为较低级的设计

---

• 按照系统设计实现过程:
  • 支持售前或需求阶段,提供概念架构或技术咨询
  • 系统分析,架构设计,技术选型,产出架构解决方案
  • 指导项目团队成员,按照架构设计完成,开发,测试和发布
  • 开发或设计开发框架,制定编码或者编程规范,设计架构原型,验证架构原型
  • 组织技术或架构培训,把我技术或者架构方向
  • 实现与成本的方案平衡,干系人沟通,技术风险管理,技术领袖
• 按照项目阶段:
  • 售前阶段: 给予商务支持,提供系统解决方案和架构咨询
  • 需求阶段: 与需求分析师一块儿,参与项目沟通,协助完成技术或者业务咨询和需求模型,兼顾业务专家身份
  • 架构阶段: 进行系统分析与设计,进行系统抽象,设计系统模型,进行技术原型,开发架构原型等
  • 设计阶段: 指导设计人员完成详细设计
  • 开发阶段: 指导开发人员按设计实现,解决技术难题
  • 测试阶段: 指导测试人员工做,特别是非功能需求测试
  • 发布阶段: 指导部署人员按照部署架构进行部署,及时解答或反馈运行期间架构问题
  • 其余工做: 技术选型,人员培训,技术指导

软件架构师工做流程

• 架构的工做流程是一个系统如何从需求,架构到实现的的过程和方法
• 良好的架构:
  • 须要架构师具有技术和架构设计能力以外,还须要具备良好丰富的业务知识
  • 从软件工程角度,架构师不只要参与系统架构和设计阶段外,还要参与需求分析阶段,开发,测试,发布,试运行阶段
• 需求分析主要包括需求模型,架构模型,设计模型和解决方案模型:
  • 需求模型: 参与需求分析和需求模型设计,提供技术建议或引导需求定义,提供解决方案指导
    • 主要参与者: 需求分析师,业务分析师
    • 辅助参与者: 架构师,设计师
  • 架构模型: 根据需求模型,产出架构模型
    • 选择架构对象: 关键流程,核心用例和非功能需求
    • 流程建模: 梳理需求关键流程,分析业务对象,子系统,模块,设计出系统的交互流程
    • 领域建模: 梳理业务流程中设计的对象,子系统模块,划分子系统,模块,核心对象,通讯机制,事务模型等
    • 输出整体架构: 根据领域模型和业务流程模型,结合组件架构,部署架构,通讯机制,输出系统体架构方案
    • 架构验证: 验证架构可用性,能够用评审或架构原型的方式,进行评审或实际测试验证
    • 主要参与者: 架构师,架构委员会
    • 辅助参与者: 系统设计师,开发人员,测试人员
  • 设计模型: 在架构师的指导下,根据系统架构,完成各子系统,模块,功能,接口的概要或详细设计
    • 主要参与者: 系统设计师,高级工程师
    • 辅助参与者: 架构师
  • 解决方案模型: 架构模型,设计模型,架构原型等统一组成架构解决方案
• 一个完整的系统架构包括:
  • 总体架构
  • 子系统
  • 模块
  • 功能概要或详细设计
  • 通讯机制
  • 事务机制
  • 接口定义,包括内部和外部
  • 领域模型
  • 业务流程
  • 数据库设计
  • 中间件
  • 组件架构
  • 部署架构
• 系统解决方案标准:
  • 知足功能和非功能性需求
  • 符合项目要求的规模和成本
  • 知足开发,测试和发布要求

软件架构师能力模型

通用能力

架构思惟

自顶向下构建架构

• 定义问题:
  • 定义问题中最重要的是定义客户的问题
  • 定义问题,特别是识别出关键问题.
  • 关键问题是对客户有体感,可以解决客户痛点,经过必定的数据化来衡量识别出来,关键问题要优先给出解决方案
• 问题定义加入时间维度:
  • 将方案和问题定义区分开来
• 分析问题定义:
  • 须要对问题进行升层思考后再进行升维思考,从而真正抓到问题的本质,理清和挖掘清楚需求
  • 要善用第一性原理思惟进行分析思考问题
• 问题解决原则:
  • 使命: 先解决客户的问题
  • 愿景: 而后才能解决本身的问题
  • 强调的是可以为客户具体解决什么问题,而后才是咱们能变成什么,从而怎样去更好地服务客户
• 善用多种方法对客户问题进行分析:
  • 将客户问题转换成产品和平台须要提供的能力
  • 好比仓储系统WMS能够提供哪些商业能力
• 梳理现有流程和能力模型:
  • 找到须要提高的地方,升层思考和升维思考真正明确提高的部分
• 定义指标:
  • 定义指标并可以对指标进行拆解,而后进行数学建模
• 能力诉求转化为技术挑战:
  • 将能力诉求转换为技术人员的方案设计,须要结合自底向上的架构推导方式
• 创新:
  • 创新能够是业务创新,也能够是产品创新,也能够是技术创新,也能够是运营创新
  • 升层思考,升维思考,使用第一性原理思惟帮助本身在业务,产品,技术上发现不一样的创新可能
  • 哲科思惟是架构师的灵魂思惟

自底向上推导应用架构

• 先根据业务流程,分解出系统时序图,根据时序图对模块进行概括,从而获得粒度更大的模块,经过模块的组合或者聚合构建整个系统架构
• 应用逻辑架构的推导有4个子路径:
  • 业务概念架构: 来源于业务概念模型和业务流程
  • 系统模型: 来源于业务概念模型
  • 系统流程: 来源于业务流程
  • 非功能性的系统支撑: 来源于对性能,稳定性,成本的需求
• 最影响逻辑结构落地成物理架构的三大主要因素:
  • 效率
  • 稳定性
  • 性能
• 从逻辑架构到物理架构,必定须要先对效率,稳定性和性能作出明确的量化要求
• 自底向上依赖于演绎和概括:
  • 若是产品方案已经明确,程序员须要理解这个业务需求,并根据产品方案推导出架构,通常使用自底向上的方法.领域建模就是这种自底向上的分析方法
• 演绎: 演绎就是逻辑推导,越是底层,越须要演绎
  • 从用例到业务模型就属于演绎
  • 从业务模型到系统模型也属于演绎
  • 根据目前的问题,推导出须要实施某种稳定性措施也是演绎
• 概括: 概括是根据事物的某个维度来进行归类,越是高层的,越须要归类
  • 问题空间模块划分属于概括
  • 逻辑架构也有的属于概括
  • 根据一堆稳定性问题来概括出事前,事中,过后都须要的对应的操做,是就时间维度来进行概括

领域驱动设计架构

• 领域划分设计步骤:
  • 对用户需求场景进行分析,识别出业务全维度的用例
  • 分析模型鲁棒图,识别出业务场景中全部的实体对象
    • 鲁棒图:
      • 需求设计过程当中使用的一种方法-鲁棒性分析
      • 经过鲁棒分析法可让设计人员更清晰,更全面地了解需求
      • 一般使用在需求分析后及需求设计前作软件架构分析之用,主要注重于功能需求的设计分析工做
      • 需求规格说明书为其输入信息,设计模型为其输出信息
      • 是功能需求向设计方案过渡的第一步,重点是识别组成软件系统的高级职责模块,规划模块之间的关系
      • 鲁棒图包含三种图形:
  • 领域划分,将全部识别出的实体对象进行分类
  • 评估域划分合理性,并进行优化

基于数据驱动设计架构

• 随着loT,大数据和人工智能的发展,之前的领域驱动的方式架构每每知足不了需求或者达不到预期的效果
• 在大数据的应用场景中:
  • 从领域分析升维到基于大数据统计分析结果来进行业务架构,应用架构,数据架构和技术架构
  • 须要具有数理统计分析的基础和BI的能力,以数据思惟来架构系统
  • 好比阿里的数据分析平台采云间和菜鸟的数据分析平台FBI

专业能力

• 企业级应用的架构师: 负载均衡,集群,分布式,高并发,高可用,易管理等等,理论能力和动手编码能力须要同时提升.注重设计思想和设计模式,对于前沿技术,要不懈的追求和钻研,这样才能在技术架构选型时作出合理的决策
  • 数据层: 重点在于集群方案的选择
    • 好比MySQL集群,集群方案不少,须要选择符合业务的方案:好比多主,主备,读写分离
    • 是否还须要作高可用,是用lvs,仍是zookeeper
    • 是否须要mycat类中间件来管理数据库或者作数据分片等等
  • 服务层:
    • 选择Dubbo,主要用于高并发的系统,微服务让团队开发耦合度下降,各自关心各自模块,以服务的方式发布出去
    • 传统一点使用SpringMVC+RESTful
    • 缓存的选择,能够用memcached,ehcache,redis
  • 应用层: 选择适合适合团队的框架
  • 网络层: 了解F5之类
  • 部署:
    • 是否须要用Docker部署,开源Docker容器让部署轻量化,易于扩展一个节点,对于高并发,伸缩性要求高的场景可使用,能够实现一键部署
    • 是否须要负载均衡,能够选择硬负载F5,也能够用软负载nginx
    • 软负载方案能够是apache+tomcat,须要考虑session复制
    • 也能够选择lvs+haproxy,打包发布,熟练使用maven,创建本身的maven私服,能指导项目成员使用maven发布
  • 安全: 大多数安全问题在网络层就解决了,但应用的安全不容忽视
    • 须要考虑SQL注入,受权认证
    • 重点的安全问题来自框架自己,尽可能解决开源框架中的应用漏洞
  • 其余方面: 自动化测试,版本管理,大数据,人工智能

必备技能

设计

• 理论层面:
  • 了解基本的设计模式
  • 研究一下模式与反模式
  • 了解质量度量
• 实践层面:
  • 尝试理解不一样的技术栈
  • 分析和理解应用模式:
    • 查看当前流行的框架
    • 在实践中学习不少模式
    • 理解如何在框架中应用模式,为何要这样作
    • 深刻地研究代码并了解如何实现的

决策

架构师须要制定决策,指引项目甚至整个公司的正确方向

• 分清主次:
  • 概念完整性
  • 一致性
• 优先级
• 认清本身的能力,明确本身的职责
• 评估多种选择

简化

• 多方位观察解决方案
• 分而治之
• 重构

编程

• 开发副项目:
  • 大量的编程语言,框架,工具,流程和实践
• 只尝试须要尝试的事情

记录

• 架构文档
• 代码整洁
• 在可能的状况下生成文档:
  • 利用工具生成文档: Swagger, RAML
• 尽量多记必需的东西,内容尽量少:
  • 用于理解该文件的全部必要信息都包括在内了吗
  • 哪些信息是真正须要的,哪些是能够省略的
• 更多地了解架构框架

成长方式

广度

• 广度: 架构师应该对所在领域的主流技术体系有一个全面清晰的认识,每一种技术不须要深刻的了解,但必须指导每一个技术的三个层面
  • 每种技术的由来,为何会出现这种技术?这种技术是用来解决什么问题的?
  • 每种技术是什么?技术的基本组成是什么?
  • 解决同一个问题的相同技术各自优缺点是什么?更适合哪一种场景?只有清晰认识同一类型技术的优缺点,才能在技术选型可以使用更加合理的技术
• 广度学习方法: 对各主流技术一一经过搜索引擎了解三个层面的内容

高度

• 高度: 架构师应该具有可以从纷繁杂乱的信息中创建抽象的能力
  • 业务抽象: 可以从软件和产品的复杂需求中抽象出核心业务实体,并给业务实体创建合理的关系
  • 技术抽象: 可以对复杂的技术架构进行分层抽象,服务抽象或者微服务抽象,组件抽象,并为各层和各层服务之间调用创建合理关系
• 高度学习方法: 深刻理解和学习面向对象,设计模式,琢磨优秀开源框架的设计原理和设计思想

深度

• 深度: 架构师对主流技术有深刻理解
  • 对主流技术的原理,运做机理有基本全面的理解
  • 至少要对一种技术有深刻的认识,是这种技术的专家,熟悉源代码

宽度

• 宽度: 架构师要熟知当前的技术前沿和热点,可以使用新的技术解决问题.好比微服务,大数据,云计算,人工智能
• 宽度学习方法: 订阅相关的技术咨询,按期了解,对于和所负责工做相关的技术进一步了解

软件架构师技术能力

• 软件架构师要会解决问题: 一个系统中,若是拆解出来了不少模块,应该部署在哪些机器上
  • 慢SQL优化
  • Memcache缓存
  • 负载均衡
  • 热备,冷备,双活
• 根据不一样的应用须要,去设计不一样的策略,同时将这些场景规范化,成为一整个团队都要遵循的标准:
  • 穿透DB
  • 失效策略
• 每个技术框架的选择,都通过讨论,验证,测试,最终在全团队里推行:
  • Tuscany
  • Scallop
  • Hadoop
  • ActiveMQ
  • Erlang
  • hertrix
  • DevOps
• 架构师职责:
  • 须要从前到后都要懂
  • 须要制定关键的技术细节,须要给出最佳实践
  • 须要了解业界全部流行的解决方案
  • 这些方案可不能够拿过来,一样适用于本身的场景
• 架构师须要精通:
  • 分布式
  • Nginx
  • F5
  • 微服务
  • 缓存
  • 持久化
  • 消息队列
• 架构师须要熟悉:
  • 全部技术细节里最经常使用的解决方案,不能有遗漏,也不能过分设计
• 架构师还要肩负起修复开源软件Bug的任务.须要看源码,理解开源框架的思路,而后找有可能产生问题的地方,再去修复
• 架构师须要在有效的时间内,弄懂全部底层的东西,TCP/IP详解
• 没有不懂业务的架构师,全部的架构,都依赖于业务:
  • 全部的架构师,也必须写业务代码
  • 不把本身设计的东西,用在真正的项目里,是不会理解架构设计的合理性在哪的

通用的架构框架

TOGAF

• TOGAF: The Open Group Architecture Framework
• TOGAF强调商业目标做为架构的驱动力,并提供一个最佳实践的储藏库:
  • TOGAF架构开发方法ADM
  • TOGAF架构内容框架
  • TOGAF参考模型
  • ADM架构开发方法指引和技术
  • 企业连续统一体
  • TOGAF能力框架

ADM

• ADM是一个迭代的步骤顺序以发展企业范围的架构的方法:

• 架构内容框架:

• 参考模型:

• ADM指引和技术:
  • 架构迭代阶段:
  • 在不一样的水平领域运用ADM:

• 利益相关者分类:

• 企业连续统一体:
  • 架构指导及支持解决方案:
    • 基础
    • 通用系统
    • 行业组织特定
• 能力框架:

DODAF

• DODAF是一个控制 “EA开发,维护和决策生成” 的组织机制,是统一组织 “团队资源,描述和控制EA活动” 的整体架构
  • DODAF涵盖DoD的全部业务领域
  • 定义了表示,描述,集成DoD范围内众多架构的标准方法,确保架构可比较,评估
  • 提供了对系统族Fos和体系SoS进行理解,比较,集成和互操做共同架构的基础,提供开发和表达架构描述的规则和指南
• DODAF的核心是8个视点和52个模型:

• 全景视点AV
  • 与全部视点相关的体系结构描述的顶层概貌
  • 提供有关体系结构描述的整体信息:
    • 体系结构描述的范围:
      • 专业领域
      • 时间框架
    • 体系结构描述的背景:
      • 条令
      • 战术
      • 技术
      • 程序
      • 相关目标和构想描述
      • 做战概念CONOPS
      • 环境条件

• 能力视点CV
  • 集中反映了与总体愿景相关的组织目标,这些愿景在特定标准和条件下进行特定行动过程或是达成指望效果的能力,综合使用各类手段和方式来完成一组任务
  • 为体系结构描述中阐述的能力提供了战略背景和相应的高层范围,比做战概念图中定义的基于想定的范围更全面
  • 这些模型是高层的,用决策者易于理解的术语来描述能力,以便沟通能力演进方面战略构想
• 做战视点OV
  • 集中反映了完成DoD使命的机构,任务,或执行的行动以及彼此之间必须交换的信息
  • 描述信息交换的:
    • 种类
    • 频度
    • 性质
    • 信息交换支持哪些任务和活动
• 服务视点ScvV
  • 集中反映了为做战行动提供支撑的系统,服务和相互交织的功能
  • DoD流程包括做战,业务,情报和基础设施功能
  • SvcV功能和服务资源及要素能够连接到OV中的体系结构数据.这些系统功能和服务资源支撑做战行动,促进信息交换
• 系统视点SV
  • 集中反映支持做战行动中的自动化系统,相互交联和其他系统功能的信息
• 数信视点DIV
  • 数信视点DIV: 指数据和信息视点
  • 反映了体系结构描述中的业务信息需求和结构化的业务流程规则
  • 描述体系结构描述中与信息交换的相关信息,诸如属性,特征和相互关系
• 标准视点StdV
  • 用来管控系统各组成部分或要素的编排,交互和相互依赖的规则的最小集
  • 目的是确保系统能知足特定的一组操做需求
  • 提供技术系统的实施指南,以工程规范为基础,确立通用的积木块,开发产品线
  • 包括:
    • 技术标准
    • 执行惯例
    • 标准选项
    • 标准规则
    • 标准规范
  • 这些标准在特定体系结构描述中能够组成管控系统和系统或者服务要素的文件profile
• 项目视点PV
  • 集中反映了项目是如何有机地组成一个采办项目的有序组合
  • 描述多个采办项目之间的关联关系,每一个采办项目都负责交付特定系统或能力