一、平台架构的认识

1、平台架构是用来促进发展的

1）、促进企业发展

很多软件企业在发展过程中，为了更好地规范开发过程、组织团队合作、聚集技术力量、推动攻关突破、加强功能重用、促进项目水平、提升应对能力等，成立了各自的技术组、架构组、系统组、支撑组、平台组，形成了各自的过程规范、技术方案、公用功能，乃至开发构架和产品平台，希望集中技术力量、优化过程管理、整合能力资源，以促进产品项目交付过程的系统化、规范化和可量化。

这既是平台架构产生的原因，也说明大家都想通过产品平台或技术构架，来提高自身的生产力和生产效率，为企业发展提供助力。

2）、解决企业瓶颈诉求

在软件开发过程中，总会遇到一些类似的问题，比如工期评估偏差大、技术方案差别不一、技术问题不好解决、公共功能多种实现、文档资料残缺不全、特定人员依赖较重、代码质量参差不齐、工作交接难度很大、技术资产难以留存等问题，这些问题影响或制约了企业的项目能力、开发效率、过程控制、质量管理等工作，甚至因为人员变动等原因，导致其工作无人能接，技术成果从此无用，架构路线推倒重来，业务功能重新开发等尴尬局面。

而这些痛点或瓶颈问题，可以通过对技术的产品化思维，利用平台架构思想或产品，进行有效地支持、控制和改善，帮助减少无谓的重复工作、技术成本和资源浪费。

3）、把握方向和认知

平台架构有其形成的必要和应用的价值，但也需要对它保持正确的认知和很好地把握，平台架构对认知能力、架构能力、把控能力等的要求都很高，对平台架构的方向控制不好或认知不够透彻，很可能走向错误的方向或退化的误区，难以保证其继续遵循合适、简单、演化的架构三原则【注1】，那么平台架构就很难合理、稳定、健康地发展，逐渐失去其应有的价值，甚至产生负面的作用。

那么什么是平台的正确认知呢也是我这几篇文章想表达的内容，简单来说，就是明白平台是用来做什么的，它需要有什么特性，应避免怎样的问题，以及它应该有怎样的发展。

4）、避免失败或束缚

尽信书则不如无书，如果认为平台构架能够解决一切问题，那么就可能会发生更大的问题。对于平台架构，既要避免对其产生过多要求或束缚，制约其发展，也要避免其对开发过程过于限制，对开发造成很大的阻碍。

以平台架构而言，首先应明确对它的期望和它需要承担的责任，并考虑到可能面对的其它问题及对待这些问题的策略，然后在平台架构发展过程中，尽量避免因超出预期的能力要求、不断提出的功能需求和其它外力原因，让平台架构陷入不停扩充、疲于应对、代码堆叠、臃肿复杂、难以进化、重负难承的境地，否则平台架构很难发展起来，甚至终将成为失败品而被放弃。

另一方面，平台架构应该提供充分的可扩展能力和可替换能力，使其在规范开发过程的同时，也允许产品开发人员在平台架构的开放约定下进行扩展，甚至替换平台架构的部分能力，以满足产品项目的实际要求。当平台构架对产品项目产生的阻滞作用，接近或超过其带来的助力时，这个平台架构要么需要马上重构，要么就该放弃使用了。

5）、权衡价值与冲突

平台架构提供的很多特性，其实是相互冲突的，比如规范性与灵活性、可控性与开放性、可靠性与可扩展性、简单化与可配置化、轻量化与丰富功能等等，这些冲突的特性需要被很好的认识到，并合理地权衡他们在不同情况下各自的要求、影响以及效果，选择更优化的决策和更平衡的处理，以实现他们的对立统一。同时，这些权衡结果应尽量不破坏平台架构本身的合理性、健康性和优化性。

对于容易产生理念冲突、难于选择或可能对规范产生影响的位置，要及时发现并给出意见或替代方案，指导开发人员按照相对合理的方法进行开发、扩展或替换，同时对其可能产生的影响，也要做出适当的解释说明。

