ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 665|回复: 0

不同架构师的视角及心得!

[复制链接]
发表于 2022-6-21 11:17:13 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-6-21 11:23 编辑
2 X9 i# |# }% N* e+ s, K2 |* X5 s1 G. U( K" m
ITIL

+ Q) a; t! _  [4 `4 U
本文分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前的工作过的公司eBay、携程、唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样,可以说一万种眼光,有业务架构、安全架构、平台架构、数据架构,各不相同,这里仅是我的一家之言,欢迎大家参与讨论。
9 _4 I5 ^/ `" ?# C* u! o- B0 K
今天聊的话题主要包括以下几点:
  • 我对架构定义的理解
  • 架构的迭代和演化性
  • 构建闭环反馈架构(Architecting for closed loop feedback)
  • 谈谈微服务架构和最新主题
  • 架构和组织文化关系
  • 架构师心态和软技能
  • 我对一些架构师争议主题的看法
    0 j+ m) P* i6 h7 Q

    $ v  U) W2 }) M5 o; Z8 K$ O

2 c) |9 w& M, L% X5 ]: x
一、我对架构定义的理解
8 [- _. ?! G8 N4 G, m
大概在7~8年前,我曾经有一个美国对口的架构师mentor,他对我讲架构其实是发现利益相关者(stakeholder),然后解决他们的关注点(concerns),后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》,里面提到的理念也是这样说:系统架构的目标是解决利益相关者的关注点。
0 b- l- B) A; q) c: L
粘贴上传202206211118587124..png
9 }% c: ?8 o0 G7 F6 p% @
这是从那本书里头的一张截图,我之前公司分享架构定义常常用这张图,架构是这样定义的:
  • 每个系统都有一个架构
  • 架构由架构元素以及相互之间的关系构成
  • 系统是为了满足利益相关者(stakeholder)的需求要构建的
  • 利益相关者都有自己的关注点(concerns)
  • 架构由架构文档描述
  • 架构文档描述了一系列的架构视角
  • 每个视角都解决并且对应到利益相关者的关注点。
    , l+ }5 ~0 x4 c) e7 s$ w

' _% \7 v+ E' k% s9 E: ?1 r
架构系统前,架构师的首要任务是尽最大可能找出所有利益相关者,业务方,产品经理,客户/用户,开发经理,工程师,项目经理,测试人员,运维人员,产品运营人员等等都有可能是利益相关者,架构师要充分和利益相关者沟通,深入理解他们的关注点和痛点,并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者,沟通不充分,都会造成架构有欠缺,不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的,比如管理层(可管理性)vs技术方(性能),业务方(多快好省)vs 技术方(可靠稳定),这需要架构师去灵活平衡,如何平衡体现了架构师的水平和价值。

7 O, W) X1 g. I8 f$ H8 K
关于架构的第二点定义是说架构主要关注非功能性需求(non-functional requirements),即所谓的-abilities。

% C+ G4 e7 h: ^4 N/ _: U- C
粘贴上传202206211119212862..png

: j/ ?( M' n( }8 D! s5 q" z8 ?% k这个是我上次公司内分享的一个图。
' z4 f2 t4 i9 m6 l6 k
8 ~. C" I( _* y3 {; {) G9 ]) T$ \0 p
粘贴上传202206211119352043..png

9 r) z3 a  G& ?5 e& ~0 |% `
' ^! c' L! g* ?$ j+ a" G
这个是slideshare一个ppt里头截取的,两个图都是列出了架构的非功能性关注点;关于架构的水平该如何衡量,去年我看到一句话,对我影响很大。

; ]; n: Q1 j9 K# b# h' ~8 `+ ^
Architecture represents the significant design decisions that shape a system, wheresignificant is measured by cost of change.
, O8 C! p# F. s& I4 G4 \- i: u. \
翻译为中文就是,架构表示对一个系统的成型起关键作用的设计决策,架构定系统基本就成型了,这里的关键性可以由变化的成本来决定。这句话是Grady Booch说的,他是UML的创始人之一。7 F9 e3 I8 u+ e9 i3 r" E/ L3 q4 n

