我对一些技术架构设计的经验记录

软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。

背景

背景交待,设计无法脱离背景,经验偏向于中大型业务应用,重业务和落地,偏于ToB体系,也有互联网经验参合。中小型团队(比如几十到几百人)类型,会有一定的资源缺乏,偏于业务应用层面。

以前也会太过于理想化的设计,经过遇到的和接触过到很多团队,反而更加相信自己的设计,或者说每个设计师有自己的思路。

概述

接触过很多做架构设计的团队,也在架构部门(专门做SA的团队)有很多讨论,临时记录的笔记,一家之思,做一些经验参考。

在以前接触的项目中,会跟很多架构师,技术经理,总监等做过很多讨论,很多感受到的一点,在整体型的平台架构设计上,能落地的团队偏少,小的设计上往往难统一意见,很多不同经验的人员,会带来很多不一样的想法,走向极端和误区性的也比较多多,过程放弃跑路的,做到一半一半的也不是没有,有些每一两年换一个架构方向也遇到。

这里主要做一些记录过程问题,架构的方向和设计,往往会决定企业或者团队未来3-5年的发展情况,做得好,商务和市场上的配合,可能达到事半功倍的情况,做得不好,可能就是其它地方事倍功半。这里以小团队做中台化产品的一些记录,同时结合其它团队沟通和接触过程中见到问题。

  • 团队基础条件: 每个团队有自己的情况,有自己的能力,有自己的缺点,不要过分否定自己,也不要过分抬高自己
  • 规避技术成本: 不要过分的引入以为好的技术,以合适为主,以简单为主,以容易上手为主,避免过度封装
  • 规避学习成本: 尊重开发人员的习惯,尊重行业的发展现状,部分人会不代表其它人就可以,习惯自然而然最简单
  • 敢于做决策: 在没有结论或者结论自己无法把控时,相信自己的想法,即使是错的,先做,重点是要能自己把控得往
  • 顶层思维思考: 从顶层思维看问题,规避过份纠结细节,整体能正常,不追求100%,保持后面有持续优化的心态
  • 其它 ……

以上为一些或者前期遇到的,很多都会有类似的问题,来来去去围绕的很多,设计开始否定的人一般会很多,甚至很多年经验的架构师一眼就会否定,觉得都不是问题,重点是个人有没有自己否定自己的设计,是否相信自己的设计,是否可以坚持自己的设计,每个设计师有自己的思路,我有我思。

经验内容

以下为一些具体遇到的问题和场景展开的分析说明,结合实际场景遇到的情况。

团队基础条件

设计不仅仅只是设计,这里业务架构设计层面不包含

在考虑团队基础条件时,我们必须理解每个团队都有其独特的情况和能力。这包括团队成员的技术水平、工作习惯以及团队内部的协作方式。不应过分否定团队的能力,也不要过度抬高。相反,应该在现有条件下寻找最佳解决方案,并努力提升团队的整体素质。

不仅如此,还有包括后期的招聘,管理,成长,城市环境等多重因素,做好一定的预案处理,这些好像不是本身的工作或者其它部门的考虑,但是存在的风险依然会需要考虑到这块的内容点上。在非大集团的情况下,或者中小团队,或者说二三线城市,或者一线城市特殊约束,都会有各种可能性,不仅如此,还包括商务、销售、市场、营销等等符合性的设计,以渐进式的方式进行的推进。

设计岗有一点类似于不上不下的角色,但是要落地,怎么推进,沟通,向上向下管理,输出都需要精细的考虑,看似跟这个不相关的事情,但是依然会带有一定的关联,在设计层面,会尽可能考虑到因素,以确定设计可落地,以保障架构的实施和后期的发展,这些都需要考量团队的基础条件。

这并不是为其它角色或者部门考虑,而是在本身的范围里面确保自己的设计可正确的实施,到这步,某个角度上,跟技术的关联性其实还比较小。不代表没有土壤就无法种树,同样需要考虑在各个部门当前的条件下,怎么创建土壤和培育。

规避技术成本

对技术的尊重和敬畏,但是不崇拜

对技术来说,不再过度去崇拜技术,而是尊重技术,尊重它带来的成果。在很多场景上的解决能力。

很多设计人员一上来会有高并发,分布式,微服务,容器化,人工智能,或者大数据等等很多的设计名词,这些并不是在每个项目上使用得到,有大有小,有高有低,并不代表它就会使用到。其实并不代表这些新的技术就是怎么样的,主要还是建立在业务和团队基础之上,以落地为主。

