一、建设平台架构的主要思想

对于建设平台架构，首先应注重对它的工程化设计和管理，而且要用比产品和项目更加严谨的工程化思想，来进行平台构架的规划、设计、落实和演进。

1、工程化

在度娘搜索了一下，关于工程化，没有找到更合适的、权威的名词解释，倒是度娘知道里的一个描述，比较贴合我对工程化理解：工程化即系统化、模块化、规范化的一个过程。【注1】

我认为，软件的工程化，就是在软件的构建过程中，应用理论化、系统化、标准化的思想，对软件进行规划、设计、实施、管理和控制，以保证其过程与结果的质量和效率，及其可维护、可复用和可发展的能力。

针对平台架构上的工程化，就是应用软件工程理论，将平台架构当作一项工程，进行充分的调研分析、系统规划、拆解建模、抽象设计、协作建设、评审验证和持续改进，以使其达到和保持理想化结果的行为。

2、模型化

模型泛指实际系统或过程的特性的一种表示形式，或映成的一种结构。【注2】

平台架构的模型化，就是对平台架构进行结构化拆解、对象化设计，并建立起它的模型和关系的表达。面向对象的理论大家应该都比较熟悉，这里结合平台架构的建设，说一下我的理解，强调的是对平台架构要做好模型化设计，以形成科学合理的架构模式、组成方式和协作关系，为平台架构提供更好的标准性、效率性、灵活性，以及可维护性与可扩展性。（关于模型化及下文中的1）、2）、3），可以见【注3】）

1）、结构化

用系统科学的思想方法，将平台架构看作是一个系统，对它进行抽象、分解，以提炼它的主体结构和分支构成，并以此描述和指导平台架构的建设。

2）、对象化

用面向对象的方法，对平台架构中的各个细微组成，进行抽象和封装，形成合理的结构单元，这些结构单元组合起来，形成了平台架构的整体。

3）、层次化

层次是对抽象的归类和排序，它可以从不同的维度进行拆解，以表达对象及结构间的构成和协作关系。

4）、组件化

组件是把具有某一方面能力的，或含有共同特性的对象汇集在一起，封装成一个大的集合，形成内部统一外部独立的服务载体或能力支撑。

5）、接口化

要对对象间、组件间、结构间、层次间的交互关系及访问过程进行很好的分析、抽象和设计，并形成相对合理而稳固的接口描述。好的接口设计对平台架构的结构、效率、稳定性、维护扩展能力都至关重要。

6）、服务化

服务化是对抽象和封装的升级要求，它强调的是对业务（也可以是技术）的服务化管理，使之应具备如下特性：

1. 边界清晰、能力稳定。
2. 高内聚、低耦合。
3. 无状态、可伸缩。
4. 轻量、通用、开放。
5. 可管理。

我认为服务化可以算作模型化的一种深化，虽然模型化并非一定要服务化，但对于平台架构和其支撑的应用来说，服务化则是很重要的手段。

3、规范化

首先应建立起平台架构自身的标准规范，并依此来建设平台架构，保持平台架构的合理性、健康性、稳定性，其次还要建立起基于平台架构搭建产品项目的标准规范，既能用来指导产品项目的实现过程，也能与平台架构本身的标准规范相互验证，以使平台架构更加的科学合理。

规范化是保证平台科学合理、健康稳定的重要标准，如果不能得到良好地执行落实，很可能会对平台架构产生很大的影响。同时，如果有些规范不完善或不合理，则应及时分析问题原因，探讨修补措施或提供替代方案。

二、构建平台架构的过程

1、收集业务需求与发展方向

平台架构要为企业应用服务，在构建平台架构前，需要先了解企业的业务情况、技术需求、发展规划，以及对业务、客户和技术的发展预期，以此来制定平台架构的远近目标、技术方案、建设规划、成本投入、期望成效等内容。

2、整理技术储备与成果储备

平台架构很难从零开始，基本都是利用企业已有的技术底蕴和经验积累，进行融汇整合，并逐步发展起来的，所以在建设平台架构之前，有必要对企业本身的经验积累、技术实力、以往成果、业务实践、研发诉求等进行收集和分析，以确定平台架构的最终需求、能力构成，并组建起平台架构团队。