对于平台架构自身也一样，比如合理性和实用性，都需要建立在大量的时间上，只不过一个是对平台架构内部，一个是对业务项目支撑，当业务急于使用平台架构的能力，但此能力是平台架构需要具备但无法在短期内保证其合理可用时，那么应尽量以较合理的方案或方式提供此能力，并在后续过程中及时对其进行调整改进。而当平台急于发展导致内部不再优化稳定时，一定要适时地停下脚步，对平台进行必要的修正重构，否则当平台架构问题重重、积重难返时，那么它也快走到尽头了。

2、平台架构不是空中楼阁

1）、平台架构不是遥不可及的

平台架构其实是可大可小的，一个大的平台，可以是很多个能力组件、大量的内置功能、全过程的管理支持，开放性的服务体系，以及成熟的规范指导，而一个小的开发架构，可能仅仅是几个开源框架的粘合和一些开发方面的约定。

对于一个小型企业或项目团队，因为规模不大，平台架构并不一定是必须的。当在需要平台架构的时候，可以结合自身实际，将技术能力、以往经验和网上的方案结合起来，尝试并形成适合自身的架构方案和架构体系。

而对于中型或大型的软件企业与团队，架构乃至平台则是很重要工具，而且他们有充分的技术实力、大量的经验积累和充足的成本投入来构建自己的平台架构，满足项目保障、技术积累、行业发展等需要。有时在面对临时项目、超短工期、非专业领域的需求时，还可以直接向外采购成熟的平台架构产品，来支撑自己的产品项目。

对于更大的软件企业来说，有几套面向不同方向或支持不同特性的平台构架产品，甚至引领平台架构的标准，都是很正常的事情了。

2）、平台架构不是一时冲动

有些企业高层或技术主管，认识到了平台架构的作用，立志于建立自己的平台架构产品，来支撑和促进企业的产品业务。但一个成熟、稳定、可持续发展的平台架构，不是仅凭一时决定和一腔热血就能实现的，起码没有充分的思考设计、大量的经验积累、充足的技术实力、不断的实践改进，是难以完成的。

对于这种情况，要么从实践中慢慢摸索，逐步形成平台架构的最佳方案，要么借鉴其它成熟的平台架构方案或经验，并在实用中通过学习改进，渐渐演变成适合自己的平台构架，总之对于一个平台架构方面积累不多的企业，平台架构之路不能想着一朝一夕就能达成，不能操之过急。

3）、平台架构需要为实用服务

平台架构首先要为本企业的当前项目和业务发展服务，它可以不用马上达到全面和完善，但要能够很快用于实际并带来价值，否则如果只顾着平台架构的先进理念、优美架构、前沿技术和广泛价值而进行封闭构建，那么平台架构很容易陷入反复论证、不断填充、接连改进的书面，导致迟迟难以完工和交付应用，同时这样完成的东西就像闭门造车一样，真正使用时仍会发现存在大量不方便的、不适配的、不实用的，甚至不合理的、无用的设计和功能，结果与预期产生巨大的偏离，造成时间上、成本上的浪费，甚至更大的损失。

一些看上去很高大上的技术、功能和设计，如果短期内或相当一段时间内无法应用于实际并带来价值，那么就可以推迟，甚至无需加入到平台框架里。

4）、平台架构需要践行和提升

平台架构初期很难保证其完全的实用性和合理性，需要尽快在实际产品项目中进行验证和磨合，并及时收集意见反馈，进行分析论证，发现和解决设想上的、规划上的、规范上的、结构上的、功能上的、质量上的偏差和问题，让平台架构更科学、更健康。经历过很多个项目检验的平台架构，其可靠度和支撑能力，也能让企业领导、业务团队，以及目标客户易接受、易认可、易信赖。

5）、平台架构需要探索与试错

