产品-项目型适配式系统开发之一：理念和设计

一．背景

在系统开发过程中，尤其是涉及到系统集成性软件开发过程中，我们经常会碰到类似这样的场景：团队中已经有一个产品化的软件系统，但该软件系统需要按照项目型进行实施，而每个项目由于面向不同客户在某一些产品组件上可能都会有其一定的独特性。这些特定的产品组件往往涉及到系统集成，由于集成技术和方案的不同而需要进行二次开发，如下图所示：

从上面的组件图中我们可以看到在产品系统中，部分产品组件（图中为产品组件A和B）的运行将依赖于系统集成组件，而系统集成组件的实现将视项目而定，图中的项目实现1、2和3分别对应了三个不同客户项目的要求，在实施过程中，通过组合产品组件和不同项目线的系统集成组件实现达到系统集成的需求，这也是这类场景的典型需求，本文中我们称之为产品-项目型系统。

二．设计理念

针对产品-项目型系统开发，为每个项目都保存和维护一份完整的代码显然是低效和不符合产品化策略的。通常我们都会对涉及的不同项目系统集成部分进行抽象，如上图中的我们把系统集成组件梳理成一套集成接口，通过实现该套集成接口完成对不同项目可变部分的适配。产品-项目型系统设计的基本目标就是完成系统标准组件与可变组件之间的分离，但同时也要梳理一些其他因素，确保结构的完整性和高效性。

1.      产品组件标准化

对产品-项目型系统而言，首先需要确保各种产品组件的标准化，即产品组件的业务逻辑和流程对所有项目而言都应该是统一的。要做到产品组件的标准化，需要对系统业务有较高的抽象，通常都会涉及到抽取标准的流程、接口和数据交互格式。标准化的产品组件是稳定、高效和没有bug的，如果一旦这些产品组件不能满足项目线的需求，则需要对其进行升级，但这种升级的频率应该远远低于系统集成组件的修改频率。

2.      系统集成组件模块化

系统集成组件是可变部分，可变的是针对具体项目的系统集成方案和技术实现方法，但对产品组件而言，系统集成组件的接口和数据交互格式应该是标准的，以便和产品组件进行无缝整合。通常我们会提供一套默认的系统集成组件实现，如果项目上能直接使用默认实现就直接使用，如果不能就开发定制化的系统集成组件。

系统集成组件的设计过程中要基于模块化思想，因为产品组件流程会依赖不同的系统集成接口。由于业务流程的不同可能导致系统集成接口的服务提供方也是不同，而目前市面上存在多种系统集成技术，无论从服务调用方式，数据传输机制、结构封装等方面都有所不同。确保系统集成组件的独立性和模块化是实现集成服务有效管理的基础，对于多数情况下接口级别的系统集成而言，这点还是比较容易把握的。

3.      数据推拉模式

数据推拉模式有两个维度：站在产品组件的角度和站在系统集成组件的角度。对系统集成组件而言，推模式是指具体项目中的服务提供者调用系统集成组件开放的标准服务来通知某些事件的发生，拉模式则是系统集成组件主动调用服务提供者的服务进行信息获取。对产品组件而言，推模式是指系统集成组件在特定事件发生时通过消息中间件来通知产品组件，而拉模式则是产品组件主动向系统集成组件发起请求并等待响应。

具体在两个维度上使用何种模式需要视情况而定，系统集成组件的推模式往往是一种优化的实现，但需要我们提供额外的服务供项目线调用，从而促使系统集成组件和项目线既是服务消费者又是服务提供者，双方都会有额外的接口及其维护成本，项目线并不一定能实现这种推模式，所以很多时候都只能使用拉模式；产品组件的推模式会对系统开发有一定要求和成本，但可以应对一些用户对实时性要求比较高的场景，由于产品组件和系统集成组件都是由我们开发，所以不存在技术实现方式上不可行的情况。

4.      数据传输和保存

