xl_echo编辑整理，欢迎转载，转载请声明文章来源。更多IT、编程案例、资料请联系QQ：1280023003 
 百战不败，依不自称常胜，百败不颓，依能奋力前行。——这才是真正的堪称强大！！
 
 
Spring 是一个开放源代码的设计层面框架，他解决的是业务逻辑层和其他各层的松耦合问题，因此它将面向接口的编程思想贯穿整个系统应用。
Spring MVC 属于SpringFrameWork的后续产品，已经融合在Spring Web Flow里面。Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块。
Spring Task 是一个定时任务框架。应用：定时执行刷新Redis数据。定时执行删除过期数据
Spring Security 是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI（控制反转Inversion of Control ,DI:Dependency Injection 依赖注入）和AOP（面向切面编程）功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。
Spring Data 是Spring 的一个子项目， 旨在统一和简化对各类型持久化存储， 而不拘泥于是关系型数据库还是NoSQL 数据存储。
SpringDataSolr 是一个搜索解决方案，基于Lucene的搜索服务器。应用：站内产品搜索
Spring Boot 是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。
Spring Cloud 是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

 
 
 转载请注明出处：
 
 http://blog.fens.me/hadoop-family-roadmap/
 
 
 
 
 
 
 
 
 
 
 Hadoop家族产品
 
 
 截止到2013年，根据cloudera的统计，Hadoop家族产品已经达到20个！
 http://blog.cloudera.com/blog/2013/01/apache-hadoop-in-2013-the-state-of-the-platform/
 
 
 
 一句话产品介绍:
 
 Apache Hadoop: 是Apache开源组织的一个分布式计算开源框架，提供了一个分布式文件系统子项目(HDFS)和支持MapReduce分布式计算的软件架构。
 Apache Hive: 是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
 Apache Pig: 是一个基于Hadoop的大规模数据分析工具，它提供的SQL-LIKE语言叫Pig Latin，该语言的编译器会把类SQL的数据分析请求转换为一系列经过优化处理的MapReduce运算。
 Apache HBase: 是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
 Apache Sqoop: 是一个用来将Hadoop和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库（MySQL ,Oracle ,Postgres等）中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。
 Apache Zookeeper: 是一个为分布式应用所设计的分布的、开源的协调服务，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，简化分布式应用协调及其管理的难度，提供高性能的分布式服务
 Apache Mahout:是基于Hadoop的机器学习和数据挖掘的一个分布式框架。Mahout用MapReduce实现了部分数据挖掘算法，解决了并行挖掘的问题。
 Apache Cassandra:是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存简单格式数据，集Google BigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身
 Apache Avro: 是一个数据序列化系统，设计用于支持数据密集型，大批量数据交换的应用。Avro是新的数据序列化格式与传输工具，将逐步取代Hadoop原有的IPC机制
 Apache Ambari: 是一种基于Web的工具，支持Hadoop集群的供应、管理和监控。
 Apache Chukwa: 是一个开源的用于监控大型分布式系统的数据收集系统，它可以将各种各样类型的数据收集成适合 Hadoop 处理的文件保存在 HDFS 中供 Hadoop 进行各种 MapReduce 操作。
 Apache Hama: 是一个基于HDFS的BSP（Bulk Synchronous Parallel)并行计算框架, Hama可用于包括图、矩阵和网络算法在内的大规模、大数据计算。
 Apache Flume: 是一个分布的、可靠的、高可用的海量日志聚合的系统，可用于日志数据收集，日志数据处理，日志数据传输。
 Apache Giraph: 是一个可伸缩的分布式迭代图处理系统， 基于Hadoop平台，灵感来自 BSP (bulk synchronous parallel) 和 Google 的 Pregel。
 Apache Oozie: 是一个工作流引擎服务器, 用于管理和协调运行在Hadoop平台上（HDFS、Pig和MapReduce）的任务。
 Apache Crunch: 是基于Google的FlumeJava库编写的Java库，用于创建MapReduce程序。与Hive，Pig类似，Crunch提供了用于实现如连接数据、执行聚合和排序记录等常见任务的模式库
 Apache Whirr: 是一套运行于云服务的类库（包括Hadoop），可提供高度的互补性。Whirr学支持Amazon EC2和Rackspace的服务。
 Apache Bigtop: 是一个对Hadoop及其周边生态进行打包，分发和测试的工具。
 Apache HCatalog: 是基于Hadoop的数据表和存储管理，实现中央的元数据和模式管理，跨越Hadoop和RDBMS，利用Pig和Hive提供关系视图。
 Cloudera Hue: 是一个基于WEB的监控和管理系统，实现对HDFS，MapReduce/YARN, HBase, Hive, Pig的web化操作和管理。
 

  

 
 

 
 

 

 
 
 
      Spring家族很庞大，从最早先出现的服务于企业级程序开发的Core、安全方面的Security、到后来的作为各种数据源桥梁的Data、最近几年很火的Boot，以及最新推出的正在蓬勃发展的Cloud（在本文之后都简单称为Boot、Cloud省略Spring节省一点我的打字时间?）。
 
      上面这个脑图给出了Spring家族主要的一些成员，右侧非Cloud部分列的是功能，左侧Cloud部分虽然组件繁杂，但是结构清晰（确实新版本清晰多了，命名也统一，你可以放大图片看一下这些是否熟悉），所以更进一步列出了组件要的一些模块依赖和开启功能的主注解。
 
