移动端API架构 统一Proxy还是各自为政? - 大熊先生|互联网后端技术 - 博客园http://www.cnblogs.com/Creator/p/5506095.html
我经历过几家公司，有把所有的service放到一个域名下的，也有按业务的不同来拆分为不同域名服务的
api.baidu.com/msg
api.baidu.com/user
api.baidu.com/search
也有如：
msg.baidu.com
user.baidu.com
search.baidu.com
对应内部的架构也会是两个样子
一般的初创公司,甚至到中型互联网技术公司，很多人都在用分拆域名的方式来分拆业务，这样做好处是什么？
一般在一家创业公司驱使按域名分业务分拆后端API始于团队和人员的发展，他们期望各业务负责人只需要关注自己的业务，业务间没有关联关系，即便在最终产品上各业务会有先后依赖关系，如消息服务(msg service)依赖user service，也都是整体由客户端来串逻辑，研发msg service的同学与user service的同学可以不用交流或者少交流，已到达各业务开发团队齐头并进的效果。出了问题呢，也能很快的定位是哪个api的service挂了，每个团队维护好自己的服务, 干好自己的事情.
在这个阶段的公司，这也是个不错的方案能够让多个团队齐头并进.
但是对于大的互联网公司，或者有技术追求的技术公司，这并不是最理想的方案，为什么呢？
我们来看看按域名分拆业务带来的问题：
- 流量监控等方案需要在各个业务做
- 安全性, 防攻击等相关问题需要各个业务团队完成
- 不利于统一管理，需要给每个业务配备对应的运维人员（绝大部分这种架构的公司op也是这么配备的）
- 扩容 缩容 熔断 等高可用相关的基础方案难复用
这里面最重要的是流量监控和容量规划，在同一的proxy层做监控能够让人非常快速的知道系统故障时问题在哪，哪个服务的耗时增加了，哪个服务开始出现500了. 如终端报bug消息出不来了，到底是msg service还是user service的问题，一目了然；同时统一的扩容 缩容以及服务降级的联动，都好做了，运维工程师的幸福生活由此展开.
当然,这并不是唯一的方式，使用分拆域名然后把各个监控数据汇集到一块也能做，但是成本变高了.
