移动端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的问题，一目了然；同时统一的扩容 缩容以及服务降级的联动，都好作了，运维工程师的幸福生活由此展开.

固然,这并非惟一的方式，使用分拆域名而后把各个监控数据聚集到一块也能作，可是成本变高了.