【深入代码系列】手牵手一起学架构思想
请在此处补充摘要
架构师这个是有国际标准(ISO/IEC 42010)可查的。
架构师概述
架构师分类
微软划分模式
- 企业架构师EA(Enterprise Architect)
EA决定整个公司的技术路线和技术发展方向。
盖茨给自己的Title就是首席软件架构师,网易丁磊也喜欢这么称呼自己,实际上就是EA角色。
- 基础结构架构师IA(Infrastructure Architect)
IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件,这些都是一个技术型公司传承下来的最宝贵的财富之一。
- 特定技术架构TSA(Technology-Specific Architect)
TSA主要从事类似安全架构、存储架构等专项技术的规划和设计工作.
- 解决方案架构师SA (Solution Architect)
SA工作则专于解决方案的规划和设计。
ps:大公司分得细,小公司不讲究,架构师多数是是IA+TSA+SA,一人包打天下,所以说大公司出专才,小公司出全才。
另一种划分模式
- 软件架构师(TSA+IA)
这也是程序员最容易突破,最可能走上的一条道路,比如JAVA架构师、DotNet架构师、LAPM架构师等等。
- 系统架构师(SA+TSA)
更着力于综合运用已有的产品和技术,来实现客户期望的需求。系统架构师要求通晓软、硬件两方面的知识,所以它的知识体系相对庞杂。
架构师职责
要知道架构师都在做什么
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调。
架构师主要职责有4条
1、确认需求
在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可。
==架构师需要和分析人员反复交流==,以保证自己完整并准确地理解用户需求。
2、系统分解
依据用户需求,架构师将系统整体分解为更小的子系统和组件,从而形成不同的逻辑层或服务。随后,架构师会确定各层的接口,层与层相互之间的关系。架构师不仅要对整个系统分层,进行“纵向”分解,还要对同一逻辑层分块,进行“横向”分解。
软件架构师的功力基本体现于此,这是一项相对复杂的工作。
3、技术选型
架构师通过对系统的一系列的分解,最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上?数据库采用MSSql、Oracle还是Mysql?需要不需要采用MVC或者Spring等轻量级的框架?前端采用富客户端还是瘦客户端方式?类似的工作,都需要在这个阶段提出,并进行评估。
架构师对产品和技术的选型仅仅限于评估,没有决定权,最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息,项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡,最终进行确认。
4、制定技术规格说明
架构师在项目开发过程中,是技术权威。他需要协调所有的开发人员,与开发人员一直保持沟通,始终保证开发者依照它的架构意图去实现各项功能。
架构师与开发者沟通的最重要的形式是技术规格说明书,它可以是UML视图、Word文档,Visio文件等各种表现形式。通过架构师提供的技术规格说明书,保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。
架构师不仅要保持与开发者的沟通,也需要与项目经理、需求分析员,甚至与最终用户保持沟通。所以,对于架构师来讲,不仅有技术方面的要求,还有人际交流方面的要求。
架构师的误区
1、架构师就是项目经理
架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作,具备管理职能。一般小型项目中,常见项目经理兼架构师。
2、架构师负责需求分析
架构师不是需求分析员。需求分析人员的工作是收集需求和分析需求,并与最终用户、产品经理保持联系。架构师只对最终的需求审核和确认,提出需求不清和不完整的部分,他会跟需求分析员时刻保持联系。架构师是技术专家,不是业务专家。
3、架构师从来不写代码
这是一个尚存争论的问题。目前有两种观点:
观点1:架构师不写代码,写代码纯体力活,架构师写代码大材小用。架构师把UML的各种视图交给开发人员,如果有不明确的地方,可以与架构师随时沟通。
观点2:架构师本来自于程序员,只是比程序员站的层面更高,比程序员唯一多的是经验和知识,所以架构师也免不了写代码。
我个人觉得这两种说法是与架构师的出身和所处的环境有关。
架构师首先是一个技术角色,所以一定是来自于技术人员这个群体,比如系统架构师,多是来自于运维人员,可能本身代码写得并不多,或者说写不出来很漂亮的代码。软件架构师多是来自于程序员,有着程序员的血统和情怀,所以在项目开发过程中,可能会写一些核心代码。我们的理想是架构师不用写代码,但事实上有时候过于理想。架构师写不写代码,可能取决于公司的规模、文化、开发人员的素质等现实情况。另外,架构师也不是跟程序员界限分得那么清楚,按照能力也有高中低之分,写不写代码不是区分两者的根本标准。
架构师的基本素质
沟通能力☆☆☆☆☆
为了提高效率,架构师必须赢得团队成员、项目经理、客户或用户认同,这就需要架构师具有较强的沟通能力。沟通能力是人类最普遍性的素质要求,技术人员好像容易忽略,想成为架构师就不能忽略。非常重要!
领导能力
架构师能够推动整个团队的技术进展,能在压力下作出关键性的决策,并将其贯彻到底。架构师如何来保证这种执行力?这就需要架构师具有领导能力。
架构师的领导能力的取得跟项目经理不太一样。项目经理主要负责解决行政管理,这种能力与技术关系不大,他有人权和财权,再扯上一张“领导”的虎皮,采用“胡萝卜加大棒”的方式,基本上可以保证执行力。架构师在项目里面可能更多地使用非正式的领导力,也就是我们常说的影响力,里面包括个人魅力、技术能力、知识传递等等。
抽象思维和分析能力
架构师必须具备抽象思维和分析的能力,这是你进行系统分析和系统分解的基本素质。只有具备这样的能力,架构师才能看清系统的整体,掌控全局,这也是架构师大局观的形成基础。你如何具备这种能力呢?
一是来自于经验,二是来自于学习。
架构师不仅要具备在问题领域上的经验,也需要具备在软件工程领域内的经验。也就是说,架构师必须能够准确得理解需求,然后用软件工程的思想,把需求转化和分解成可用计算机语言实现的程度。经验的积累是需要一个时间过程的,这个过程谁也帮不了你,是需要你去经历的。但是,如果你有意识地去培养,不断吸取前人的经验的话,还是可以缩短这个周期的。
技术深度和广度
架构师最好精通1-2个技术,具备这种技术能力可以更加深入的理解有关架构的工作原理,也可以拉近和开发人员的距离,并形成团队中的影响力。
架构师的技术知识广度也很重要,需要了解尽可能多的技术,所谓见多识广,只有这样,才可能综合各种技术,选择更加适合项目的解决方案。有的人说,架构师技术广度的要求高于技术深度的要求,这是很有道理的。
总而言之,一句话:架构师是项目团队中的技术权威。
架构师要做的工作(运维角度)
1.需要搭建高可用的框架,比如就拿最简单的搭建数据库服务来说,得考虑如果一台MySQL服务器宕了,如何保证业务切换到另外一台机器上。
2.需要考虑高并发的因素,从这个点展开,架构师至少需要会用nginx,mycat,netty,redis之类的工具,以及考虑搭建实现负载均衡的集群。
3.需要把设计好的架构部署上线,或者哪怕上线动作是由运维来做,但架构师至少要知道如何把nginx集群等组件部署上线的活,由此架构师需要了解必须的linux命令和脚本,以及了解jenkins之类的部署工具。
4.上述技能不是简单会用即可,如果在开发部署和运行过程中由问题,架构师得负责解决。这就要求架构师不能仅仅靠看视频知道如何搭建系统,更得具备针对netty等组件的debug能力,还得能通过看日志,知道集群的运作情况,如果集群出了问题,还得知道如何快速解决。
5.不能仅仅关注技术,更得结合业务,把诸如抢红包之类的需求通过架构实现,这就要求架构师得知道各种组件的优劣,以此能选型并设计方案。
做久了CRUD,有的时候公司封装的太好了。体验不到架构。从运维角度入手架构可能是个不错的选择。
比如先从ant脚本,jenkins脚本和linux shell脚本入手,能知道系统的部署方式,以及熟悉必备的linux调试技能。
通过观察nginx或dubbo或zookeeper配置文件,了解各组件的运作方式,并能通过这些了解高并发高可用系统里负载均衡和失效转移等配置方式。
可以观察线上相关的日志,了解系统部署的情况,以及从架构层面了解诸多组件间的关联。
在上述步骤里提到的脚本和日志,在平时工作中只要上点心,应该可以看到,或者我们可以和运维人员多交流请教,上述组件部署和配置的知识也不难知道
从运维角度或许更容易理解像下面这样的题目。毕竟是实操过的。
如何部署nginx(或其它组件),从而实现高可用?
Redis集群里,容灾一般是怎么做的?
Kafka消息队列里,如何实现消息重复?如何确保消息不被重复消费?
或者是问底层的问题,比如说下netty里的读写索引工作方式。
理想中的架构师
只不过一个头衔而已,架构师最重要的一个技能是团队缺什么他可以补什么,对外可以写PPT吹牛逼,对内可以培训员工开发技术栈、运维技术栈、测试技术栈,网络技术栈。(针对外包公司)公司前期重心在网络和机房构建和中间件各个服务上,独立充当运维角色,开发运维比例7:3左右;公司前转中的过渡期,内网稳定,项目偏少,带人驻场开发,快速反馈bug快速解决bug,客户沟通交流;公司中期的发展,开始抓团队的代码质量问题,提高公司开发效率,更多的时候充当测试角色,用自己的经验告诉开发人员,怎么样的代码容易碰到什么样的坑,要如何避免这样的坑和内部员工的培训,不仅让员工只会curd,更应该让他们去思考,自己用的数据结构是一个怎么样的存在,和一些网络知识,起码碰到connection reset by peer和空报文知道是谁的问题。公司慢慢发展开,随着项目增多,便只负责前期规划项目,交付技术方案,具体团队遇到问题再负责协助解决,如果没有问题,划水啊,开心,快乐
上可九天揽月,下可五洋捉鳖。要懂产品,要会画图,沟通高效,擅长抽象,文档靠谱,代码牛P,技术通透,熟悉底层,基础牢固,调bug一流,算法不弱
岗位需求和行业分析
职业发展
title 与 能力
⼤⼚ vs 中⼩企业
title相对较虚,能⼒为实
只要你能力足够,title这玩意完全可以自己造,比如:我在上家做核心研发。
行业现状
研发经理 vs 架构师
在boss直聘/携程等检索:3-5年,java架构师,对比java经理,观察技术要求和薪资情况,可以发现实际企业的一些情况。
研发经理偏管理,架构师职业发展更好,后劲足
架构师怎么定义
岗位⽐较模糊,一般都俗称填坑的,哪里不行顶上去。
岗位招聘案例
java架构师
1 | JAVA架构师 40-70K·15薪 |
中间件架构师
1 | 中间件架构师 30-60K·16薪 |
系统架构师
1 | 直播PaaS 系统架构师 20-40K·15薪 |
在线教育
⽀付系统、结算系统、确认收⼊体系、⼤规模统计
⾦融系统
分布式通讯框架改造、配置中⼼、⽹关、权限认证、资源保护
电商中台
部署发布体系、监控体系、中台系统规划(中台 - 去中台⽹格化 -_-!)
怎么做
清晰的技术栈
⼤纲体系 - 横向维度
架构演进课 - 纵向维度
要亲⾃动⼿梳理 - 个体差异,融会贯通,知⼰知彼
⼯具
⼀切皆是⼯具,多多益善
学会再忘掉,构建索引
语⾔本身:集合、线程、甚⾄其他语⾔ lua,shell,python
框架:spring、springboot、dubbo、netty
设计⼯具:pd,uml
版本管理:git
项⽬管理:maven,gradle
中间件: redis,mq,mongo
……
设计能⼒
设计模式 - 简单直⽩,但不要脱离应⽤
来⾃常⽤框架的设计 - 艰苦⽽漫⻓
⾃⼰尝试思索和改进 - 费脑细胞
架构思维
⽇常的经验积累和总结
知⾏合⼀,做之前,先考虑意义
原⽣优于定制,约定⼤于配置
什么都是,最后会沦落到什么都不是
控制技术欲,不要瞎折腾
留下扩展,但不要想到100年后
没有最好的,只有最合适的
够⽤就好,玩的越花,⻛险越⼤
⼤巧不⼯,简约最美
圈⼦
⼈脉很重要!
迈出第⼀步
先从0-1,再考虑100
⼏个问题
3-5年,可以做架构吗?
初级架构师,中⼩企业作为切⼊点,有试错的资本
最好的时光
架构与资深开发的区别?
基础底⼦要求基本⼀致,⼯作内容有所偏差
⾮计算机专业可以吗?
可以!
对学历有没有要求?
有影响,⾮绝对
35岁是职业终点吗?
错!看职位,还在码砖的要警惕
3-5年是转型关键阶段,要开始着⼿布局。
从体⼒类⼯作⾛向设计类、管理类⼯作
⽬标:让⼯作变的不可替代
如何卷成百万架构师
架构师成长要素
思维决定路径
- 程序=逻辑+翻译+实现
- 架构=判断+取舍+创新
架构师的定位
- 架构师是业务和技术之前的桥梁
- 架构师不能只顾技术,不懂业务,很容易两头不讨好。
- 你做出来的东西要给别人说怎么用。比如你整合了activiti,要负责给下面的开发兄弟结合业务使用。
架构师能力模型
架构师也分层级
架构设计理论基础
什么是架构
【软件架构(Software Architecture)】
指软件系统的“基础结构”,创造这些基础结构的准则,以及对这些结构的描述。
– 来自《维基百科》
为什么做架构设计?
As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system—the software architecture—presents a new set of design problems.
—-卡内基·梅隆大学,Mary Shaw,David Garlan
核心:随着系统规模的增长,数据结构和算法不再是主要问题,整个系统的结构成为首要问题
架构设计方法论
指导方法
理想VS现实
架构设计原则
架构设计原则-合适
架构设计原则-简单