大中台应用的层次抽象

问题引入

• 一个单体中台应用要支持的业务越来越多，必然要引入各种业务第三方jar包，用来支持不同功能。

• 且这些业务jar包，可能由于不同业务需求而有不同的配置、版本、特性能力。

所以这必然导致单体应用越来越大，且业务jar包引入的越多，jar冲突的可能就会出现，且越来越多。最后应用的构建、启动可能就会越来越慢。

庞然大物需要变小，且也要服务好所有业务

以一个应用依赖不同中间件例子说明

如上，传统做法是必须要兼容升级，最后保留一个fastjson版本。但是有没有可能是各用各的互不打扰呢？

参考文档：https://doctording.blog.csdn.net/article/details/114760787

思考 - 加中间层

即没有什么问题是不能通过增加一个抽象层解决的

作为一个独立的平台应用，应该要保持自己的核心功能模块，也要满足不同业务方的需求。

显然一层的架构无法满足，那么就是再加一层，一层不够就再加

最后抽象出如下层：

有一些通用能力可以沉淀，大家都用的是一样的。比如类似各个公司通用的账号密码加密服务、公司的审批服务，员工信息服务等

平台层：仍然负责主要的业务逻辑

业务层：即业务自己的扩展逻辑，其中可以有自己业务的特定逻辑，依赖也是自己的，不与其它业务干扰。

---

当你的业务需要给别人使用时，则业务之间存在依赖关系了，如下：