3、上升平台架构的理念和预期

“技术是船，思想是舤”，平台架构如果不能形成自己的理论和远景的预期，很容易被不断涌入的业务需求和各种意见与批判所干扰影响，难以找到正确的方向和得到科学的发展。只有建立起自己明确的预期和遵循的理念，才能围绕着这些，形成平台架构自身的思想与规范，并以之引领平台、指导开发，带动客户。

再进一步，平台架构还可以承载企业对技术的理解和对行业的认知，通过平台架构及建立在平台架构上的产品项目，还能够推广企业自身的产品理念、行业价值观和发展观，见证企业发展，推动行业升级。

4、形成和磨合平台架构的规划、方案和指标

前期准备工作完成之后，就可以对平台架构进行具体的规划、设计，并形成可行方案，对于远期目标，可以粗放一些、简略一些，但对于近期计划，一定要相对细致且可落实。同时，对于这些规划、方案和目标，要有结果预期和验证指标，以确认计划的执行情况、完成程度和实际价值，及时发现和解决过程中的问题，以及调整和明确后续计划。

5、回落具体模型和组成部分

将大体的粗放的规划和方案，拆解为更细小的基本的模型和方案，形成详细设计，并以之指导平台架构的具体建设。做平台也应一手抓发展一手促实践，在保持宏观上具有科学认识和明确方向的基础上，在实践中要能够分解落实，将这些设想和理念，变成真正可行的、可变现的、可实用验证的内容。

6、指导产品开发、调整和改进

依据之前的各类规划、设计和方案，组织平台架构的具体开发，稳步推进，并及时进行过程回顾、总结分析、调整优化，以及目标展望、持续推进平台的进步与发展，并向着更合理、更科学的方向演化。

三、建设平台架构的要素

1、规范研发要求

建立起平台架构自身的，以及面向平台应用的标准、规范、约定和要求，以此来引领平台发展、指导开发过程，引导客户思维，促进企业产品项目推广建设。

2、先进架构思想

平台架构的思想理论，一方面指引着平台架构的建设和发展，另一方面也承载着对企业发展方向、技术发展趋势和行业未来走向的认识和预期，对这些内容认识的越深，越明确，越具体，越贴近，对平台架构自身、及搭建在其上的应用，还有平台架构与企业发展就会更加有利。

3、技术经验积累

建设平台架构，既需要对开发技能和前沿技术的掌握和敏感，也需要对分析设计和架构能力的熟悉和应用，还需要对项目过程和开发经验的了解与积累，起码对于平台架构的管理者与主导者来说，这些都是基本的要求。

4、分析思考讨论

平台架构注重模型化分析、结构化设计和规范化应用，这个过程，需要各建设者都参与进来，共同认识平台架构思想，了解平台架构要求、学会结构设计，制定并遵循各项标准，同时还要激发思考、大胆探索、勇敢尝试、促进沟通、坚持审评、积极讨论，以让建设者们思想活跃、步调协调、目标一致、方法贴近，让平台架构向正确的、更好的方向发展进化。

5、尝试磨合优化

平台架构初始的预期、设计、结构和功能，可能并不是最好、最方便、最优化、最适合发展，这就要求平台架构需要在实用中不断摸索、验证、总结、改进，同时也要求平台架构的建设者们，也要加强自己的架构能力、发展认识和技术水平，持续提升平台架构的支撑能力、健康程度、效果评价、发展能力和推广价值。

6、审评发展重构

如前文所述，平台架构的思想规范，以及设计编码，可能不是最好的、最优的，那么就需要在平台架构的发展过程，坚持对平台自身的审视和对未来发展的追随。要加强平台的评审、内部的探讨，以及理念的明确和提升，同时关注技术的发展和行业的进步，对平台架构自身问题、缺陷、弱点，及其它不适应发展要求的内容，进行适时的调整、优化、重构，并不断融入对新技术、新方向、新需求的理解与支持，让平台架构做的更好，走的更远。

四、新型平台架构的要求