后来发现,这并不是一个好的事情。新的技术引入,以选择合适为主,简单为主,比如微服务,以前会听说很多springcloud技术,还有多个变种,官方版本,阿里版本,腾讯版本 … 还有k8s版本,在前期过程中你会发现,有可能会喜欢将“好”的东西运用上去,会成为一个臃肿的设计,或者追求各类型的过度封装,觉得这样会给开发过程带来很多方便。优劣好坏某个角度来说,很难区分,怎么选择。

后面发现,过重的微服务设计,使用的东西并不多,过多的设计理念,过分的封装,会带来后期很多无用的成本,后面的设计将springcloud组件能去掉的就去掉,保留最基础的springboot版本,其它按需引入,将非业务下沉到PaaS层,能轻量就轻量。

规避学习成本

尊重习惯的同时改变习惯

推行新的设计,以前很多情况下会走一到两个项目或者前期小团队试行,以积累后带大团队进行,这是一个常用方式之一。但是在不断的接触和积累过程中发现,这部分的成本也是非常大的,包括时间成本,学习成本,培训成本等。有时候需要找到新的血液进入,这个就更不用说了,周期往往一来就是半年以上,团队完全消化,甚至有可能1-3年。

尊重开发人员的习惯和行业的发展现状是至关重要的。虽然部分人的习惯可能不符合我们的预期,但我们应该尽量与之和谐相处,避免强行改变。同时,我们也应该意识到行业技术的更新迭代是不可避免的,但不是所有新技术都值得投入大量时间和精力学习。应该谨慎选择学习的方向,以避免浪费时间和资源。

效能工具方面,新的设计应该带来更好的效能,更好的减少学习成本。假如说将工作比作开车,前期可能大家习惯的手动档,在新的设计上,应该是提供出自动驾驶,或者自动档,依然是开车,提供更好的工具,以确保习惯的同时,提供更好的工具,在后期转变过程中,通过工具升级进一步的升级习惯,在过程中进行转换。

敢于做决策

决策有对跟错,没有决策往往是最大的错

前期带过很多Leader型的角色,新Leader有的时候,不太敢于做决策,包括我自己也一样,没做过,别人也没有类似场景,在决策时心理会有多个打鼓点。

在后面发现,在面对没有明确结论或自己无法完全把握的情况下,我们必须敢于做出决策。尽管决策可能是错误的,但关键是要相信自己的想法,并且能够承担后果。即使决策出现问题,也可以从中学到经验教训,并不断优化和改进。

这个的效果会带来一些误伤,但是错误和修正的成本相比于没有明确决策成本,会更大,而且后期成本相当隐形。

以前在做一个SaaS型平台产品,有上百个基线,同类的设计场景团队有时候也没遇到,但是先走,错了就调整,做好风险把控,结果在半年时间产品成型,形成团队转型基础,当时3个月出演示,半年成产品,后面都是接入项目。对比另一个公司团队也在做,2年基础版本才刚刚体现,基本上很难跟上市场和行业发展。设计 在决策上很多时候(注意是很多不是所有)不怕出错,就怕没有结论。

顶层思维思考

从顶层往下看,规避一叶障目

遇到的,不管是哪类型的设计,即使考虑是最好的,是减轻或者有利的团队或者发展的,依然很难达到100%的愿景目标。

这类型问题出现比较多的情况在于细节性的体现,管理太细或者太粗都不太合适,需要适当的下发权限,在一定的规则范围内,形成一定的容错性。在一开始的时候,同样也会纠结很多细节,这个不好那个不对,过分的追求理想化,常常导致的消极的反噬。

在设计时,从顶层思维看问题,避免过分纠结于细节。重要的是要确保整体系统能够正常运行,并且有一定的容错和恢复机制。不应也不要(以前可能犹豫,现在是明确不要)追求完美,而是要保持持续优化的心态,随着系统运行和需求变化,不断进行调整和改进。

高工跟设计的思考区别会比较明显,特别在处理在高工阶段的时候,这也没有问题,但是在设计层面,更多的思考全局性的,保持良好的扩展和耦合管理机制,在之前遇到的,先能用,最坏的就是模块重构一下。

总结

以上是前期设计的一些经验,可能会跟遇到的理想化或者架构模式会有一定的区别,但是总的来说,是过程遇到的问题和一些经验记录,期望给一些同学进行参考。

在设计架构时,应该注重适应实际情况,避免过度追求新技术和复杂解决方案。尊重团队成员的能力和习惯,勇于做出决策,并确保系统具备一定的容错和风险保障机制。通过不断总结经验,并持续优化改进,实现架构设计的有效落地和业务发展的持续增长。

注:文章图片由讯飞星火大模型生成