平台架构不应只满足对已有能力的维护和对已有产品项目的支撑，还要对现有内容进行改进、对行业发展进行预见，对流行技术进行探索，否则当客户有更高要求、更多需求或发展要求时，平台架构如果不能在较短时间内提供支撑方案，那么很可能会让各方降低对平台架构的评价，而且在平台架构上仓促补增的功能，在质量、合理性、可靠性等方面也很难保证，对平台架构也是不利的。

平台架构的优化探索，可能在稳定性等方面产生一定的风险，但为了平台的发展，既要承担这个风险，也要做好控制工作。通过对平台架构进行充分测试验证，以及版本升级等方法，可以尽量降低平台架构的BUG量，及其产生的影响。

3、平台架构不是一蹴而就

1）、先要理解平台架构思想

搭建一个简单的平台架构，并不太复杂，但搭建一个优秀的，有强大支撑力、广泛适用性和长久生命力的平台架构，就不是那么容易的事情了。要搭建一个高质量的平台架构，首先要理解平台化思想，要懂得和坚持软件工程化、过程规范化、结构模型化、组成构件化、能力复用化、调用接口化、业务隔离化【注2】、代码标准化这些思想和要求，架构思想本身既有软件工程思想，也包含着对丰富的规划设计能力、开发支撑经验、需求运维体验的要求，忽视上述这些内容来建设平台架构，是不会成功的。

而对于平台建设参与者来说，至少要具备较强的技术能力、一定的项目经验、面向对象思想，以及对代码的“洁癖”和对技术的追求。

2）、还要清楚平台架构使命

平台架构大的目标和作用前文已经说过，不在赘述。但在具体企业里，平台架构初始的任务，并不见得非要这么大，可能它当前只需要支撑一个或几个项目，那么作为平台架构的构建者，就要先掌握平台架构当前最重要的目标、可以收拢的资源，以及对交工日期和平台能力的要求，在此基础上，还可以向平台架构的广义使命上靠拢，或在平台架构设计上深化，并把握住平台架构的结构和质量，让设计开发出来的平台架构，具备向深度、广度、成熟度发展的良好潜质。

而一个大的、长久的平台，它需要承担的使命和需要具备的特质，是每一个平台建设参与者都需要理解清楚和认真执行的事情。

3）、要认识平台架构的生命

平台架构并不能一直存在，这也是每个平台建设参与者需要了解的。我把平台架构的生命划分为：初生、发展、调整、转变/衰退，共四个时期。

其中初生期，是平台架构刚开始规划建设的时期，这时平台架构功能不全、Bug不少，但充满着活力和希望，即将承担重任；

到了成长期里，平台架构的基本目标已经达成，基础功能大体完备，整体趋于稳定，已经有项目建立或运行在平台架构上，平台架构重点向纵深方向发展；

再往后发展，平台架构进入调整期，这时平台架构的初期目标已经大半或全部实现，平台架构开始侧重精细化或大而全，此时的平台架构仍很有优势，但有些问题也开始显露，而平台架构构建者对这些问题的认识和态度，也决定了下一步平台将进入转变或衰退；

再到下一阶段，随着目标行业的发展与扩展、开发技术的演变与转化，以及平台初始的核心缺陷与积累的庞大、复杂、混乱、封闭、不合理、低效率、难改进、难扩展等问题，导致平台劣势渐显、矛盾渐深时：

1. 平台可能因设计架构合理、问题较浅和转变及时，而用新结构、新技术、新组成来优化、替代或重构，提升活力，延长或焕发生命力。
2. 或因设计缺陷、结构问题、缺少投入，以及体积臃肿或业务粘连【注2 】等原因而难以改进，等待衰退直到消亡。

4）、要有好的方向和设计

要做平台架构，需要有长远和眼光，具备良好的设计能力。有名话说：目光有多远，你就能走多远，格局有多大，你的世界就有多大，这句话对平台也适用。代入一下，方向即是平台架构的目光，设计即是平台架构的格局。

在平台初期和发展过程中，不仅要低头干活，还要抬头看路，适时地整理一下平台架构的状况，展望一下平台架构未来的方向，看看现在的路走的对不对，好不好，往下应该怎么走。同时合理的架构、良好的设计，也是保证平台能发展的基础，充斥着不合理不健康设计的平台，是发展不起来的。