/ A, e( f& U0 {9 D
进一步展开讲,架构的目标是用于管理复杂性、易变性和不确定性,以确保在长期的系统演化过程中,一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷,让应用的易变部分能够频繁地变化,对应用的其它部分的影响尽可能地小。

3 j8 c! K8 S# Z4 S6 d3 x' Z& K
我刚入软件开发这个行业之出,谈的架构主要是性能,高可用等等。现在,见过无数遗留系统,特别是国内企业IT的现状,无数耦合性系统的遗留系统,不良的架构象手铐一样牢牢地限制住业务,升级替换成本非常巨大, 所以我更加关注可理解,可维护性,可扩展性,成本 。我想补充一句,创业公司创业之初获得好的架构师或技术CTO非常重要。

! O- _& ]. V- F- C
二、架构的迭代和演化性

5 U1 C' F: a  P/ G) T; F
我是属于老一代的架构师,99年参加工作。职业初学了很多RUP,统一软件过程的理念。RUP的理念对我的架构有很深的影响,RUP总结起来就是三个特点:
  • 用例和风险驱动Use Case and risk driven
  • 架构中心Architecture centric
  • 迭代和增量Iterative and incremental

    # h  J3 s5 R; Y0 I7 L
RUP很注重架构,提倡以架构和风险驱动,该开始一定要做端到端的原型prototype;通过压测验证架构可行性,然后在原型基础上持续迭代和增量式开发,开发->测试->调整架构->开发,循环,如下图所示:
1 x& d2 O- V( L6 I
粘贴上传202206211119548568..png

, G( B* d8 W7 u7 z2 @" Y( ~
& C( \  g4 y$ x0 C2 K" d0 E
从上图可以看出架构师要尽可能写代码,做测试,纸上谈兵式做架构而后丢给团队的作法非常不靠谱(除非是已经非常清晰成熟的领域)。另外,做技术架构的都有点完美主义倾向,一开始往往喜欢求大求全,忽视架构的演化和迭代性,这种倾向易造产品和用户之间不能形成有效快速反馈,产品不满足最终用户需求,继续看下面两个图:) s5 G  F0 j$ j" f1 h
, q( [  {+ L9 x3 Z
粘贴上传202206211120169358..png
3 u8 J8 J) p( Q/ d1 {

5 x4 c2 J' y9 C  Q
3 c# Y3 v" \$ z. r
第一个图是讲最小可用产品(Minimum Viable Product, MVP)理念,做出最小可用产品,尽快丢给用户试用,快速获取客户反馈,在此基础上不断迭代和演化架构和产品。第二个图是过度工程(Over Engineering)的问题,其实也是讲产品架构和用户之间没有形成有效的反馈闭环,架构师想的和客户想的不在一个方向上,通过最小可用产品,快速迭代反馈的策略,可以避免这种问题。注意,在系统真正地投入生产使用之前,再好的架构都只是假设,产品越晚被使用者使用,失败的成本和风险就越高,而小步行进,通过MVP快速实验,获取客户反馈,迭代演化产品,能有效地减少失败的成本和风险。
" L% ^( z% a! z6 B" I
另外,多年的经验告诉我,架构,平台不是买来的,也不是用一个开源就能获得的,也不是设计出来,而是长期演化才能落地生根的。

  \  K4 n# w0 q6 c: w$ `( a
三、构建闭环反馈架构

. C3 H! W) d) a3 h
粘贴上传202206211120314418..png
! E% z. V( y4 s9 o! ~( N4 J
第一条道路,系统思维,开发驱动的组织机体,其能力不是制作软件,而是持续的交付客户价值,架构师需要有全局视角和系统思维(System Thinking),深入理解整个价值交付链,从业务需求、研发、测试、集成,到部署运维,这条价值链的效率并不依赖于单个或者几个环节,局部优化的结果往往是全局受损,架构师要站在系统高度去优化整个价值交付链,让企业和客户之间形成快速和高效的价值传递。

9 G" q! p# C+ N  x/ y
粘贴上传202206211120489132..png

- K. v% t5 W- ]+ A  \, ~) {+ s
3 P3 t  h3 k3 c+ ]( ]; }8 H
聊聊架构第二条道路,强化反馈环,任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师,也是中国学生的普遍问题,就是生产运维意识不足(监控是系统反馈的重要环节)。有两种化这样讲的:
  • no measurement, no improvement没有测量,就没有改进和提升
  • What your measure is what you get你测量什么,就得到什么

    5 x! A  l0 y* g1 e% T- H5 X
没有监控或者监控不完善的系统相当于裸奔,开车上高速无仪表盘。

3 J, Q0 ?. d, x8 p
度量驱动开发的理念,即所谓MDD,在系统,应用和业务,通过三级监控,构建三个反馈环,在监控测量基础上持续改进系统和架构,我最近也在参考这个理念设计一个电商平台的技术架构,见下图:
  a9 w% O7 Z3 d: B+ ~( I
粘贴上传202206211121099707..png
0 l( C, m/ x# o
) a  c1 f) |$ D9 U
这是一个电商平台的架构,整个体现了闭环架构的思想,右侧是整个平台的反馈监控环节。具体如下:
  • 系统层监控计算网络存储,构建系统层的反馈环
  • 应用服务层,监控业务、应用、服务,甚至整个研发流程,构建应用和服务层的反馈环
  • 客户体验层,监控端用户和分析网站用户的行为,构建和客户的反馈环

    9 }  b, Z( M8 H' ]1 J
下面这个图展示了系统提升和改进的一般方法:
- Z! w1 r: H. \5 i/ |: f2 k  Z
粘贴上传202206211121279857..png

3 ]. q9 d* X7 V# u) M
% F7 v8 u; `  m. G  D% L
收集->测量->调整->闭环重复,在有测量数据和反馈的基础上,系统、应用、流程和客户体验才有可能获得持续的提升和改善,否则没有数据的所谓改进只能靠拍脑袋或者说猜测。
' f9 ~1 q+ p- }4 s0 f
粘贴上传202206211121456814..png

% J7 h. P* [' S0 t

/ C0 G& i: r  g7 ~+ Y# Z
第三条道路,鼓励勇于承担责任,冒险试错和持续提升的文化。这点是最难的,一般和企业人才密度有关。工具,技术,流程只是一个公司的冰山浮出水面的部分,而真正对企业效能影响大的则是冰山水下的部分,即企业的人和文化,架构师作为技术和架构的布道者,有责任义务鼓励和推动试错文化。
架构师要深入领会这三条道路,关注整个价值交付链的效率,关注每个环节的闭环反馈,鼓励和推动公司的试错文化,打造全系统的闭环架构(Architecting for closed loop feedback),提升整个系统效能。下图的DevOps和每日交付是每一个互联网系统架构师的梦想和努力的方向。

% \& `! Q& i2 w" d- [3 }1 h  q
粘贴上传202206211122207692..png
9 X: n. E. G7 b4 N. X

1 C' C) U; _4 K# F: k- _
四、谈谈微服务架构微服务
; A* I2 \0 A) N
我想大家都听得很多了,我本人也非常关注和推崇微服务,从技术角度讲,我认为微服务主要体现的是单一职责和关注分离的思想,从单进程模块化进一步拓展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元,正如我在第一点架构定义中提到的,微服务中每个服务可以独立演变,它的cost of change比较小,整体架构比较灵活,是一种支持创新的演化式架构。
1 E) s2 z& X' {
粘贴上传202206211122379725..png
0 p. M# r- Q0 n3 {6 ]$ o  s0 r
% s8 S) U, M: s0 V% }
这个图讲什么时候该引入微服务。微服务有额外成本的,需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素系统复杂性和团队规模,当到达一个点,单块架构严重影响效率才考虑 。另外补充一点,微服务更多是关于组织和团队,而不是技术。

