问题引入
-
一个单体中台应用要支持的业务越来越多，必然要引入各种业务第三方jar包，用来支持不同功能。
-
且这些业务jar包，可能由于不同业务需求而有不同的配置、版本、特性能力。
所以这必然导致单体应用越来越大，且业务jar包引入的越多，jar冲突的可能就会出现，且越来越多。最后应用的构建、启动可能就会越来越慢。
庞然大物需要变小，且也要服务好所有业务
以一个应用依赖不同中间件例子说明
如上，传统做法是必须要兼容升级，最后保留一个fastjson版本。但是有没有可能是各用各的互不打扰呢？
参考文档：https://doctording.blog.csdn.net/article/details/114760787
思考 - 加中间层
即没有什么问题是不能通过增加一个抽象层解决的
作为一个独立的平台应用，应该要保持自己的核心功能模块，也要满足不同业务方的需求。
显然一层的架构无法满足，那么就是再加一层，一层不够就再加
最后抽象出如下层：
有一些通用能力可以沉淀，大家都用的是一样的。比如类似各个公司通用的账号密码加密服务、公司的审批服务，员工信息服务等
平台层：仍然负责主要的业务逻辑
业务层：即业务自己的扩展逻辑，其中可以有自己业务的特定逻辑，依赖也是自己的，不与其它业务干扰。
当你的业务需要给别人使用时，则业务之间存在依赖关系了，如下：
