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

背景

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

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

概述

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

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

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

• 团队基础条件: 每个团队有自己的情况，有自己的能力，有自己的缺点，不要过分否定自己，也不要过分抬高自己

• 规避技术成本: 不要过分的引入以为好的技术，以合适为主，以简单为主，以容易上手为主，避免过度封装

• 规避学习成本: 尊重开发人员的习惯，尊重行业的发展现状，部分人会不代表其它人就可以，习惯自然而然最简单

• 敢于做决策: 在没有结论或者结论自己无法把控时，相信自己的想法，即使是错的，先做，重点是要能自己把控得住

• 顶层思维思考: 从顶层思维看问题，规避过份纠结细节，整体能正常，不追求 100%，保持后面有持续优化的心态

• 其它 ……

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

经验内容

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

团队基础条件

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

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

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

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

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

规避技术成本

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

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

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

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

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

规避学习成本

尊重习惯的同时改变习惯

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

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

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

敢于做决策

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

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

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

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

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

顶层思维思考

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

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

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

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

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

总结

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

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

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