聊聊架构
2016-04-06 10:10
323 查看
这篇文章是转来的
背景
什么是架构师?业内一直没有定论,在前两天『聊聊架构』群的讨论中,来自各大互联网公司的架构师都对自己的工作内容做了总结,然我们还是没有抽象出架构师的定义。反而引来了跟多的问题,比如:
架构师应该写代码吗?
架构师有分类吗?
好的应用应该包含哪些特点?什么才是好的应用系统?
对于架构师,有哪些能力要求?
怎么才是完整的方案? 怎么写出完整甚至完美的方案?
为了回答这些问题,1月10日晚上8点30分,我们邀请了1号店资深架构师张立刚来分享他自己的经验。本文根据其演讲整理而成。精彩观点提前看:
代码也有架构有规范,后续的维护、扩展全靠它了,代码的结构规划也体现出一个人的架构规划能力。
给你一套新的毛坯房你能设计出一个漂亮的家,给你一套阴暗狭窄的老公房你依然能设计打造出一个温馨的家,这才是本事。
空降的架构师要先放到具体的核心项目里,沉下心来专注于一线的代码开发、业务讨论等至少2-3个月的时间,才有能力对现有系统提出相应的方案或改进意见。
一个好的业务系统一定是技术与业务的完美平衡,完全满足业务需求做不出好系统。
记住,首先技术是为业务服务的,再者,技术可以推动业务。
架构分类
关于架构,大体可以分为以下三类:
IT架构
基于硬件、网络等构建整体的IT运维架构体系,包括IDC机房、网络拓扑、安全、负载均衡、运维监控等
基础架构
主要基于基础服务的软件产品架构,如SOA中间件、消息中间件、规则引擎、大数据存储、数据库产品、第三方组件等,相对独立于业务系统、不考虑具体的业务场景,更多地关注技术产品本身的性能、可靠、可扩展等,服务于业务系统。
应用架构
偏重于业务功能的实现,在基于用户需求实现业务功能、提升用户体验的基础上,保证系统的性能、可靠、可维护、可扩展。
关于应用架构师
我个人更愿意把应用架构师称之为SA(system analysist),即系统分析师。
应用架构师是用户(需求方)与开发人员(实现方)的桥梁,他的作用就是把业务与技术更好地结合起来,站在中立的角度-不唯技术、不唯业务,在业务和技术之间找到那个平衡点,做出最好的系统。
记住:首先,技术是为业务服务的;再者,技术可以推动业务。
什么是好的应用系统(架构)
好的应用系统特点
满足业务功能
用户体验好
稳定可靠
维护简单
扩展性强
完全满足业务需求做不出好系统
业务需求是理想、技术是现实,理想是我们希望像鸟儿一样自由地飞出银河系,现实就是我们刚能踏上月球,还上不了火星,还必须借助于笨重的宇航服、宇宙飞船。
纯靠技术做不出好的业务系统
以减少系统功能降低用户体验为代价的高可用、高性能、高并发等貌似很NB的系统是得不到赞赏的。
一个好的业务系统一定是技术与业务的完美平衡
找到这个平衡点,是应用架构师的职责。
架构师能力要求
先看一个百度而来的架构师能力要求
一般来讲,系统架构师应该拥有以下几方面的能力:
具备 8 年以上软件行业工作经验;
具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验;
具备 3 年以上的代码编写工作经验;
具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验;
对相关的技术标准有深刻的认识,对软件工程标准规范有良好的把握;
具有面向对象分析、设计、开发能力(OOA、OOD、OOP)
精通大型数据库如 Oracle、Sql Server 等的开发;
对计算机系统、网络和安全、应用系统架构等有全面的认识,熟悉项目管理理论,并有实践基础;
在应用系统开发平台和项目管理上有深厚的基础,有大中型应用系统开发和实施的成功案例;
良好的团队意识和协作精神,有较强的内外沟通能力。
如果我要招聘应用架构师会再加一条,并且是第一条
优秀的业务理解、分析能力,能站在业务的角度实现用户需求、提升用户体验。
因为上述的10条要求大多地是从技术的角度考虑的,可忽略了一点,我们做出来的系统是给用户使用的,用户说好才是真的好。
架构师的职责,不仅仅是技术
架构师要做以下工作:
需求分析->系统分解->技术选型->系统设计->培训与指导->沟通与推动
技术选型、系统设计才涉及到技术,培训与指导也仅仅一半是技术相关,其他基本与技术无关
架构师是一个多角色综合体
用户—使用方
产品设计者—产品经理
方案设计者—狭义上的架构师
开发人员—功能实现者
维护人员—系统维护者
只有站在一个系统所有的干系人角度,你才能设计出好的系统。
几点经验
架构师不仅仅是技术架构,也是业务专家
专注于技术领先的是技术专家,不是应用架构师。
首先站在业务的角度去考虑问题,找到业务架构和技术架构的平衡。
架构师要培养
空降的架构师不接地气,给出来的方案或架构很美、很理想,但很难落地实现。这个方案拿去给投资方演示很有用。
空降的架构师不是能力不行,而是他不了解现有系统、技术和业务
空降的架构师要先放到具体的核心项目里,沉下心来专注于一线的代码开发、业务讨论等至少2-3个月的时间,才有能力对现有系统提出相应的方案或改进意见
架构师要内部选拔,不足是视野不够,要提供学习培训等机会让其开阔视野,如InfoQ架构师峰会(没收广告费哈)。
外部空降+内部选拔+培养的方式,能让你的架构师团队更强大,只是培养方式要稍有不同,外部空降的要往下摁让其根基牢固有深度、内部选出的要往上拔让其视野开阔有高度。
不要轻易说推倒重来
在初始阶段设计出可扩展的架构是架构师一般的能力体现
在维护阶段能在现有架构基础上进一步提升系统的扩展性,这是架构师的境界。
给你一套新的毛坯房你能设计出一个漂亮的家,给你一套阴暗狭窄的老公房你依然能设计打造出一个温馨的家,这才是本事。
太多的系统,我们永远没有推到重来的机会,只能优化、优化、不断地优化
架构师要不要写代码?可能的话,尽量写吧
不写你怎么知道技术的痛点、怎么把控技术的方向
代码也有架构有规范,后续的维护、扩展全靠它了,代码的结构规划也体现出一个人的架构规划能力
技术人员最崇拜的就是技术,在这个圈子里除了以德服人,以技术服人更容易被大家接受,至少要有共同语言不要让大家嘲笑你吧!
作为架构师,你能写出一个完整的方案吗?
怎么才是完整的方案
一说方案,好多人就拿出技术架构图、流程图了,很漂亮很完美,NO,NO这不是一个完整的方案。
完整的方案应该包括但不限于以下要素:
项目概述:项目背景、项目需求、项目价值、项目干系人
系统概述:系统目标、系统功能
系统设计:架构设计、技术选型、系统性能\容量\扩展、功能设计等
系统实现:详细开发设计、数据库设计等
系统依赖:中间件、第三方系统、第三方组件等
怎么写出完整甚至完美的方案
还记得上面说的那几个角色么:用户、产品设计者、方案设计者、开发人员、维护人员
同时站在他们的角度看,你一定会写好的。
背景
什么是架构师?业内一直没有定论,在前两天『聊聊架构』群的讨论中,来自各大互联网公司的架构师都对自己的工作内容做了总结,然我们还是没有抽象出架构师的定义。反而引来了跟多的问题,比如:
架构师应该写代码吗?
架构师有分类吗?
好的应用应该包含哪些特点?什么才是好的应用系统?
对于架构师,有哪些能力要求?
怎么才是完整的方案? 怎么写出完整甚至完美的方案?
为了回答这些问题,1月10日晚上8点30分,我们邀请了1号店资深架构师张立刚来分享他自己的经验。本文根据其演讲整理而成。精彩观点提前看:
代码也有架构有规范,后续的维护、扩展全靠它了,代码的结构规划也体现出一个人的架构规划能力。
给你一套新的毛坯房你能设计出一个漂亮的家,给你一套阴暗狭窄的老公房你依然能设计打造出一个温馨的家,这才是本事。
空降的架构师要先放到具体的核心项目里,沉下心来专注于一线的代码开发、业务讨论等至少2-3个月的时间,才有能力对现有系统提出相应的方案或改进意见。
一个好的业务系统一定是技术与业务的完美平衡,完全满足业务需求做不出好系统。
记住,首先技术是为业务服务的,再者,技术可以推动业务。
架构分类
关于架构,大体可以分为以下三类:
IT架构
基于硬件、网络等构建整体的IT运维架构体系,包括IDC机房、网络拓扑、安全、负载均衡、运维监控等
基础架构
主要基于基础服务的软件产品架构,如SOA中间件、消息中间件、规则引擎、大数据存储、数据库产品、第三方组件等,相对独立于业务系统、不考虑具体的业务场景,更多地关注技术产品本身的性能、可靠、可扩展等,服务于业务系统。
应用架构
偏重于业务功能的实现,在基于用户需求实现业务功能、提升用户体验的基础上,保证系统的性能、可靠、可维护、可扩展。
关于应用架构师
我个人更愿意把应用架构师称之为SA(system analysist),即系统分析师。
应用架构师是用户(需求方)与开发人员(实现方)的桥梁,他的作用就是把业务与技术更好地结合起来,站在中立的角度-不唯技术、不唯业务,在业务和技术之间找到那个平衡点,做出最好的系统。
记住:首先,技术是为业务服务的;再者,技术可以推动业务。
什么是好的应用系统(架构)
好的应用系统特点
满足业务功能
用户体验好
稳定可靠
维护简单
扩展性强
完全满足业务需求做不出好系统
业务需求是理想、技术是现实,理想是我们希望像鸟儿一样自由地飞出银河系,现实就是我们刚能踏上月球,还上不了火星,还必须借助于笨重的宇航服、宇宙飞船。
纯靠技术做不出好的业务系统
以减少系统功能降低用户体验为代价的高可用、高性能、高并发等貌似很NB的系统是得不到赞赏的。
一个好的业务系统一定是技术与业务的完美平衡
找到这个平衡点,是应用架构师的职责。
架构师能力要求
先看一个百度而来的架构师能力要求
一般来讲,系统架构师应该拥有以下几方面的能力:
具备 8 年以上软件行业工作经验;
具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验;
具备 3 年以上的代码编写工作经验;
具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验;
对相关的技术标准有深刻的认识,对软件工程标准规范有良好的把握;
具有面向对象分析、设计、开发能力(OOA、OOD、OOP)
精通大型数据库如 Oracle、Sql Server 等的开发;
对计算机系统、网络和安全、应用系统架构等有全面的认识,熟悉项目管理理论,并有实践基础;
在应用系统开发平台和项目管理上有深厚的基础,有大中型应用系统开发和实施的成功案例;
良好的团队意识和协作精神,有较强的内外沟通能力。
如果我要招聘应用架构师会再加一条,并且是第一条
优秀的业务理解、分析能力,能站在业务的角度实现用户需求、提升用户体验。
因为上述的10条要求大多地是从技术的角度考虑的,可忽略了一点,我们做出来的系统是给用户使用的,用户说好才是真的好。
架构师的职责,不仅仅是技术
架构师要做以下工作:
需求分析->系统分解->技术选型->系统设计->培训与指导->沟通与推动
技术选型、系统设计才涉及到技术,培训与指导也仅仅一半是技术相关,其他基本与技术无关
架构师是一个多角色综合体
用户—使用方
产品设计者—产品经理
方案设计者—狭义上的架构师
开发人员—功能实现者
维护人员—系统维护者
只有站在一个系统所有的干系人角度,你才能设计出好的系统。
几点经验
架构师不仅仅是技术架构,也是业务专家
专注于技术领先的是技术专家,不是应用架构师。
首先站在业务的角度去考虑问题,找到业务架构和技术架构的平衡。
架构师要培养
空降的架构师不接地气,给出来的方案或架构很美、很理想,但很难落地实现。这个方案拿去给投资方演示很有用。
空降的架构师不是能力不行,而是他不了解现有系统、技术和业务
空降的架构师要先放到具体的核心项目里,沉下心来专注于一线的代码开发、业务讨论等至少2-3个月的时间,才有能力对现有系统提出相应的方案或改进意见
架构师要内部选拔,不足是视野不够,要提供学习培训等机会让其开阔视野,如InfoQ架构师峰会(没收广告费哈)。
外部空降+内部选拔+培养的方式,能让你的架构师团队更强大,只是培养方式要稍有不同,外部空降的要往下摁让其根基牢固有深度、内部选出的要往上拔让其视野开阔有高度。
不要轻易说推倒重来
在初始阶段设计出可扩展的架构是架构师一般的能力体现
在维护阶段能在现有架构基础上进一步提升系统的扩展性,这是架构师的境界。
给你一套新的毛坯房你能设计出一个漂亮的家,给你一套阴暗狭窄的老公房你依然能设计打造出一个温馨的家,这才是本事。
太多的系统,我们永远没有推到重来的机会,只能优化、优化、不断地优化
架构师要不要写代码?可能的话,尽量写吧
不写你怎么知道技术的痛点、怎么把控技术的方向
代码也有架构有规范,后续的维护、扩展全靠它了,代码的结构规划也体现出一个人的架构规划能力
技术人员最崇拜的就是技术,在这个圈子里除了以德服人,以技术服人更容易被大家接受,至少要有共同语言不要让大家嘲笑你吧!
作为架构师,你能写出一个完整的方案吗?
怎么才是完整的方案
一说方案,好多人就拿出技术架构图、流程图了,很漂亮很完美,NO,NO这不是一个完整的方案。
完整的方案应该包括但不限于以下要素:
项目概述:项目背景、项目需求、项目价值、项目干系人
系统概述:系统目标、系统功能
系统设计:架构设计、技术选型、系统性能\容量\扩展、功能设计等
系统实现:详细开发设计、数据库设计等
系统依赖:中间件、第三方系统、第三方组件等
怎么写出完整甚至完美的方案
还记得上面说的那几个角色么:用户、产品设计者、方案设计者、开发人员、维护人员
同时站在他们的角度看,你一定会写好的。
相关文章推荐
- 架构纵横谈之二 ---- 架构的模式与要点
- BS项目中的CSS架构_仅加载自己需要的CSS
- 关于三种主流WEB架构的思考
- Android操作系统的架构设计分析
- w3c技术架构介绍
- linux学习笔记 linux目录架构
- mysql数据库应付大流量网站的的3种架构扩展方式介绍
- 从零开始搭建MySQL MMM架构
- C/S和B/S两种架构的概念、区别和联系
- 限时抢购秒杀系统架构分析与实战
- Android App的运行环境及Android系统架构概览
- 也谈淘点点60s短信订单的架构设计
- android技术内幕心得
- 谈谈MVC与微信
- SequoiaDB 笔记
- Web服务器Nginx多方位优化策略
- 面试:(设计,架构)
- 十日谈
- memcached pk redis
- 悠然推荐:你的架构是如何一步步腐化的?