软件架构师:
制定高级设计决策,并确定技术标准,包括编程标准,工具和平台的软件专家软件架构:
系统的基本组织构成,这种组织主要体现在其组件,组件之间关系,组件与环境之间的关系,以及决定系统设计与演化原则架构是系统的蓝图,描述了系统的结构和关键决策架构包含系统的功能和非功能性需求:
系统如何实现的?系统与子系统是如何划分的?系统之间是如何通信的?系统功能如何设计和交互的?包含重要的架构决策,系统组成,功能设计,技术选型,成本分析等等架构的基础是设计满足客户需求的系统,其中包含功能性,非功能性以及质量和约束
架构师一定要负责整个系统中最核心和最难的地方编写,并且设计好团队合作开发方式,能根据编程经验看到未来的变化如果一个团队里需要一个架构师,一定是一位代码能力最好的,能够负责核心业务的开发,并且不能脱离实际业务
项目中包含哪些角色:
客户: 为系统开发买单的人,关注系统的业务价值用户: 使用系统的人,关注是否满足功能需求,提升效率和易用性等项目经理: 负责项目管理,组织,协调,沟通等管理工作需求分析师: 负责需求相关工作,比如业务分析,需求获取,需求调研,需求管理,编写需求规格说明书等系统架构师: 负责整体的系统分析,架构规划,技术选型,核心功能需求和非功能性需求的架构设计系统设计师: 在架构模型的基础上,进行核心功能和非核心功能的详细设计开发人员: 根据架构设计和详细设计完成编码和单元测试,达到提测标准测试人员: 验证开发功能是否满足需求,比如进行功能测试,集成测试,性能测试,压力测试,安全性测试,回归测试等运维人员: 负责部署环境搭建,部署和日常维护架构师职责架构师需要建立高效卓越的体系,在规定的时间内完成项目架构师需要:
识别定义并确认需求进行系统分解形成整体架构正确地技术选型制定技术规格说明并有效推动落地架构师的角色:
理解并解析需求创建有用的模型确认并细化扩展模型管理架构
软件架构层级应用级最低层级的架构层级低,但是很详细这种层级的交流一般是在一个开发团队内展开
解决方案级架构的中间层关注一个或多个满足业务需求的应用,即商业方案这之中有些设计是高层次的,但大部分还是低层次的设计这种层级的交流开始涉及多个开发团队
企业级架构架构的最高层级关注多个设计方案这种架构的设计层次高且抽象,因此也需要方案级和应用级的架构师对此进行细化这种层级的架构需要多个组织进行沟通
架构师可以被看作是不同工作组之间的粘合剂:
横向: 在业务部和开发人员或者不同的开发团队之间架起沟通的桥梁纵向: 在管理者和开发人员之间架起桥梁技术: 将不同的技术或应用整合在一起解决方案架构师工作方式理解了解和挖掘客户痛点,项目定义,现有环境管理梳理明确高阶需求和非功能性需求对客户问题已经存在什么解决方案沟通,方案建议,多次迭代,交付总体架构架构决策
职责从客户视图看:
坚定客户高层信心: 利用架构和解决方案能力,帮助客户选择相关解决方案解决客户中层问题: 利用相关解决方案,帮助客户解决业务问题,获得业务价值引领客户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尽可能多记必需的东西,内容尽可能少:
用于理解该文件的所有必要信息都包括在内了吗哪些信息是真正需要的,哪些是可以省略的