5）、要大胆设想小心求证

做平台要大处着眼，小处着手，既要明白平台的远期战略目标与期望价值，也要制订当前合适的战术计划和结果预期，并着力于具体工作。同时理论与实践相结合，一方面印证战略的方向是可行的正确的或需修正的，另一方面在实用中总结和升华，形成更科学的目标和论断。

想的不一定就是对的，如果只会空想忽略实际，并强行应用于平台框架，那么结果可能只是个花架子，中看不中用；而只专注当前需求，不考虑未来发展的平台架构，虽然一时能用，但很快就会跟不上技术和需求发展的步伐。

6）、要从基础慢慢积累

罗马不是一天建成的，平台架构也同样。平台架构对认知和设计的要求，需要借鉴成功的经验或从实践中慢慢摸索，并认真思考研究，同样平台架构对建设者的要求，也需要慢慢培养和引导。

建设平台架构，首先要统一思想，明确目标，然后一步步完成设想，及时发现和解决问题，形成平台架构的基础并渐渐完善。应促进平台建设者们的交流和讨论，让大家在交流讨论过程中，解开思想和技术上的问题，逐步形成一致的认识，统一的标准，共同把握平台的结构和质量。

4、平台架构不是一个模子的

1）、不能照搬照抄

世界上的企业千千万万，平台架构也多不胜数，但各个企业的主营方向、客户群体、业务场景、软件构成、技术力量、管理策略等都可能会有差异，别人家的平台架构和建设经验，对自己的企业并不一定就是完全适用的，要会甄别和分析，哪些可以拿来就用，哪些需要做些改造，哪些对自己几乎毫无用处，要知道只有合适的才是最好的。

2）、不能画地为牢

平台架构既需要用来规范开发，也需要能够规范自身，但这个“规范”不能是死的一成不变的，要根据实际情况和发展需求，做适当的调整和变化。就整体而言，平台构架是业务开发的基础和支撑，它应该是牢固的，但就局部而言，平台架构的组成和提供的能力，应该是开放的、解耦的、可替代的，这样平台架构既能建立起统一的规则，指导产品项目开发，也能灵活转变，适应发展的需求。同时平台架构自身，也要跟随时代发展和技术进步，不断演进和提升。

3）、理论实际相结合

平台架构需要有指导思想和建设理论，这样它才能看的更高，走的更远，平台架构还必须为实用服务，这样它才能印证设想，产生价值，这两者既不冲突，又是相辅相成的。同样的，很多的软件工程思想，比如面向对象、模型驱动、设计模式等等，也都适合在平台架构中应用，帮助其建立科学合理的设计和结构，但这些都必须以实用为主，如果过度设计，那就得不偿失了。

4）、以实用为主以规范为纲

平台架构应面向应用，它的各项设计和能力，都应该能在现在或可预见的将来，为企业进行服务并产生促进作用。平台架构建设者应与公司领导和开发团队、产品团队多接触交流，让他们也了解和掌握平台的目标和特性，帮助平台架构健康发展，及时发现和纠正平台架构中的不合理、不实用的设计和功能。同时平台架构也需要建立起自己的、科学合理的规则和标准，引导和规范自身发展与业务开发，并在实用中磨合出更合适的标准和更明确的方向。

5、平台架构是发展演进的

1）、平台架构思想在变化

我认为平台架构思想的发展，经历着由固定模式到最佳实践、由一体化解决方案到适用生态、由项目能力到服务能力的转变。

以前技术发展相对较慢，技术生态圈也很弱小和迟滞，知名的平台架构，基本都有自己的固定模式，尽量涵盖到面向行业的大部分需求，并由自身提供这些能力和技术支撑，而平台架构的使用者，需要在它的限定范围内进行开发和使用，如想跳出它的制约采用其它方案，则存在诸多困难。

