我对架构定义的理解
大概在7~8年前,我曾经有一个美国对口的架构师导师,他对我讲架构其实是发现利益相关者(stakeholder),然后解决他们的关注点(concerns),后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》,里面提到的理念也是这样说:系统架构的目标是解决利益相关者的关注点。
这是从那本书里头的一张截图,我之前公司分享架构定义常常用这张图,架构是这样定义的:
每个系统都有一个架构
架构由架构元素以及相互之间的关系构成
系统是为了满足利益相关者(stakeholder)的需求而构建的
利益相关者都有自己的关注点(concerns)
架构由架构文档描述
架构文档描述了一系列的架构视角
每个视角都解决并且对应到利益相关者的关注点。
架构系统前,架构师的首要任务是尽最大可能找出所有利益相关者,业务方,产品经理,客户/用户,开发经理,工程师,项目经理,测试人员,运维人员,产品运营人员等等都有可能是利益相关者,架构师要充分和利益相关者沟通,深入理解他们的关注点和痛点,并出架构解决这些关注点。
架构师常犯错误是漏掉重要的利益相关者,沟通不充分,都会造成架构有欠缺,不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的,比如管理层(可管理性)vs技术方(性能),业务方(多快好省)vs 技术方(可靠稳定),这需要架构师去灵活平衡,如何平衡体现了架构师的水平和价值。
关于架构的第二点定义是说架构主要关注非功能性需求(non-functional requirements),即所谓的-abilities。
这个是我上次公司内分享的一个图。
这个是slideshare一个ppt里头截取的,两个图都是列出了架构的非功能性关注点;关于架构的水平该如何衡量,去年我看到一句话,对我影响很大。
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
翻译为中文就是,架构表示对一个系统的成型起关键作用的设计决策,架构定系统基本就成型了,这里的关键性可以由变化的成本来决定。这句话是Grady Booch说的,他是UML的创始人之一。
进一步展开讲,架构的目标是用于管理复杂性、易变性和不确定性,以确保在长期的系统演化过程中,一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷,让应用的易变部分能够频繁地变化,对应用的其它部分的影响尽可能的小。
我刚入软件开发这个行业之初,谈的架构主要是性能,高可用等等。现在,见过无数遗留系统,特别是国内企业IT的现状,无数高耦合的遗留系统,不良的架构像手铐一样牢牢地限制住业务,升级替换成本非常巨大, 所以我更加关注可理解,可维护性,可扩展性,成本 。我想补充一句,创业公司创业之初获得好的架构师或技术CTO非常重要。
架构的迭代和演化性
我是属于老一代的架构师,99年参加工作。职业初学了很多RUP,统一软件过程的理念。RUP的理念对我的架构有很深的影响,RUP总结起来就是三个特点:
用例和风险驱动Use Case and risk driven
架构中心Architecture centric
迭代和增量Iterative and incremental
RUP很注重架构,提倡以架构和风险驱动,项目开始一定要做端到端的原型(prototype);通过压测验证架构可行性,然后在原型基础上持续迭代和增量式开发,开发->测试->调整架构->开发,循环,如下图所示:
从上图可以看出架构师要尽可能写代码,做测试,纸上谈兵式做架构而后丢给团队的作法非常不靠谱(除非是已经非常清晰成熟的领域)。另外,做技术架构的都有点完美主义倾向,一开始往往喜欢求大求全,忽视架构的演化和迭代性,这种倾向易造产品和用户之间不能形成有效快速的反馈,产品不满足最终用户需求,继续看下面两个图:
第一个图是讲最小可用产品(Minimum Viable Product, MVP)理念,做出最小可用产品,尽快丢给用户试用,快速获取客户反馈,在此基础上不断迭代和演化架构和产品。
第二个图是过度工程(Over Engineering)的问题,其实也是讲产品架构和用户之间没有形成有效的反馈闭环,架构师想的和客户想的不在一个方向上,通过最小可用产品,快速迭代反馈的策略,可以避免这种问题。
注意,在系统真正地投入生产使用之前,再好的架构都只是假设,产品越晚被使用者使用,失败的成本和风险就越高,而小步行进,通过MVP快速实验,获取客户反馈,迭代演化产品,能有效地减少失败的成本和风险。
在这里顺便给大家推荐一个架构交流群:650385180,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。相信对于已经工作和遇到技术瓶颈的码友,在这个群里会有你需要的内容。
另外,多年的经验告诉我,架构,平台不是买来的,也不是用一个开源就能获得的,也不是设计出来,而是长期演化才能落地生根的。
构建闭环反馈架构
先分享一个链接,这几年对我架构影响最深的一篇文章。这篇文章是关于DevOps的,但对系统架构同样适用:
-
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
这篇文章讲述了企业通向DevOps的三条必经之路,我们来看看这三条道路对架构师的启示。
第一条道路,系统思维,开发驱动的组织机体,其能力不是制作软件,而是持续的交付客户价值,架构师需要有全局视角和系统思维(System Thinking),深入理解整个价值交付链,从业务需求、研发、测试、集成,到部署运维,这条价值链的效率并不依赖于单个或者几个环节,局部优化的结果往往是全局受损,架构师要站在系统高度去优化整个价值交付链,让企业和客户之间形成快速和高效的价值传递。
第二条道路,强化反馈环,任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师,也是中国学生的普遍问题,就是生产运维意识不足(监控是系统反馈的重要环节)。有两句话是这样讲的:
no measurement, no improvement没有测量,就没有改进和提升
What your measure is what you get你测量什么,就得到什么
没有监控或者监控不完善的系统相当于裸奔,开车上高速无仪表盘。有一篇很不错的关于测量驱动开发的文章,在InfoQ上的,向大家推荐:
-
http://www.infoq.com/cn/articles/metrics-driven-development
这篇文章提出了度量驱动开发的理念,即所谓MDD,在系统,应用和业务三个层次,通过三级监控,构建三个反馈环,在监控测量基础上持续改进系统和架构,我最近也在参考这个理念设计一个电商平台的技术架构,见下图:
这是一个电商平台的架构,整个体现了闭环架构的思想,右侧是