早期的滴滴系统架构
这里存在的问题：
上下游依赖硬编码在代码里；
没有使用 inrouter/tgw 的 ip：Port；
摘除和扩容需要代码重新上线，inrouter 有网络链路稳定性隐患，以及效率上的损失；
没有清晰的服务目录，API 文档以及 SLA 和监控。
分布式 RPC 框架图
目标是把一些服务之间的调用能够通过规范化方式串联起来。上下游通过名字服务，从上游和下游端口解耦，名字服务需要在全公司统一且名字唯一。
Naming 服务就是做服务命名，服务注册和发现，到注册中心
RPC通道，部署私有协议，具备可扩展性
服务路由与容灾，动态路由，故障节点摘除
这里需要提醒的是，目前滴滴技术栈还不统一，所以导致中间件会复杂一些，应该最早期把技术栈统一，选择 Java 或者 Go 等，可以避免后续的问题。
服务命名要规范，服务名自描述，要构建统一服务树。为了效率和规范性，协议建议选择私有 RPC 协议。公有如 http 协议，测试方便，带来方便性的同时也带来的其他问题，就是容易被滥用。
服务路由建议是全局摘除，像机器一旦不可用就通知上游，及时摘掉，但也有一定的风险。如网络闪断，下面机器全挂，会导致所有服务都不可用。所以需在全员镇守情况下做全局确认，不要拖着整个服务，要从上游做决策，再换个IP，重新做一次。
分布式服务化改造的大团队协作，从单业务系统做分布式改造的一个出发点就是解决大团队分工和协作问题。代码的分支拆分，减少代码冲突，使得系统独立，打包和发布效率都会提高；部署独立，线上故障排查和责任认定会更加明确。
同时，带来的问题是依赖的不确定性增加，性能上的一些损耗。像一次请求，如果一下调来七八个请求，这也会带来一些问题，所以这个过程要有一定的合理性，就是公司现在处于什么阶段，现在需不需要拆分。所以系统、效率等方面要做一个平衡。
大流量系统的高可用迭代
大流量系统的架构实现高可用的策略部署，带有分组功能的一致性 Hash 的 Cache、静态内容前置到 CDN 和热点侦测等。
系统 APS 和服务层有五层代码
如上图，一个系统 APS 和服务层有五层代码，通过水平扩展加机器也解决不了问题。在业务层，没办法做水平扩展，必须做有状态的变化，部署带有分组功能的一致性 Hash 的 Cache。
为了具备更大的伸缩性需要把静态内容前置到CDN。
静态内容前置到 CDN
在服务端即使做扩展，量还是有限，读的请求，读的数据往前推，最终推到 CDN 上。CDN 体系比较多且有地域性，可抗百万级别的流量，但要解决冗余带来的时效性、一致性的问题。这样做带来的好处，除提高伸缩性，还节省带宽，节点分散，可用性更高。这里提醒下，CDN 可用性需要做评估，如不是自建，需要让提供 CDN 的供应商给出可用性指标，避免后续维系困难。
热点侦测