随着行业发展、技术进步，对平台架构的要求也在发生着变化，我认为新型的平台架构，应符合下面这些要求。

1、认知、共识

之前已经说过了，建设平台架构，如果没有形成比较先进的认知和理论，相对合理明确的理念、目标和标准，或者建设者们内部思想跟不上、观点不统一、步调不一致、互不认同、做法各异，那平台架构是很难成功的，只有形成科学的认知、共同的意志和良好的配合，平台架构才能有更好的表现，更远的未来。

2、设计、规划

长远的设想、良好的规划、优秀的设计，以及出色的执行和持续的演进，能让平台架构站的更高，走的更远。

做平台要“大处着眼、小处着手”，“一眼看现在，一眼看未来”，就是说既要有远景目标与计划，也要做好近前的工作，用实践来验证理论设想和应用效果，同时在践行过程中，不忘“抬头看路”，既走好眼前的路，还要兼顾平台的标准和可持续发展的能力，以更好地走向未来。

3、粘合、适配

如今形势下的平台架构，已经不适合完全自己从头建设，那样既耗费大量时间和成本，也带有很大风险。

我认为新型的平台架构，应更注重对发展的理解和规范的制定，并充分利用当前市面流行的这些成熟的技术、规范、组件、协议，参考人们的使用体验，从中选择合适的内容，粘合成自己期望的平台架构，并完成它们之间的适配和协作，使之符合自身的预期成效与规范要求。

同时在平台架构发展过程中，一方面可以促进局部的配置化、个性化建设，另一方面也可对这些组成进行优化或更替。

4、标准、自由

如上一观点所述，平台很难重新定义开发标准、接口规范及组合模式，那样既耗费成本，也难以兼容流行技术。所以平台在建设时，应尽量贴合流行标准和发展趋势，一方面可以利用现有的资源，减少成本、时间、难度、风险，另一方面也便于与其它系统或构件对接、协作，以及扩展和发展。

同时，平台应提供充分的可扩展、可适配与可替换能力，既要在开放性的方面，允许开发人员在需要的时候，通过可扩展性设计，接入新的处理能力或操作模式来满足业务需求和发展需要，还支持在必要的时候，直接对平台构件和服务能力进行改写与替换，提升平台支撑能力，避免平台对项目造成较大制约和束缚，成为业务阻碍和发展负担。

5、轻量、层次

建设平台应该注重微核心、轻量化、层次化的特性。

首先，平台架构一定要轻量，平台架构需要为产品项目提供解决方案，但这个解决方案不一定完全是自行建设的，也可以是粘合流行技术并形成合适规范，以提供充分的支撑能力。

同时，对于平台架构的建设，也要使其组件化、服务化、轻量化，以便平台架构自身的能力的解耦设计、拆分管理、重构替换和独立服务。轻量化使平台架构结构更清晰、规范更明确、维护更容易、扩展更方便，对发展方向调整和对部件的更替也更容易实现，这样的平台能力可以更强，产品项目的适配性和支撑性可以更好，也能更好的适应未来发展。

其次，对于平台架构及其组成，都可以当成一个个构件，并按由内而外的方向将其划分为核心、标准功能、扩展功能和个性功能四个层次。

其中的核心层是能力的最底层的、最基本的、最稳固的支持，这里一定要最轻量、最优化、最合理、最稳定，标准功能层提供能力的基础展现，通过核心+标准功能，就可以体现这个构件的最小特征和最基本的能力支持。扩展功能是对能力的进一步丰富和扩展，这些扩展并不一定在所有应用中被用到，而个性功能则是个别产品或项目的要求，一般不具有大范围使用的需求或不具备广泛适用性，部分的扩展功能，和绝大部分的个性功能，都可以在产品或项目中实现，而没必要非得放入平台架构里，这样才能更好地保持平台架构自身的合理性、轻量性、业务无关性。

这些功能层次，由内而外，对规模、质量和效率的要求，越来越低，对它们重要性的评价也越来越低，在需要的时候，也可以对层次内的能力，进行适当的提升或下降，并进行适当的调整或优化。

