移动端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

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

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

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

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

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

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

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

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

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

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

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

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

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