0.Spring的发展
 
Spring框架几乎涉及到了Java企业级服务开发的所有方面，也几乎针对所有开发常用的模式、中间件、数据库进行了整合适配。
 
之前在聊互联网架构模式的时候我谈到过，很多时候我们写一个业务把逻辑写死写出来是比较容易的，但是把这个逻辑提取成模式进而打包成一个框架来给大家使用，这是比较难的。因为我们只有经历过足够多的场景后才能提取出普适的功能框架，大部分人才能用上，而且我们需要针对核心功能开放出可配置的部分，满足小部分人进一步定制和扩展功能的需要。
 
Spring框架经历了几个阶段：
 
1.第一个阶段推出的Core、Security、Data是把单体应用开发服务好。不仅仅提供了便捷的数据库访问、Web MVC等必要功能，而且通过AOP、IOC两大利器让我们的程序内在能够做到低耦合可扩展。
 
2.第二个阶段推出的Boot的意义不仅仅是加速了开发效率而且能让我们的程序从可用变为好用，应用程序核心业务逻辑可能只有70%的工作量，要让程序在线上跑的愉快还有30%的监控日志打点等工作量需要去做。
 
3.第三个阶段推出的Cloud的意义在于推动了微服务架构的落地。让不具备开发微服务基础套件的小型互联网公司也能享受到免费的开箱即用的微服务解决方案。其实很多人不是看了微服务的架构思想去寻找解决方案，而是了解到了Spring Cloud才去了解微服务思想从而落地的。
 
4.目前属于第四个阶段，大力发展Cloud Dataflow+容器。Dataflow的思想是不管是做实时消息处理的服务还是临时运行的任务，都可以认为是服务的组件，如果可以有一套DSL来定义这些组件之间的交互方式，然后在容器中进行自由组合、部署、伸缩，那么架构会非常灵活。下图是Dataflow管理界面的一个示意图。
 
 
      Spring的发展可以看到互联网架构的发展，Spring给我们带来相当多的技术启发，从软件设计模式的启发慢慢到了架构的启发，甚至我觉得Spring是为Java开发打造了架构风格的模板，接下去Spring继续发展2到3年有望成为架构标准，我在想这个时候应用架构师何去何从？
 
