随着业务的一直倒退，软件系统不可避免的走向熵增：复杂度越来越高、研发效率越来越差、稳定性逐步升高等。这时形象外围能力，走向平台化的路线成为很多零碎的首要抉择。笔者联合本人的教训，总结了平台化建设的几种思路，心愿对大家建设平台化有所帮忙。

平台化有以下长处

• 复用性强：复用外围逻辑，业务性能只在平台之上的业务层建设，升高建设老本；
• 研发效率高：平台服务作为通用能力基建，业务只须要关注需要，不必关怀平台底层简单能力实现；
• 升高复杂性：平台都有正当的职责边界和模块划分，对外开发的接口也都直观简洁；
• 稳定性：平台服务的稳定性是重中之重，个别有专门的团队保护，稳定性比个别的业务零碎强；

平台化建设几种形式

1、嵌入式

平台提供相似容器的性能，业务方以 Jar 包模式嵌入到平台当中，相似于传统的多个 war 包部署在 tomcat 中。这种实现形式平台提供通用能力接口和业务扩大点，业务方实现业务扩大点来实现业务逻辑。个别有对立的入口（比方 tomcat 提供的域名 + 端口），依据租户标识来辨别业务方（比方 tomcat 的 serverPath），平台底层的存储及模型中也都有租户 ID 标识。

劣势：

• 运维：平台对立运维，业务方工作量升高；
• 对外接口：对外对立接口，调用者的工作量会升高；

劣势：

• 业务方性能受限：个别不能做重量级工作，平台以扩大点形式提供给业务方扩大，除此之外的能力都应该被限度；
• jar 包抵触、类抵触问题：平台自身蕴含了很多依赖，业务方 jar 包也会有很多依赖，如果有抵触会导致整个平台不可用，下文会介绍几种躲避办法；
• 业务隔离性差：不同业务方之间可能相互影响；

解决业务隔离的罕用计划：

1. 每个业务方提供一个集群；
2. 应用类加载器隔离 jar 包，但可能仍然解决不了 jar 包抵触的问题；
3. 业务方提供 fatjar，更改所有依赖包的 package 门路，比方 MavenShadePlugin 插件；

2、接口依赖式

平台也能够通过近程依赖的模式来整合业务的性能。这样能防止 jar 包抵触、业务性能受限等问题。此计划也会有一些限度，比方原 jar 包依赖的形式都是本地调用，当初都是近程调用，对性能、事务保障等都提出了新的挑战；须要保障接口的兼容性；平台与业务的交互由原来对象交互变成 RPC 接口，设计到编解码等；

这种计划适宜平台与业务层交互较少、扩大点比拟固定的场景，比方 API 渲染服务，平台提供渲染模板接口，业务方实现接口填充字段。

劣势：

• 隔离性：平台和业务齐全隔离；
• 业务方不便整合其余业务：平台扩大点只是作为业务方的一种能力，能够在已有的服务上提供；

劣势：

• 接口变更简单：如果要变更接口，所有业务方都须要迭代；
• 交互简单：都是通过 RPC 交互，一些扩大字段须要编解码成 String 传输；
• 平台方兜底：如果业务方服务异样，平台方须要提供限流、降级、兜底的能力；

3、中台式

下面讲到两种模式都是以平台为主，对下层来说都是感知的平台，适宜交互接口比拟固定的场景，对交互差异性大的业务不是很适宜。中台式的思路是提供业务通用能力，业务方基于中台能力疾速开发本人的业务，并独立提供服务或页面。

中台和平台的区别：

• 视角不同：平台关注的是去重、整合；中台关注的是复用；
• 价值体现：平台间接对外提供服务，是一个性能大汇合；中台是其余产品的一部分，为了其余产品更好的提供服务；

劣势：

• 能力聚焦：只须要提供外围能力撑持，不关怀和用户交互；
• 复用性更强：平台不依赖业务的扩大点，而只是业务方到平台的单向依赖；

劣势：

• 个性化能力弱：因为没有扩大点，只提供通用能力；

平台化建设罕用模式

1、DSL 畛域个性语言

DSL（Domain Specific Language）是针对某一 畛域 ，具备 受限表白性 的一种计算机程序设计 语言。DSL 具备弱小的表现力，罕用于聚焦指定的畛域或问题。

在平台化建设中，DSL 个别用来屏蔽平台简单的业务逻辑，以 DSL 的模式对业务方裸露简洁能力接口。

比方十分有名的 Gradle，就是一种 DSL 表白，具备比 Maven 更灵便的个性，对于如何构建 DSL，请参考作者博客：应用 Groovy 构建 DSL