层次化首先可以让平台构架更注重核心的能力和效率，并集中技术优势来建设，其次可以更好地进行人员分工，让主力人员侧重于核心能力，保证平台架构的基础是坚实可靠的，第三，当平台架构遇到人员流失、发展困难、转变方向等重大问题时，一方面能够保证核心是稳固的，不会受到大的影响，另一方面还可以从外围逐一舍弃一些能力，以保持平台仍是可控的、可用的、可维护的、可发展的。

6、拆解、服务

做好平台架构各项能力的划分、拆解，及各能力构件内部的建模和设计，使整个平台架构，及其构件，既是整体统一，又能独立解耦，便于模块间、建设者间的分工推进和整体协作，也便于局部能力的优化、重构，甚至撤换。

各构件之间及平台能力的外放，尽量使用服务化的方式，既便于将服务提供给更多的使用者，也便于服务的统一访问和管理，而且还能让服务的内部与使用者解耦，便于升级改进。

7、评审、交流

平台架构管理者和建设者们，应该加强相互间的沟通探讨、技术交流，以及对平台的评审讨论，一方面便于发现平台架构及建设者的认知上、设计上、结果上的问题，另一方面也利于统一大家的思想，让大家齐心协力，共同促进平台的质量和效率。

8、演进、重构

平台的强化、进化、优化、转化，是很麻烦的过程，但也是必须的过程，平台只有不断进步，才能适应客户的要求和时代的发展，在此过程中，及时和适当的回顾自身，并进行审视、修正和演化，才能让平台更健壮，更先进，有上佳的表现和更好的发展。

五、构建平台架构的建议

这里对构建平台架构，提出了一些建议，对前文内容再次重申，避免平台架构的建设陷入误区。

1、应共识和协力，先理论和规划

促进建设团队统一思想、广泛讨论，深入理解平台架构的意义、目标和未来，共同做出合适的远近规划并协力推进。

2、重融合和规范，分核心和枝节

平台架构更侧重能力的提供和过程的规范，而无必要全部自产自研，可以对开源技术、企业经验、以往成果进行融合，结合平台架构理论，形成平台架构产品。还要划分清平台架构及其构件的核心能力和核心层次，并着重建设，这样既能分清主次，促进平台核心能力和核心功能的稳定和发展，又能在困难条件下保留住平台架构的核心资产，还可以在需要的时候，对非核心能力进行取舍，以便平台架构可以轻身前进。

3、要认知和遵循，再实践和总结

要对平台架构及其规范，形成良好的认识，并认真遵循，还要引导平台架构建设者、业务开发人员和客户群体了解这样约定的意义和好处，让大家理解平台架构的规则并善加使用；同时避免非规范性的东西融入平台，这样平台架构才能更稳定更长久地提供支撑能力；还在实践中还要不断地总结提升，促进对平台的理解，和认知的进步；在必要的时候，可以适当地对规范内容进行调整，使之更适合发展要求。

4、可调整和完善，莫迟疑和偏离

平台架构及其规范需要遵循，也需要进化，何时需要改变，怎么改变，这是对平台架构管理和建设者们的一个考验，对平台构架的认知越清晰，对未来发展的认识越贴近，所做的判断和取舍就越有价值。在平台架构发展过程中，还应该避免平台架构中的规则模糊不清，产生歧义，或者规范把控不严，导致平台发展远离期望的整体目标。

5、有评审和验证，需权衡和决断

对平台架构的规划和预期成效，应该提前做好分析和设想，并在建设和发展过程中，不断验证和审评，及时发现建设问题、设计问题、认识问题，当发现起初的设想或标准存在问题时，应尽快分析讨论并做出决断，让平台架构能够继续沿着明确的或修正的路线快速前进。

6、应轻量和兼容，能包容和演进

平台架构要轻量、建设者要精干、建设队伍要简化，这样才会让平台和建设团队的战斗力更强、成长更灵活、发展更容易、性价比更高，同时平台架构及其构件应结构化、开放化，与流行技术和发展趋势相适配，这样既便于它的维护提升，也便于需要时分拆使用，提供独立构件服务或进行部分更迭替换。

7、忌全能和臃肿，防复杂和低效