. C  j- k6 H: _! E& g
五、架构和组织文化关系
2 `! k% h5 ^% a' q6 @4 S1 E& {
再谈一下康威定律:
# Q/ L( `' X7 i8 t1 A1 ?7 r
Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
(设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。)
4 p: o) A& Q  ^: [/ j5 \* E/ I
从单块架构到微服务架构是这个定律的很到体现。
- I" o7 j( r) R, Q% h0 ~: B3 E
粘贴上传202206211122566065..png
- O! M# b: r1 P" r+ g
4 L* c: {" i3 X) m. X6 X& I+ z
团队是分布式的,系统架构是单块的,开发,测试,部署协调沟通成本大,严重影响效率,严重时团队之间还容易起冲突conflict。
+ V: r) C# ~  `; ^8 F) E
粘贴上传202206211123103741..png

! k% _+ X# N) q) f
将单块架构解耦成微服务,每个团队开发,测试和发布自己负责的微服务,互不干扰,系统效率得到提升。
9 A$ K$ g! i3 f. }6 G6 e
可见,组织和系统架构之间有一个映射关系(1 ~ 1 mapping),两者不对齐就会出各种各样的问题,一方面,如果你的组织结构和文化结构不支持,你也无法成功建立高效的系统架构,例如集中式和严格职能(业务, Dev, QA, Deployment, Ops)的企业,很难推行微服服务和DevOps,推行Docker/PaaS平台也会比较困难,这样的组织职能之间都倾向于局部优化(local optimization),无法形成有效和合作和闭环。