1.Spring Core
 
        Spring Core提供的IOC、AOP功能已经变为半个Java命根子了。其实很多开发平台并不是那么强调IOC和AOP，甚至有的平台完全没有相关支持。虽然我一直觉得IOC和AOP是非常好的思想，可以让我们的软件内部做到组件之间的低耦合，容易替换，容易扩展，但是我的观点是，作为一个类库不应该把自己组件的初始化以及组装工作交给外部来做。我们知道通过IOC容器来管理我们组件的实例化和依赖，其实我们可以在程序内部实现每一个组件，把装配工作交给XML配置进行，但是对于一些复杂的组件，如果这个工作的配置交给XML进行，那么也就相当于交给了使用者进行，相当于需要使用者一定要理解组件内部的装配结构，这是不合理的。更合理的方式是，组件或框架的作者提供一些扩展点，让使用者可以明确通过API来注入自己的扩展组件或实现组件，而对于只需要简单使用组件的使用者可以无需配置开箱即用。
 
        当然，这不是说Spring的IOC和AOP有什么不好，正因为框架实现的如此灵活，Java使用Spring作为容器也基本是标准了，所以Java界很多框架也因此可以相互进行很好的集成，确实是一个很好的平台。
 
        Spring 5推出了Reactive非阻塞技术栈，基于Netty或Servlet 3.1+容器，提供了Stream API、WebFlux以及各种响应式的存储（各种NOSQL）访问类库。从前到后实现非阻塞的服务，可以避免IO阻塞占据线程，减少线程切换和资源使用，以最小的资源做到最大化的并发。可惜的是JDBC目前并没有非阻塞的版本，这样我们主流的基于MySQL的应用并不能进行全链路（从Controller到外部的Rest服务到数据库）的非阻塞IO（一竿子到底这样才是最爽的）。而且对于Reactive套件，我经过简单的使用个人感觉API比较晦涩，链式调用可读性并不高，而且反而遇到了并发的一些坑，加上代码的示例和最佳实践现在也很少，我感到现在使用并不是特别成熟。
 
2.Spring Data
 
       Spring Data希望以相对比较一致的Template API来让我们更方便得使用各种数据存储。我个人不太喜欢习惯使用Data套件而是更喜欢使用各种NOSQL的Java原生客户端。几个原因：
 
1.原生客户端紧跟服务端的实现，可以第一时间体验到最新的功能
 
2.原生客户端的API和服务端提供的API往往一一匹配，可以一竿子到底，让我们功能使用更准确
 
3.原生客户端往往只是基于API的简单封装，性能更好
 
       当然，如果我们只是对NOSQL进行简单使用的话，Spring Data可能使用起来更方便。
 
3.Spring Boot
 
       稍微老一点的Java开发基本都是从纯XML配置到XML+注解配置走过来的，比较有意思的是很多开发虽然当初在使用XML配置，但是往往问他们每一个配置的含义都不能准确回答出，基本就是拿着主管或前人搭建的一套XML配置直接复制粘贴过来使用。从侧面说明了，其实我们大部分那些Mybatis、Spring MVC的配置都是在干组件初始化而不是定制化的事情。从0开始要让一个组件用起来就需要这些基本的配置，既然是这样的话，其实完全可以有默认配置，采用约定大于配置的方式来做。只有在我们需要针对组件进行定制化的时候才去做更多配置。
 
       Spring Boot不但在自动配置、配置简化上做了很多工作，而且还提供了轻量的嵌入式的容器，只需要20行的Pom+10行代码，就可以立即实现一个可以自启的应用程序（部署简单）激发了我们使用微服务的热情。此外也给我们做了很多Production-ready的启示（Actuator），告诉我们一个完善的应用程序应当注重环境切换、监控、日志、打点等等方面。总之，之前我们可能需要半天时间搭建一个项目，现在通过start.spring.io甚至只需要10秒。在有Boot之前，我实在没有兴趣使用重量级的Java（可能就为了访问下数据库做一些处理，还是使用Python算了）来创建一个实验性的控制台应用程序。
 