一个人不可能什么都会，一个平台架构也不可能什么都支持，如果想建设一个全能的平台架构，那么它一定会相当的臃肿，并且难以保持健康和高效，甚至会存在结构复杂、逻辑杂乱、耦合深化、难以改进等问题。建设平台过程中，一定要分清哪些能力是平台架构必须的，哪些能力是可以通过可扩展性来实现的，哪些能力压根就不必放入平台里。我认为，宁可让平台架构的建设者，在需要时，帮助业务团队，在他们的项目实现和解决个性化的技术问题，也远比把这些需求放入平台架构里更科学合理得多。

8、慎庞大和繁重，勿封闭和僵化

平台架构的体量，与建设团队的体量，以及对平台架构的预期，这些都是需要考虑和权衡的，俗话说“有多大肚吃多少饭”，既不要以简单的需求和单薄的力量，挑战庞大而全面的预期，也不要给团队以重压和难以完成的目标，让他们疲惫失落，对平台未来和自身价值失去信心。同时“小目标”，精团队，轻体量，高融合，也是平台架构立身和发展的“法宝”。

六、注

1、百度知道—什么是工程化

https://zhidao.baidu/question/174630859.html

2、百度百科—模型化

https://baike.baidu/item/%E6%A8%A1%E5%9E%8B%E5%8C%96/15713553?fr=aladdin

3、百度知道—如何理解各种模型化的基本方法

https://zhidao.baidu/question/268173064297089525.html（因原文标点错乱，这里做以整理）

1）.结构化方法遵循的基本原则。结构化方法的基本思想，就是将待解决的问题看作一个系统，从而用系统科学的思想方法来分析和解决问题。结构化方法遵循以下基本原则：

（1）抽象原则。抽象原则是一切系统科学方法都必须遵循的基本原则，它注重把握系统的本质内容而忽略与系统当前目标无关的内容，它是一种基本的认知过程和思维方式。

（2）分解原则。分解原则是结构化方法中最基本的原则，它是一种先总体、后局部的思想原则。在构造信息系统模型时，它采用自顶向下分层解决的方法。

（3）模块化原则。模块化是结构化方法最基本的分解原则的具体应用，它主要出现在结构化设计阶段中，其目标是将系统分解成具有特定功能的若干模块，从而完成系统指定的各项功能。

2）.面向对象模型遵循的基本原则。面向对象模型遵循的基本原则有：抽象、封装、模块化以及层次原则等。

（1）抽象。抽象是处理现实世界复杂性的最基本方式，在OO方法中它强调一个对象和其他对象相区别的本质特性，对于一个给定的域确定合理的抽象集是面向对象建模的关键问题之一。

（2）封装。封装是对抽象元素的划分过程，抽象由结构和行为组成封装，用来分离抽象的原始接口和它的执行封装（也称为信息隐藏，Information Hiding），它将一个对象的外部特征和内部的执行细节分割开来，并将后者对其他对象隐藏起来。

（3）模块化。模块化是已经被分为一系列聚集的和耦合的模块的系统特性，对于一个给定的问题，确定正确的模块集几乎与确定正确的抽象集一样困难，通常每个模块应该足够简单以便能够被完整地理解。

（4）层次。抽象集通常形成一个层次，层次是对抽象的归类和排序。

在复杂的现实世界中有两种非常重要的层次，一个是类型层次，另一个是结构性层次。

确定抽象的层次是基于对象的继承，它有助于在对象的继承中发现抽象间的关系，搞清问题的所在，理解问题的本质。

3）.结构化方法的核心问题。模型问题是结构化方法的核心问题，建立模型简称建模，是为了更好地理解要模拟的现实世界。建模通常是从系统的需求分析开始，在结构化方法中就是使用SA方法构建系统的环境模型，然后使用SD方法确定系统的行为和功能，模型最后使用SP方法进行系统的设计，并确定用户的现实模型。

4）.面向对象方法的核心问题。面向对象方法与结构化方法一样，其核心问题也是模型问题。面向对象模型主要由OOA模型、OOD模型组成，其中OOA主要属于学科抽象形态方面的内容，OOD主要属于学科设计形态方面的内容。

参见：

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

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

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

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

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