今天看到一篇文章《YARN或将成为Hadoop新发力点》，讲解Hadoop问题，以及YARN的解决方案。作为多年系统架构设计人员来说，这是个很挑战的命题。
这个博客有点标题党的意味，但仍然会作为一个严肃的技术问题来讨论。
首先，要界清怎样才算是一个大规模的系统。我认为有这么几点：
1、服务于大量终端，百万、千万甚至更多。
2、系统包含大量数据，GB/TB/PB。
3、业务逻辑多样而且复杂。主要体现在业务数据多类型，业务和数据之间有依赖，才算复杂。
4、单事务时延容忍度低。一个事务拖个小时级别，基本有很多方案可以选择。但是到了毫秒就会是个非常艰巨的任务，要是要微秒级别，那么极有可能是传说，也许只有等到基础设施有极大飞跃的时候，才有可能。
我们看到，YARN的核心改进是“通过YARN管理集群的资源请求，Hadoop从一个单一应用程序系统升级成为一个多应用程序的操作系统”。这个改进，相当于从WIN95升级成WINNT，从单核CPU变成多核CPU。
应对大规模系统的不二原则，就是并行，将一个大数据、大计算进行切割成局部系统。对于基于网络的应用来说，网络传输是仅次于磁盘IO的瓶颈。因此，才衍生出分布式缓存和内存数据库等项目。大规模的批量处理系统衍生出Hadoop，大型的数据存储，衍生出GFS等。
我们假定有个系统，类似于谷歌、FaceBook、淘宝之类的。有大量的客户请求，有海量的数据存储，有复杂的业务逻辑，需要毫秒级的响应。那么如何设计内部系统来应对这种情况呢？有这么几个要点：
1、我们为每个资源定义一个访问路径：A.B.C.D....。这个资源包括服务、计算节点、存储甚至内存等。
2、我们有一个资源管理系统，来管理这些资源。也管理这些资源的真实访问方式，比如IP。
3、考虑到网络传输代价，跨数据中心、跨机柜、跨机器之间的传输应该尽量被避免。就是资源局部化原则。
4、资源寻址、调度和真实的数据传输必须在不同的渠道中完成。这点和消息总线是有差别的。
寻址和调度，要求快速的完成，但数据的传输是很难控制的。
见下图：
每一个资源，将名称和具体访问方式通过访问代理注册到资源管理器。当这个资源被具体访问时，如果是同类资源，资源管理器可以同时兼任调度功能。每个访问代理同时也向资源管理器汇报自身和所管理资源的状态，实时向资源管理器汇报。资源管理器也实时向访问代理更新他所关联的资源状态。
