如何成为更好的软件架构师

软件架构师定义

• 软件工程师的职业发展方向:
  
• 软件架构师:
  • 制定高级设计决策,并确定技术标准,包括编程标准,工具和平台的软件专家
• 软件架构:
  • 系统的基本组织构成,这种组织主要体现在其组件,组件之间关系,组件与环境之间的关系,以及决定系统设计与演化原则
  • 架构是系统的蓝图,描述了系统的结构和关键决策
  • 架构包含系统的功能和非功能性需求:
    • 系统如何实现的?
    • 系统与子系统是如何划分的?
    • 系统之间是如何通信的?
    • 系统功能如何设计和交互的?
    • 包含重要的架构决策,系统组成,功能设计,技术选型,成本分析等等
  • 架构的基础是设计满足客户需求的系统,其中包含功能性,非功能性以及质量和约束
    
• 架构师一定要负责整个系统中最核心和最难的地方编写,并且设计好团队合作开发方式,能根据编程经验看到未来的变化
• 如果一个团队里需要一个架构师,一定是一位代码能力最好的,能够负责核心业务的开发,并且不能脱离实际业务

项目中包含哪些角色:

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

软件架构层级

应用级

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

解决方案级

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

企业级架构

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

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

软件架构师职责

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

---

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

软件架构师工作流程

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

软件架构师能力模型

通用能力

专业能力

• 企业级应用的架构师: 负载均衡,集群,分布式,高并发,高可用,易管理等等,理论能力和动手编码能力需要同时提高.注重设计思想和设计模式,对于前沿技术,要不懈的追求和钻研,这样才能在技术架构选型时做出合理的决策
  • 数据层: 重点在于集群方案的选择
    • 比如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
• 尽可能多记必需的东西,内容尽可能少:
  • 用于理解该文件的所有必要信息都包括在内了吗
  • 哪些信息是真正需要的,哪些是可以省略的
• 更多地了解架构框架

成长方式

广度

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

高度

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

深度

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

宽度

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