移动端API架构 统一Proxy还是各自为政?

今天首先回答上一篇的问题:

为什么APP通过运营商接入网络,连通率会那么差?

1. 域名缓存问题

运营商的localdns会缓存域名的解析结果,不向权威DNS递归查询解析

为什么要这么干呢?

1)运营商之间的跨网流量结算费用比较贵(他们内部技术团队的KPI),为了最大化的在本网消耗(内部结算好算),减少跨网结算,所以会把IP地址解析到自己的内容缓存IP地址

2) 推送广告,有利可图。把内容缓存替换为第三方联盟广告.

2. 解析转发问题

部分小运营商图省事,不进行域名的递归解析,而是把解析请求转发到其他运营商的LocalDNS上,导致调度出现问题,跨网调度,最后影响的就是耗时,当耗时足够大时,连通性就没法保障了

3. LocalDNS递归出口NAT导致调度不准

LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归,但是因为在网络上存在多出口且配置了目标路由NAT,结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址,跨网的影响如上

 

所以基于以上的原因,APP端对服务器端API的连通性就会损失个5%左右.

解决方案请见上文<移动端API接口优化的术和结果>

 

今天来讲另一个话题:

移动端API架构 是该统一Proxy还是各自为政?

我经历过几家公司,有把所有的service放到一个域名下的,也有按业务的不同来拆分为不同域名服务的

如:
api.baidu.com/msg
api.baidu.com/user
api.baidu.com/search
也有如:
msg.baidu.com
user.baidu.com
search.baidu.com

 

 对应内部的架构也会是两个样子

移动端API架构 统一Proxy还是各自为政?_第1张图片 

今天我们就来聊一下,仅仅从架构层面来说到底是有红色Proxy部分好呢还是没有好?

一般的初创公司,甚至到中型互联网技术公司,很多人都在用分拆域名的方式来分拆业务,这样做好处是什么?

一般在一家创业公司驱使按域名分业务分拆后端API始于团队和人员的发展,他们期望各业务负责人只需要关注自己的业务,业务间没有关联关系,即便在最终产品上各业务会有先后依赖关系,如消息服务(msg service)依赖user service,也都是整体由客户端来串逻辑,研发msg service的同学与user service的同学可以不用交流或者少交流,已到达各业务开发团队齐头并进的效果。出了问题呢,也能很快的定位是哪个api的service挂了,每个团队维护好自己的服务, 干好自己的事情. 

在这个阶段的公司,这也是个不错的方案能够让多个团队齐头并进.

但是对于大的互联网公司,或者有技术追求的技术公司,这并不是最理想的方案,为什么呢?

我们来看看按域名分拆业务带来的问题:

1. 流量监控等方案需要在各个业务做

2. 安全性, 防攻击等相关问题需要各个业务团队完成

3. 不利于统一管理,需要给每个业务配备对应的运维人员(绝大部分这种架构的公司op也是这么配备的)

4. 扩容 缩容 熔断 等高可用相关的基础方案难复用

 

这里面最重要的是流量监控和容量规划,在同一的proxy层做监控能够让人非常快速的知道系统故障时问题在哪,哪个服务的耗时增加了,哪个服务开始出现500了. 如终端报bug消息出不来了,到底是msg service还是user service的问题,一目了然;同时统一的扩容 缩容以及服务降级的联动,都好做了,运维工程师的幸福生活由此展开.

当然,这并不是唯一的方式,使用分拆域名然后把各个监控数据汇集到一块也能做,但是成本变高了.

 

你可能感兴趣的:(移动端API架构 统一Proxy还是各自为政?)