架构实战体会,结合《蔡学镛:架构的5个观察角度》
架构是结构化的表征,结构重在看 ,会看才能发现其中的别有洞天之美。研究物理结构常常说:“横看成岭侧成峰,远近高低各不同”,通过不同的视角,会有不同的表征,如俯视图、正视图、侧视图,我们会有抽象思维能力(刻意练习),快速形成空间抽象图像。
软件架构也是同样的思考方式,需要能够通过多视角观察,才能体会其门道,才能体会架构之美。在我日常的实战中,更多的是关注业务架构(需求)——>产品架构(功能、结构、行为)——>技术架构——>组织架构。重点说一下组织架构,基于架构师的职责应该是技能完成好设计,又能灵活利用资源完成架构的落地,因此我在做产品、技术架构的同时,比较喜欢近一步考虑人员结构,如何让人员的能力与软件架构的工作形成较好的匹配,来顺利的完成架构的实现。以上是软件建设过程的组织架构。随着软件的建设,软件与业务相结合,从康威定律的理解,软件结构会影响组织架构,运行态的软件一定是与维护组织结构有良好的映射,如果不能建立很好的映射,就会面临架构的落地困难问题。
在阅读本文后,对于数据架构、网络架构我接触较少,可能是跟项目属性偏业务更多有所关系,或者我更愿意将数据架构和网络架构放在技术架构中考虑,当然这才建设期数据和网络是技术的重要组成部分,但是站在业务或者运行态的视角考虑,数据架构一定很重要,站在运维视角考虑,网络与部署架构则更加重要。由此可得出一个结论,架构有众多视角,但是更重要的关注什么视角,取决于你的角色,根据角色(业务、技术、运维……)而选择观察关注的侧重点。
文章对于架构观察视角的分类有:鸟瞰架构、剖面架构两个维度,剖面有可以有横剖、侧剖,鸟瞰相对更加宏观,更加能表达蓝图,剖面体现内部结构,体现细节,我对微服务架构的理解其实也是类似的思考,微服务=微服务节点+微服务关系,微服务是一个宏观架构-鸟瞰,节点+关系便是一种图结构的剖面关系,微服务节点有其功能特性也有其内部剖面结构。同样对于微服务,其实可以近一步谈数据架构、领域设计架构、安全架构、网络架构等,这些也是微服务在不同视角下的剖面架构。
文章关于应用系统的分层也有所启发,文章分为:UI、应用、框架、服务、核心、驱动、数据,感觉这个可能是过去架构的最佳实践,首先按应用层和核心层可以分为应用层包含UI、应用、框架、服务;核心层包含核心、驱动、数据,对于核心业务和数据之间架设的驱动层,可以将业务与数据解耦,而让驱动层变为可拔插的架构,数据库这么多年便是这样干的。核心层与应用层的区分可以参看操作系统,内核态和应用态,通过内部接口进行衔接。服务指围绕一些核心业务的功能封装,属于中台性质,一般服务之上是应用,应用是面向业务场景的特性化封装,但是我们可以在之间架设框架层,可以近一步抽象变化,提升服务适应业务场景的开发效率。相对简单指页面层。
以上是结合文章与日常架构工作的一些思考理解,架构谈来谈去,还是从不同的视角理解结构,以形成准确清晰的结构抽象。
参考文章:蔡学镛:架构的5个观察角度
https://mp.weixin.qq.com/s/Co-5ZafexBhd1aYSnfEWDw