4.Spring Cloud
 
 
 
 
      上图来自官网首页，很好地阐述了各个组件之间的关系。我们来逐一过一下脑图上的那些组件：
 
      1.配置管理Cloud Config：提供了客户端和服务端,客户端的使用方式和Spring完美结合，服务端提供了Git方式和文件方式的数据存储，最新版本也提供了数据库方式。这个配置管理的功能上和之前《朱晔的互联网架构实践心得S1E5：不断耕耘的基础中间件》一文中我探到的那些配置管理的功能差十万八千里。
 
       2.服务发现Netflix Euerka：提供可客户端和服务端（兼管理台），这里的客户端是指服务发现的使用方，其实微服务中的服务在这里是客户端。
 
       3.断路器Netflix Hustrix：提供了客户端API、聚合服务端Tubine和Dashboard网站。
 
       4.服务网关：有Netflix Zuul和Cloud Gateway两种网关可以选择，后者据说性能更好。网关其实就是典型的Filter+Handler的实现机制，通过路由找到合适的Handler，然后调用Pre和Post的各种插件式Filter。
 
       5.调用链跟踪Cloud Sleuth：可以搭配Zipkin使用，功能只能说凑活用。Zipkin的那后台功能上和国内主流互联网实现的Trace后台功能相比还是太弱了。
 
       6.消息驱动Cloud Stream：抽象成为了产出消息的Source，消费数据的Sink和抓换数据的Processor。然后把Broker的实现通过Binder进行解耦，支持主流的Kafka、KafkaStream和RabbitMQ三种类型。
 
       7.消息总线Cloud Bus：抽象了MQ的功能，支持主流的MQ产品。
 
       8.函数即服务Cloud Function：把函数封装为Web服务或Stream服务可以独立调用。对函数编程的Function、Consumer和Supplier分别映射成为了Processor、Sink和Source。
 
        9.微服务契约Cloud Contract：实现契约优先的编程，可以先定义契约对契约进行测试，同时进行服务实现。复杂的服务可以用这套方式来做，消费者提供者对着契约自己编自己的，两不耽误。
 
       10.任务框架Cloud Task：非定时任务的概念，这里的任务是指一次性运行的进程。框架提供了任务执行审计管理最基本的功能。这里的任务最后可以在Cloud Dataflow中运行也可以独立运行。
 
        11.管理台：这里列的Admin管理台是第三方提供的，基于Actuator的端点进行信息的综合展示和监控。
 
        总结一下，总体上我感觉Cloud模块化的思想很好，模块和模块之间可以相互搭配使用，但是可能一开始没有进行系统性的规划，版本的升级带来的Breaking Changes有点过多，而且因为内容太多了，文档方面没有特别全面，要全部用起来坑会比较多，需要享受新功能的话还需要不断更新框架版本不断踩坑。
 
        从目前功能的完善程度来说我感觉核心功能完善度在60%（大概还需要发展1年可以用的比较舒服）。后台方面过于简陋，官方提供的后台零散丑陋而且完成度极低（相比国内一线互联网在治理这块开发的功能来说，完善度大概在30%，大概还需要发展2年可以用的比较舒服，如果可以好好规划一套完整的后台把服务治理所有相关功能都整合在一起就好了）。不管怎么样，至少Cloud套件是一套完整的解决方案，目前来看还没有可以媲美的其它开源选择可以使用（Dubbo我们也知道虽然现在又开始高速迭代，但是由于其原始定位是RPC框架，理念上还是有很多不同的，组件方面并没有Cloud那么完善）。
 
        除了功能不完善，Cloud令我担心的还有一点是（我没测试过，但是因为看到目前功能的迭代速度对这方面信心不足，谁大规模应用了能否可以给点数据），这些中间件（服务发现、网关服务、链路跟踪、配置管理）是不是经过压测，是否可以满足比较大的压力，如果只是实现功能的话，可能会在全面用起来后遇到性能瓶颈，在这个时候恐怕就麻烦了。
 
总结
 
        Spring家族已经是功能强大的庞然大物了，我们的项目pom中出现几十个Spring依赖也是家常便饭。使用.NET家族的套件也是几年前的事情了，但是至今我还是觉得微软.NET的开发套件不管是MVC还是ORM还是RPC方面比Spring的MVC、Data JPA（现在大家都使用Mybatis，Mybatis也还是太弱了）、Cloud套件在功能和设计的优雅上更胜一筹，希望将来可以看到Spring针对这些点继续发力，并且持续打造Dataflow套件，结合K8S打造成一个微服务的OS（各种中间件可以实现一键部署集群）。另外对于Spring Cloud除了核心功能之外，希望在管理台方面可以继续完善，打造一个一体化（不一定是一个网站，但是至少可以有权限控制和审计，实现SSO）的管理台，全面实现微服务部署伸缩、服务治理、数据流程管理、服务全链路监控、配置管理等等功能，也期待Spring Cloud和Dataflow双剑合璧在将来的2到3年定义微服务和以数据为核心的流处理的架构标准。

一、hadoop生态图：
 
 
二、hadoop家族子项目：
 
 
三、hadoop框架：
 
 
1、Namenode： 
 1）HDFS的守护程序 
 2） 纪录文件是如何分割成数据块的，以及这些数据块被存储到哪些节点上 
 3）对内存和I/O进行集中管理 
 4）namenode 是个单点，发生故障将使集群崩溃
 
