经过几个月业务的沉淀，明确出几个具体的业务方向，原本的架构已经不适合现在的项目。
下面从几个方向介绍我们的切换思路：
1、原本架构存在几个问题
- 网关层：随着业务的发展，由原本的APP到后面的微信公众号、小程序，网关层由于各渠道鉴权、分发、限流等不同，网关层逐渐复杂，经过各种渠道判断等，网关层效率变低；
- 服务层：基础业务层由于业务增多，营销、运营、用户等业务全部编写在里面，基础业务层开始臃肿，代码各种交错，代码维护性差；由于服务未完全拆分，容易出现服务冗余，比如：获取用户信息会出现多段代码；
- 配置文件：各工程配置文件相互独立，且测试环境与生产环境变更需要频繁维护，配置文件修改后需要重启，且各个研发人员本地都存一份，配置文件维护成本较高，且问题率也较高；
2、架构设计
重新设计后架构如下：
业务架构如下：
主要优化的几个方向：
- 网关层： 新增小程序、公众号网关，各网关间实现解耦，各网关实现各自鉴权、分发、限流体系，减少网关层逻辑判断，提升网关层效率；
- 聚合平台层：新增聚合平台层，聚合平台层只关注业务，不做任何数据操作，各平台间互相解耦，最大程度提升代码利用率；
- 业务中台层：新增业务中台层，业务中台层不关注业务，只提供基础数据操作，提供业务接口供各平台使用，例如：获取商品信息，各个平台只需从产品服务中调用，业务中台层各接口实现公用化；
- 配置中心： 新增配置中心，配置中心选型携程Apollo，支持可视化配置，且配置后可实现动态加载，配置中心利用率高，问题率低；
经过上面架构的整改，实现整个业务中台的理念，当然底层各个细节实现都需要考量、设计，在架构之外，服务熔断、服务追踪、日志分析、容器化等都可以考虑引入，增强系统的高可用。
