月度归档:2024年03月

我在产品研发中用到的基础设施工具

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

背景

内容针对的是社区产品建设新人切入的指导性思路,目标是打开自我思维,有基础,能设计,能思考,能实践,会自我价值体现。合理利用社会资源工具,将时间和精力放在最有价值的地方,创造价值,提升价值。

产品是以开源状态进行开发管理,当前社区团队在接纳新人,有部分还是大二大三学生,有一些可能没有接触过设计体系这块,考虑更系统的体现基础层,这里进行阐述说明。针对于新人来说需要一些方向的引导,以快速的进入状态,跟上梯度成员,便于他们有方向的成长和学习方向,也是规避迷茫,缺少方向感,导致负面和误导,消耗无谓的时间。

当前维护的社区团队非常小,还是兼职,自动化和低成本的基础设施对团队来说,会比较看重,应用最少的人力去维护好产品,同时为了更方便的办公。工具的使用,可以让新人和加强的技术理解、架构思维、使用场景、解决能力、还有方案输出等能力。

设施包含

这里的基础设施工具,主要是使用开源和常用的SaaS化工具来进行平台产品研发的管理,以减少成本和学习路线,可以有大量的学习内容让团队可以快速解决问题,如下图中的这张架构内容。

基础层主要是包括【基础设施、代码级、模块层、应用级】,这个主要是基础环境设施,上面系统级主要是软件服务应用。在基础层,基本上使用的都是免费工具类型,包括免费服务器,免费的DevOps套件、免费的代码检测、安全检测等。每个人都可以使用,开个账号就可以学习,可以使用一些效能工具更快的提高自己的效率。

有一部分是现成的,有另一部分的自己设计的,总的来说,类似于PaaS层,但是又高于PaaS层,最大化的贴近于应用层,以减少底层的建设,确定好规范之后,外加GPT的加持,会更加提高效率和输出服务能力。

这里主要的内容包括几个主要部分:

  1. 基础PaaS层:阿里云ECS服务器、Kubernetes、阿里云ECS网络安全、阿里域名
  2. DevOps套件:Github、GithubAction、阿里云效Maven私服、阿里云ACR镜像
  3. 中间件层:Redis、阿里云MySQL、七牛云存储、Clickhouse存储、Kafka消息、Nacos等
  4. 基础服务层:Infra核心包、Infra单点登陆、Infra代码生成器、Infra权限引擎、Infra网关服务等
  5. 质量管理层:SonarCloud、GithubSecurity、墨菲安全、ApiFox
  6. 自动化层:GithubAction、Ansible
  7. 项目管理层:阿里云效项目管理、阿里钉钉、WPS、腾讯会议
  8. 项目预警层:Prometheus、Ansible、阿里钉钉
  9. AI智能层:Hugging face、百度飞浆、阿里云AI系列
  10. 数据治理层:阿里云DataWorks、Infra数据治理套件
  11. LLM大模型层:ChatGPT、星火大模型、百川AI、Infra智能体服务

这些大部分社区工具和云服务平台,作为入门的基础内容,难度系数并不高,要求只是基础能接入使用就可以,另一部分是基础架构里面进行补充的内容(以Infra开头),这些都提供出对应的接口和使用说明文档。当中有一部分会混着用,比如数据治理层,后期做为平台型产品会做一些场景进行针对性替代的研发。

上面这些,在这进里统一规划层基础设施层,这些会考虑使用低成本的方式去运营管理,方便产品的正常开发和演示运营,同时确保可以新人更好的针对性的自我学习。

学习路线

在工具选定之后,针对新人来说,怎么接触练习,这个可能来说,先对比较简单一些,对于线上可以注册的工具,基本可以自己学习就可以,学习主要通过以下路线,先熟悉工具,在进行应用层服务的开发。

学习路线主要是下面:

  1. 了解开源工具:账号的注册和示例的学习,了解这个工具是做什么的。
  2. 了解服务能力:了解Infra组件提供的基础能力有哪些,怎么使用当前的服务模板。
  3. 熟悉研发流程:了解产品的项目管理流程,敏捷开发流程,知道从哪步到哪步。
  4. 创建服务能力:能根据需求自主创建出服务并提供出服务能力,价值体现。

学习工具主要是了解怎么使用,这里使用的层面就是自己注册跟学习了,然后自己关联自己的demo进行学习。这个过程看个人,不合适人员并不会要求往下,合适人员接触起来,其实也比较容易,大部分就是看教程或者视频操作。

这也是进入产品维护的一个简单门槛,基本工具使用的还是helloworld级别,深入会过程再慢慢沉淀这样。在长期接触过程中,其实大部分场景都是可以满足,即使不满足,也不会达到多难的程度。

这里除了编码层面的,其他都是自动化,编写一套之后,留着自动任务执行就可以,根据预警情况,看是否需要处理,其他的,出问题再需要人工介入。

编码层面的,这里主要是通过结合代码生成器,GPT和定制的Prompt来进行,因为是产品型和服务型应用,逻辑还是先出一般本,先可以看到,然后后续根据产品功能,进一步的完善。先用起来为主,这部分对一般没怎么接触过的人员,先做一个功能就可以上手,因为规范都统一化,这些入门成本会比较低,参考着复制粘贴就可以。

另外就是Agent智能体服务的,这个整合起来就是调用GPT的接口外加基础服务的接口,当然,这个需要一些规范,前期已经解决了这个问题,目前主要是根据规范,结合工具API接口写Agent插件就可以,集成架构也已经集成。

能力输出

这部分重点还是在需求和设计上面,到进入服务输出来说,到这步已经很容易了,服务能力的输出,才是最贴近业务层的,这里会把精力放在这块上面,时间成本最大的,也是在这块上面。这部分可以花时间在需求和设计上面,后期通过AI编程和微调整来实现,另外就是参考其它网上代码或者开源项目。

自我能力提升,还有AI的引用也是在这块上,这块要考虑的编码,但是更多的期望可以使用现成的代码,可以复制或是开源的,符合的拿过来就可以,没有的,使用GPT协助建设也可以。这部分偏于码农路线,但是我们能做但是不代表一定需要做。

时间精力放在优化,某个框架深入,思维的理解,场景的运用,解决方案沟通上,这个是目前团队特别关注也是重视的。

总结

上面是当前产品研发过程中,使用的基础设施工具,有部分是使用现成的,有部分是结合开源项目进行的研发,有部分是自主开发,通过设计整合起来的基础设施能力,为上层服务建设提供良好的条件,也可以让新人更专注于场景解决方案和业务能力分析设计上面。

这里提出了一套基于开源工具和社区资源的学习和实践方法,强调了基础设施、代码级、模块层、应用级的基础知识,以及使用免费或低成本的工具和服务的重要性。并给出了一个学习路线,包括了解开源工具、了解服务能力、熟悉研发流程和创建服务能力等步骤。强调了能力输出的重要性,包括业务能力、AI引用、编码能力、优化能力、框架深入理解、思维理解和解决方案沟通等方面。

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

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

背景

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

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

概述

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

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

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

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

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

经验内容

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

团队基础条件

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

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

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

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

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

规避技术成本

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

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

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

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

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

规避学习成本

尊重习惯的同时改变习惯

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

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

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

敢于做决策

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

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

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

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

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

顶层思维思考

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

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

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

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

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

总结

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

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

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