私有化交付订制代码问题

        从第一篇文章发布以来，本想一口气写下去，哪知道这学期MBA的课程安排的满满当当，又是异地求学，一到周末就开启双城生活，除了学习还有做不完的工作，于是断更了一段时间。趁着最近放暑假，没有学业的影响，抓紧时间继续更新。

        从笔者这几年的经历来，首先遇到的是私有化交付的订制代码问题，接着是SaaS软件的不停机发布，一直到近期信创适配等等。按照时间顺序，先从私有化交付的问题说起。

        SaaS软件迎来客户以后，逐步开始遇到了行业内常见的一个 问题——一些客户会要求产品私有化部署。私有化部署不难，难的是私有化部署的客户中有80%有订制代码的需求。于是带来了以下问题：

1. 订制版本与SaaS版本如何维护？
   订制版本会带来订制代码与SaaS代码冲突问题。
   订制版本会带来数据库表结构与SaaS版本表结构不一致问题。
   订制版本上面，部分客户会有自己的技术要求。比如：你的软件使用Redis5集群模式，客户由于自身原因，要求使用Redis6哨兵模式等等。
2. 客户看到SaaS新版本功能后，要求订制版本页更新SaaS功能。如何实现更新？
   比如SaaS软件当前是1.2.0，客户购买私有化部署后，在上面做了一些订制代码的开发。
   一个月后，SaaS软件更新到1.4.0。客户看到SaaS软件上某个功能比较实用，软件又在维保期，客户提出了升级的需求。如果订制代码和SaaS代码冲突，那么升级功能过程中，合并的代码就是一件痛苦的事情。
   同样的问题，定制化代码也会带来数据库表结构的冲突，也是升级功能过程中面临的问题。

         以上只是在私有化交付过程的部分问题，实际上还会有更多的问题，比如：近几年的信创适配要求等等，先讲讲我们是如何解决私有化代码订制问题。             

        最初我们的SaaS软件架构成熟度并不高，软件的功能对客户来说具有吸引力，但是一旦涉及到订制代码就比较困难了。我们最初的想法是，既然客户对于SaaS软件来说，一个客户就是一个租户(这里见上一篇文章)，我们单纯的认为，针对租户在A端对他进行配置，针对租户A配置这个接口走方法A，针对租户B走方法B，走不同的实现即可完成订制代码的交付。但是实践证明私有化部署订制需求非常多，这种方式配配置可能会成百上千。所以我们以其他方式来实现这种订制效果。

        下面以一个简单的示例来说明，比如SaaS标准功能是将访客信息保存到CRM系统，以便后续销售跟进线索。这个时候客户A要求订制代码在保存访客信息的时候，与客户A自己的客户系统通信，补全访客的一些属性。比如，客户如果是金融行业，那么就会有合同号等信息，并且处于安全考虑，最后访客信息落地并不会存储到我们自己的CRM系统，而且加密后传输给客户A，由客户A存储到它自己的系统里面。按照我们最初的想法，设计如下。

         SaaS标准的业务流程，客户访问系统的时候咨询业务，留下联系方式等线索，数据存储到我们的CRM数据库，待后续业务跟进。

        这个时候，客户A要求，客户留下的线索需要和客户A自己的系统通信，获取合同号。那么业务流程就是如下：

         可见，多了一步从客户A系统获取合同号。这部分代码在SaaS上是没有的，而在私有化交付环境是必须要的。代码肯定要有订制需求的实现。

         由上图，TenantACrmServiceImpl是针对客户A的订制代码实现，如何让业务流程执行的时候执行这段代码呢？答案是SPIService Provider interface），对于SPI不做详细解释，网上资料一大片，具体解决方案如下：

        SaaS开发人员在进行设计的时候，所有的业务Service均是以接口 (interface)和实现类(implement)方式设计，SaaS上面按照标准需求实现（CrmServiceImpl），遇到类似客户A要求私有化部署，并且有订制代码的时候怎么办呢。我们的SaaS软件是基于SpringCloud微服务架构的，SaaS开发人员会将代码打包成jar包(不包括带有@SpringBootApplication或@SpringCloudApplication的启动模块)。因为交付开发人员会有订制代码开发，由他们去完成最后的启动模块，这样可以把他们自己开发的代码模块扫描进来。

        交付人员拿到SaaS的jar包后，针对上面客户A的订制需求，他们会开发订制代码(TenantACrmServiceImpl)，这样在META-INF/services配置他们自己的实现类，即可实现订制代码的开发。这样解决了订制代码的问题，同时在客户现场更新SaaS版本的功能，只要SaaS能够保证接口版本的兼容性，那么交付现场只需要更新标准jar包即可。

        另外，对于订制代码关联的数据库表结构变动问题，根据多年的经验，客户的需求对于表结构的变动一般只需要增加字段即可。解决方案对于大部分企业来说当然不可能采用Salesforce的方案，该方案的对架构底层和数据库底层要求非常高。既然知道了客户的需求一般只是增加字段，那么就好办了。新增字段通过扩展表的方式和原表关联上，既然有了SPI的解决方案，那么上面是Service层的示例，Dao层依然可以实现，这样在更新SaaS标准版本功能的时候，原表字段的增加，修改等操作，对于订制需求的扩展表也是无影响的。

        以上的方案只是解决订制需求的基本方案，订制需求多种多样，针对新增需求还可以采用低代码平台进行快速开发，针对原有代码的订制可以采用以上方法。成熟的SaaS软件针对订制需求有很多解决方案，比如下面 ：        

        

         详细架构图就不放了，方案较多，主要是实现的思路。根据自身产品业务，抽象出原子能力层，在此基础上根据业务能力，抽象出业务API。在业务能力上构建自己的SaaS标准产品，针对SaaS的客户订制需求也可以通过API接口快速构建。在私有化部署的时候，API和能力层也可以部署过去，这样针对客户的订制代码，可以通过现有API实现，对于部分需求API可能不完善，也可以通过SPI的能力实现。

        目前整个IT行业如低代码平台、流程编排等工具和方案较多，要实现订制代码和SaaS代码不冲突，版本管理清晰还是比较容易的。