对系统集成而言，由于各个服务提供者的技术实现以及网络传输等环境上的差异化，可能会存在性能上的问题。面对性能问题，服务提供者的数据传输通常无法控制，但可以采用特定数据格式来减少产品组件和系统集成组件之间数据的传输量。另一方面，对于静态或者相对静态的数据而言，在系统集成组件中使用缓存进行数据保存也是常用的策略。

三．设计方案

设计方案上我们从系统集成角度出发梳理关注点和细节。对于产品-项目型系统开发而言，我们希望达到的目标是保持产品组件稳定，通过适配来自项目线的不同服务实现达到系统动态组装的效果，从而为不同的项目构建出适合该项目的完整系统。对产品组件而言，关注的是系统业务逻辑，本文中不展开讨论，我们来看一下系统集成组件：

1.      系统集成组件功能

系统集成组件的主要任务是完成来自项目线的服务适配，同时，作为系统中可变部分需要确保自身服务的稳定性和数据的可靠性。系统集成组件包含以下几个主要方面：

• 标准化服务定义：系统集成组件对外的服务格式必须统一才能确保与产品组件进行适配，首先需求确定服务定义的格式和传输方式，如是使用Web Service等主流的系统集成方案还是采用自定义方案。定义标准化服务的难点是通过对系统业务逻辑的理解，抽象出标准化服务的数量和结构定义，这需要具体问题具体分析。
• 数据验证：对服务提供者发送的请求进行删选和过滤，只有真实的业务请求数据才能经由系统集成组件流转到产品组件。
• 数据转换：对于产品组件和系统集成组件两端而言，数据格式是透明的，但项目线各自系统以自己的特有数据格式来对系统集成组件进行请求和回应，这就需要对这些特有的数据进行转换。数据转换包括两个方面：数据格式转换和数据内容转换。服务提供者提供的常见格式有数据库视图、XML、Json等，数据格式转换需要对其转换为标准化服务所需要的格式。另一方面，服务提供者提供的服务中可能因为字段数量、含义等的差异性，不能完全适配到标准化服务，我们也需要对这些字段进行内容转换，确保每个字段都能符合标准化服务中的业务定义。
• 数据传递：数据传递方式上需要考虑数据的推拉模式，也可以引入回调等手段，但本质上还是要看业务的场景和性能上的需求。系统解耦是产品组件和系统集成组件之间需要考虑的一个切入点，使用各种消息中间件技术可以提供系统的扩展性，消息异步回调也能提升性能和用户体验。
• 数据存储：系统集成组件在分层上有时候只是充当比较单纯的转化层功能，但有时候也是作为一个单独的子系统进行运作，具有本地的数据存储功能。数据存储可以是持久化的数据库存储，也可以是内存中的缓存处理。
• 系统监控：系统集成组件作为可变部分，通常都应具备高于产品组件的监控功能，因为服务提供者的运行情况可能存在波动，这些波动也可能影响到产品组件的正常运行。通过系统日志、异常分析等手段追踪问题的来源，便于发现系统的瓶颈。

2.      系统交互方案

我们以系统集成组件为中心设计系统交互方案如下：

• 标准服务使用拉模式调用服务提供者提供的服务并完成适配，如果服务提供者支持使用推模式进行交互，那服务提供者也能调用标准服务进行数据推送。
• 产品组件使用拉模式调用标准服务完成系统组装，同时标准服务也可以使用推模式与产品组件进行交互，这时通常采用基于事件处理机制的消息中间件
• 标准服务可以使用数据存储进行数据的保存

上述交互方案包含了系统集成组件的完整接口，可以根据具体项目线上的实现方案进行裁剪。

四．小结

在实际开发过程中，本文提出的产品-项目型适配式系统开发模式具有一定的代表性。不管采用何种叫法，其本质是系统可变部分和不可变部分的抽象和解耦，不仅仅可以应用于系统集成领域，也可以扩展到系统设计和开发的方方面面。本文对这一思路的基本理念和设计进行了说明，后续会进一步阐述具体的实现方式和持续集成等主题。