详解互联网APP架构2.0

详解互联网APP架构1.0

详解互联网APP架构2.0

经过几个月业务的沉淀,明确出几个具体的业务方向,原本的架构已经不适合现在的项目。

下面从几个方向介绍我们的切换思路:

1、原本架构存在几个问题

  • 网关层:随着业务的发展,由原本的APP到后面的微信公众号、小程序,网关层由于各渠道鉴权、分发、限流等不同,网关层逐渐复杂,经过各种渠道判断等,网关层效率变低;
  • 服务层:基础业务层由于业务增多,营销、运营、用户等业务全部编写在里面,基础业务层开始臃肿,代码各种交错,代码维护性差;由于服务未完全拆分,容易出现服务冗余,比如:获取用户信息会出现多段代码;
  • 配置文件:各工程配置文件相互独立,且测试环境与生产环境变更需要频繁维护,配置文件修改后需要重启,且各个研发人员本地都存一份,配置文件维护成本较高,且问题率也较高;

2、架构设计

  重新设计后架构如下:

  业务架构如下: 

  主要优化的几个方向:

  • 网关层: 新增小程序、公众号网关,各网关间实现解耦,各网关实现各自鉴权、分发、限流体系,减少网关层逻辑判断,提升网关层效率;
  • 聚合平台层:新增聚合平台层,聚合平台层只关注业务,不做任何数据操作,各平台间互相解耦,最大程度提升代码利用率;
  • 业务中台层:新增业务中台层,业务中台层不关注业务,只提供基础数据操作,提供业务接口供各平台使用,例如:获取商品信息,各个平台只需从产品服务中调用,业务中台层各接口实现公用化;
  • 配置中心: 新增配置中心,配置中心选型携程Apollo,支持可视化配置,且配置后可实现动态加载,配置中心利用率高,问题率低;

        经过上面架构的整改,实现整个业务中台的理念,当然底层各个细节实现都需要考量、设计,在架构之外,服务熔断、服务追踪、日志分析、容器化等都可以考虑引入,增强系统的高可用。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

斑马工

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值