当前的IT行业与软件技术发展非常快，架构思想也更为贴近、技术生态更为活跃、协议标准更为一致、功能组件多种多样、能力积累丰富成熟，主流的平台架构更多的是采用相近的架构理念和类似的搭建方案，对能力的支持也不限于自己提供或单一选择，而是面向服务协议或接口标准，让使用者可以自行在能力生态圈里筛选组合，在提供解决方案的同时，为使用者提供了更宽泛和自由的支持；同时倡导对既有能力以服务化的形式进行整合、优化、封装、开放和管理，为不同用户需求和使用场景提供公共支撑【注3】。

2）、平台架构构成在变化

以前平台架构的能力组成，多由平台架构本身提供，技术实现也基本相同，相互间依赖较重，能力间拆分较少或较浅，现在的平台架构，更注重模块化、组件化、服务化，能力构成之间各自独立并以接口协议进行互访，各能力支撑组件可使用不同技术实现、可拼装卸载、可选择替换、可单独使用。

3）、平台架构模式在变化

以前的平台架构，更强调业务能力、行业经验和产品化功能，而当前的平台构架，则重注重能力组合、简化过程、解耦功能、加强协作，提升能力面向范围，简化开发配置过程，减少相互引用和依赖，降低代码量和协作成本，促进企业能力整合和高效收益。

4）、平台架构体量在变化

以前的平台架构一般是以“全家桶”方式提供，在当时情况下，它以自行开发为主，能力较强、封装较多、体积很大、部署复杂，显得大而全，而现在的平台架构，则向融合化、轻量化发展，大量采用公共标准和开源组件，开发代码量大幅减少，平台体量的伸缩性很强，既可以选择全部功能，也可选择部分能力，还可以进行局部的能力替换，使用平台外的产品来替代平台本身的能力。

5）、平台架构的面向性在变化

我认为，平台架构经历着单体->整合->融合方向的发展。以前平台架构只要支撑单一项目或产品即可（单体），随着软件产品的扩充和数据孤岛的增加【注4】，以及用户的管理要求，软件间互通的需求越来越多，要求平台架构能够支持软件间的访问和协作（整合），那么当前平台架构除了基础的项目支撑外，还需要具备支持敏捷响应、业务创新、以及跨行业适用等特性，以满足用户对能力的快速提供、服务协作和用户体验等方面的要求（融合）。这也符合了软件从单体到服务化，再到云、互联网+、移动化、微服务、大中台、富生态的发展过程。

6、平台架构不是万能的

1）、没有“银弹”

平台架构有它的好处，但也不是万能的，“平台”并不能解决所有问题，能解决问题的，最终还是人，还是对行业和企业的认识和发展的考量与决策。企业可以通过平台架构思想，来构建自己的技术平台、业务平台、产品平台、服务平台，促进企业发展和提升，但“用什么”、“怎样用”，是与“要不要用”一样重要的问题，需要想清楚。使用平台架构应符合最佳实践的理念，只有合适的才是最好的，而不“合适”的平台，比如能力不强、设计糟糕、代码混乱、约束重重等，这样的平台不如不用。

2）、平台架构需要明确并专注目标点

平台架构要为实用服务，为企业创造价值，这需要为平台制订合适的长期规划与可行的短期目标，在平台架构发展过程中，围绕这些规划和目标开展工作。平台架构的目标与规划可能会随着企业本身、技术趋势与管理意识等的发展而进行调整，但也要把握好尺度，过于频繁的调整目标计划，或不断改变对平台架构的能力预期，以及经常冲击平台已有的规则标准，这些就都是很忌讳的事了，这样做往往会导致平台架构的目标难以完成，健康性与支撑能力减弱，甚至更糟。

3）、平台架构需要减负增效

平台架构能力的提升过程，往往也伴随着它体积的增长，以及健康度、稳定性、运行效率的下降，如果不重视这些问题，那么平台架构也会变成“胖的走不动路”，影响它的能力与发展。所以在平台架构发展过程中，还要注意平台自身的减负增效，对平台进行评审、优化、拆分、重组，甚至是局部或整体的重构，使它始终能够保持可控、合理、高效和可发展。