$ V5 f- s& a- l
反过来也是成立的,如果你的系统设计或者架构不支持,那么你就无法成功建立一个有效的组织;作为系统架构师,一定要深入领会康威定律,设计系统架构之前,先看清组织结构,也要看组织文化(民主合作式,集权式,丛林法则式,人才密度),再根据情况调整系统架构或者组织架构。
& S- w% T; }0 ]" ~/ ~
六、架构师心态和软技能
: x) H8 O( `% w
空杯,或者说开放心态(open minded)是一个成熟架构师的应有心态,stay hungry, stay foolish, 心态有多开放,视野就有多开阔。来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师 :
如果一位具有相当聪明才智的人跟我意见不同,那么对方的主张必有我尚未体会的奥秘,值得加以了解。与人合作最重要的是,重视不同个体的不同心理、情绪与智能,以及个人眼中所见的不同世界。与所见略同的人沟通,益处不大,要有分歧才有收获。
. B" j$ c- E2 T
另外再推荐一个本书《软件架构师的12项修炼》,这书中三个观点很值得每个架构师学习领会:
7 W6 p5 |* G5 V) G" g' X
  • soft skills are always hard than hard skills,软技能比硬技能难
  • choosing relationship over correctness ,注重关系重于谁对谁错
  • 架构的政治性,在中大型公司里混的架构师尤其要学习
    : [9 U6 a  t3 c
政治指的是和他人协作将事情搞定的艺术,架构是一种社交活动,在技术的世界里,个人主义很容易被打败,即使你的目的是好的技术是最优的,技术决策是政治决策(technical decisions are political decisions),一个技术产品,一波人可以做,另一波人也可以做,到底谁做的好,真不好说,不管谁做,都给业务套上了一副手铐。
架构师如何提升?实战,实战,实战!规划职业,找好的团队和项目,总结分享,学习GitHub开源项目,尽可能参与和开创自己的开源项目和产品,并长期积累。
: l' H3 j6 _( B( L3 n
七、我对一些架构师争议主题的看法
! `6 p+ U1 P4 v6 v$ E& B+ Q% N
主要争议是两个话题:
  • 技术和业务的关系。
  • 架构师要写代码吗?
    8 i& z6 R6 n! B4 [! t! z- a$ P
架构师怎么回答这类问题?一个成熟架构师的口头禅:视情况而定,不一定,是也不是,it depends。技术和业务,架构师要理解业务吗,看产品和客户,如果是业务性产品,肯定要理解业务,如果是技术型产品,就不一定。
架构师要写代码?也不一定,个人觉得尽可能要写,如果你写过十年以上代码了,每年不少于2万行,都玩通了,可以不写。另外架构师如果写代码,要把控度,不要一头钻入代码,花大量时间解决细节和复杂性问题,忽视全局和系统性问题。(转自杨波)

* t$ U: j+ c) y- R' H" F$ B6 ?2 D5 S9 t4 \2 j
+ Y' q* `& p5 n/ M" N




上一篇:拥抱科技,双模IT成为了过去式?
下一篇:如何做好项目风险控制,避免项目延期?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2023-3-22 17:23 , Processed in 0.169365 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表