2、Secondary Namenode: 
 1）监控HDFS状态的辅助后台程序 
 2） 每个集群都有一个Secondary Namenode 
 3） 与NameNode进行通讯，定期保存HDFS元数据快照 
 4） 当NameNode故障可以作为备用NameNode使用
 
3、DataNode： 
 1）每台从服务器都运行一个 
 2） 负责把HDFS数据块读写到本地文件系统
 
4、JobTracker： 
 1）用于处理作业（用户提交代码）的后台程序 
 2） 决定有哪些文件参与处理，然后切割task并分配节点 
 3） 监控task，重启失败的task（在不同的节点） 
 4）每个集群只有唯一一个JobTracker，位于Master节点
 
5、TaskTracker： 
 1）位于slave节点上，与datanode结合（代码与数据一起的原则） 
 2）管理各自节点上的task（由jobtracker分配） 
 3）每个节点只有一个tasktracker，但一个tasktracker可以启动多个JVM，用于并行执行map或reduce任务 
 4） 与jobtracker交互
 
6、注：Master与Slave 
 1）Master：Namenode、Secondary Namenode、Jobtracker。浏览器（用于观看 管理界面），其它Hadoop工具 
 2）Slave：Tasktracker、Datanode 
 3）Master不是唯一的
 
四、HDFS体系结构
 
 
1)客户端对HDFS读取数据流程：
 
 
2)客户端对HDFS写入数据流程：
 
 
3)HDFS的可靠性有 : 冗余副本策略、机架策略、 心跳机制、 安全模式、 校验和 、回收站、 元数据保护、 快照机制
 
五、Map-Reduce：
 
 
六、Pig
 
 
1）Hadoop客户端 
 2） 使用类似于SQL的面向数据流的语言Pig Latin 
 3） Pig Latin可以完成排序，过滤，求和，聚组，关联等操作，可以支持自定义函数 
 4） Pig自动把Pig Latin映射为Map-Reduce作业上传到集群运行，减少用户编写Java程序的苦恼 
 5）三种运行方式：Grunt shell，脚本方式，嵌入式
 
七、Hbase
 
 
Hbase物理模型：
 
 
1）Google Bigtable的开源实现 
 2）列式数据库 
 3） 可集群化 
 4）可以使用shell、web、api等多种方式访问 
 5）适合高读写（insert）的场景 
 6） HQL查询语言 
 7） NoSQL的典型代表产品
 
八、Hive
 
 
1）数据仓库工具。可以把Hadoop下的原始结构化数据变成Hive中的表 
 2） 支持一种与SQL几乎完全相同的语言HiveQL。除了不支持更新、索引和事务，几乎SQL的其它特征都能支持 
 3） 可以看成是从SQL到Map-Reduce的映射器 
 4） 提供shell、JDBC/ODBC、Thrift、Web等接口
 
九、Zookeeper
 
 
1）Google Chubby的开源实现 
 2）用于协调分布式系统上的各种服务。例如确认消息是否准确到达，防止单点失效，处理负载均衡等 
 3） 应用场景：Hbase，实现Namenode自动切换 
 4） 工作原理：领导者，跟随者以及选举过程
 
十、Sqoop
 
 
1）用于在Hadoop和关系型数据库之间交换数据 
 2）通过JDBC接口连入关系型数据库
 
十一、Avro 
 
1）数据序列化工具，由Hadoop的创始人Doug Cutting主持开发 
 2）用于支持大批量数据交换的应用。支持二进制序列化方式，可以便捷，快速地处理大量数据 
 3）动态语言友好，Avro提供的机制使动态语言可以方便地处理 Avro数据。 
 4） Thrift接口
 
十二、Chukwa 
 
1）架构在Hadoop之上的数据采集与分析框架 
 2） 主要进行日志采集和分析 
 3） 通过安装在收集节点的“代理”采集最原始的日志数据 
 4） 代理将数据发给收集器 
 5） 收集器定时将数据写入Hadoop集群 
 6） 指定定时启动的Map-Reduce作业队数据进行加工处理和分析 
 7） Hadoop基础管理中心（HICC）最终展示数据
 
十三、Cassandra
 
1）NoSQL，分布式的Key-Value型数据库，由Facebook贡献 
 2） 与Hbase类似，也是借鉴Google Bigtable的思想体系 
 3）只有顺序写，没有随机写的设计，满足高负荷情形的性能需求