4）、平台架构需要边走边看，不断演进

软件技术、行业标准、发展趋势都在发展变化，那么平台架构也需要参照这些发展变化情况，以及审视自身状态，及时进行调整、适配和提升。这与平台的“专注”并不冲突，规则和标准，本身就是平台架构的立身之本，但发展的道路不是一成不变的，规则标准以及平台架构自身，可能并不会完全符合未来发展的趋势和变化的要求，这一方面要求在制定规则标准及搭建平台产品时，要有一定的前瞻性及可发展性，另一方面这些内容也需要不断完善与演进，以适应趋势，保证平台能够始终能够在发展的浪潮中，得到存续并不断提供充分的价值。

5）、平台架构也有可能成为负担

如上所言，在平台架构的发展过程里，它的决策者和构建者们，要不断地提升自己的认知、视野、敏感性和技术能力，同时也要保证平台自身的合理、健康、可持续、可发展，这样才能让平台沿着正确方向不断提升演进，否则平台架构就可能发生能力减退、不适应技术趋势、不支持行业发展要求，甚至制约企业的产品项目能力等问题，由企业发展的助力者，变为阻碍者。当出现这样的情况时，这个平台架构就是失败的，难逃没落的命运。

7、平台架构本身也有价值

1）、平台架构可以为企业提升价值

用合适的平台架构作为企业产品项目的建设支撑，可以有效地为企业提升业务承接能力、提高项目建设效率、降低项目建设成本、强化客户对企业的认可、促进企业发展进步。

2）、平台架构可以实现或推广企业价值

在平台架构中，还可以融入企业对行业的认知和对技术的引领意识，将企业对自身的总结和对发展的预见，体现在平台框架，以及其支撑的产品中，来促进和推动客户企业以及目标行业对本企业发展观的认可，以及对本企业带动作用的认同，助力企业价值的推广。

3）、平台架构也可以作为产品

当企业的平台架构比较完善或先进时，可以将平台架构作为产品，进行平台架构的技术推广和有偿使用，以及提供咨询、培训、支持、出版等付费业务，为企业获取收益。

二、注：

1、来源于《架构设计三原则》，https://blog.csdn.net/program_guys/article/details/81007352

2、业务隔离化和业务粘连，是指在平台架构代码中，不要出现针对业务状态或业务指标值的判断和处理,避免架构业务之间的紧耦合，这样即是平台架构与业务的隔离化，反之则是业务粘连。

技术型平台架构虽然是为支撑业务开发而存在的，但其核心应该是单纯技术化、功能化的，或者说是只对当前模块能力负责，而不考虑具体业务指标的差别。如果因业务场景或业务条件不同，导致平台架构里的处理出现不一致，这时就要通过插件、适配或可扩展性等方式，将与业务相关的处理从平台架构中剥离出来，避免平台架构与业务，或者平台架构功能间出现逻辑沾染或深度耦合，特别是避免与业务开发间的粘连。

如果平台架构出现业务粘连，一方面会导致平台架构存在非平台处理，变得肿胀和不纯粹，另一方面因平台架构修改会影响到业务，导致平台架构难以优化和改造，拖累平台架构的发展，甚至影响其生命。

3、实际上是说中台的概念，简单地搜索了一下，我对中台的理解，与此链接及其评论相近：https://www.jianshu.com/p/86dc7ad52ad6。中台是平台架构的延伸，它是基于平台架构和业务积累之上建立起来的。

4、指早些年企业里相互独立，互不相通，难以协作的各类管理软件。

参见：

【我对软件平台架构的理解】第一部分：软件平台架构有什么用

【我对软件平台架构的理解】第二部分：对软件平台架构的认识（一）

【我对软件平台架构的理解】第二部分：对软件平台架构的认识（二）

【我对软件平台架构的理解】第三部分：构建软件平台架构的建议

【我对软件平台架构的理解】第四部分：软件平台架构的历程和类比

来源：sidac