这是我参与更文挑战的第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
  • 集中反映了项目是如何有机地组成一个采办项目的有序组合
  • 描述多个采办项目之间的关联关系,每个采办项目都负责交付特定系统或能力