2、Specification 规约模式

Specification 模式用于解决「业务规定」相干的复杂性。

什么是业务规定呢？比方电商业务场景中须要判断：账户无效状态、是否是 VIP、流动价有效期、账户余额等。在惯例的代码开发中，有三种解决形式：

• 在业务流程代码中 case by case 的编写；毛病是会导致能力复用性、可维护性越来越差；
• 新建动态类，比方 OrderValidator、TimeValidator 等，毛病是解决组合逻辑（and、or）力不从心；
• 在模型类中校验，毛病是类中会掺杂越来越多的非畛域逻辑，这种逻辑太多会覆盖业务外围的业务规定；

Specification 模式认为校验逻辑都是“动作”，须要独自建模，且模型都是值对象，接口通用模式如下：

public interface Specification<T> {boolean isMatch(T domainObject);
}

通过实现 Specification 接口，咱们能够对不同的畛域对象扩大不同的校验逻辑，而这些类都是能够复用的。

同时这些 Specification 能够作为根底元素进行任意的组合，组合更为简单的校验规定与筛选逻辑。

当然Specification 不仅仅实用于过滤数据，它的外围是组装业务规定。例如 Spring Data JPA 提供了基于 JPA 的 Specification 模式的查问性能，应用起来十分不便，以下是一个示例：

 public List<Student> getStudent(String studentNumber, String name) {Specification<Student> specification = new Specification<Student>(){
            @Override
            public Predicate toPredicate(Root<Student> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
                // 用于临时寄存查问条件的汇合
                List<Predicate> predicatesList = new ArrayList<>();
                //equal
                if (!StringUtils.isEmpty(name)){Predicate namePredicate = cb.equal(root.get("name"), name);
                    predicatesList.add(namePredicate);
                }
                //like
                if (!StringUtils.isEmpty(nickName)){Predicate nickNamePredicate = cb.like(root.get("nickName"), '%'+nickName+'%');
                    predicatesList.add(nickNamePredicate);
                }
                // 最终将查问条件拼好而后 return
                Predicate[] predicates = new Predicate[predicatesList.size()];
                return cb.and(predicatesList.toArray(predicates));
            }
        };
        return repository.findAll(specification);
    }

3、异构

平台提供的通用能力如果不能间接满足业务的需要，须要提供扩大能力以适配业务模型来达到异构的目标。反对业务扩大模型个别有以下几种形式：

• String ext
• Map<String,String> ext
• Class：个别用于嵌入 jar 式

还有另外一个问题须要解决，平台作为通用能力，有平台本身的模型，如何将平台模型转换为业务模型？简略的做法是作为扩大点凋谢给业务方实现，不过作为业务方，应该关注的是业务模型，平台模型有本人的规定且平台为了通用化，模型都会非常复杂。

一个更欠缺的平台应该反对更灵便的异构模型反对，罕用是计划是字段配置化：

1. 在平台申请一个模型的定义，个别包含类型，长度，限度规定等（比方必须是正整数）；
2. 业务方配置字段和平台模型的映射关系，如果须要动静能力，可提供 Groovy 或 Aviator 等脚本反对；
3. 转换为业务方模型：依据用户配置，主动转换并给用户返回业务模型；
4. 转化为平台模型：参数中须要传入元数据类名，平台依照配置规定进行有效性校验；如果须要主动转化，则须要在配置服务反对双向映射

4、对立存储

平台除了平台通用模型的存储反对，还须要反对不能转换为平台模型业务模型存储。有以下几种计划：

1. 宽表：采纳列式存储引擎，可不便的创立、批改列，毛病是罕用的列式存储引擎个别不能提供的很好的事务反对；
2. 列转行：数据表只有三列：id、key、value，查问及存储时在 repository 层进行转换，毛病是不能 join、不反对批改列；实用于不太简单的业务场景；
3. 元数据：齐全接管数据库操作，依据不同字段格局主动存储到不同列，欠缺的元数据平台还反对分库分表、扩缩容、数据迁徙等能力，建设老本最高；

总结

平台化建设是一个非常复杂的工程，波及的业务方、计划抉择比拟多，难点和投入老本也都差别较大，没有一套完满的计划能笼罩所有业务场景，本文提供了几种参考计划和设计模式，具体的计划还须要读者联合本人的业务场景来筛选最适宜本人的计划。

作者简介：木小丰，美团 Java 技术专家，专一分享软件研发实际、架构思考。欢送关注公共号：Java 研发
本文链接：平台化建设思路浅谈