2010年，几个大胡子年轻人在旧金山成立了一家做 PaaS平台的公司，起名为dotCloud。dotCloud是YCombinator（创投公司） S10的毕业生。 创始人：Solomon Hykes 2006年毕业于EPITECH - European Institute of Technology(硕士) 2003-2004年做过个人IT教师 2006年曾经在SmartJog担任售后工程师 2010-2013年担任dotCloud的CEO 2013年至今担任dotCloud的CTO dotCloud主要是基于 PaaS 平台为开发者或开发商提供技术服务。PaaS的概念虽好，但是由于认知、理念和技术的局限性，市场的接受度并不高，市场的规模也不够大。除 此之外，还有巨头不断进场搅局，IBM的蓝云，微软的 Azure，Amazon 的 EC2，Google 的 GAE，VMware 的 Cloud Foundry等等，可谓强敌环伺，而且强敌都不差钱，想玩多久就玩多久，想玩多大玩多大。在这种情况下，虽然 dotCloud在2011年初拿到了1000万美元的融资，但依然举步维艰。 Solomon Hykes在这种情况下，决定将自己的核心引擎开源，并让团队的核心成员参与开源项目。这个引擎的名字叫做Docker，以Go语言写成。Docker一经开源立刻得到了「业界」的热烈吹捧。这个容器管理引擎大大降低了容器技术的使用门槛，轻量级，可移植，虚拟化，语言无关，写了程序扔上去做成镜像可以随处部署和运行，Docker迅速从单纯的云端虚机限定资源环境转变成新的代码或应用发布形式，方便有集成开发、快速迭代需求的用户实现多次更新的回退和版本管理，开发、测试和生产环境彻底统一了，还能进行资源管控和虚拟化。 从此以后，他们开始专心研发 Docker 产品和维护相关社区。2013年10月 dotCloud公司更名为Docker股份有限公司，2014年8月Docker宣布把PAAS的业务「dotCloud」出售给位于德国柏林的平台即服务提供商「cloudControl」，dotCloud的历史告一段落。同年8月，Docker内部员工 James Turnbull 发布了面向开发者、运维和系统管理员的 Docker电子书《The DockerBook》。2014年9月，Docker 宣布已获 4000 万美元的 C 轮融资。 2014年6月，Microsoft Open Technology （微软开放技术）宣布 Azure开始支持Docker部署；2014年10月，微软宣布下一个版本的WindowsServer将原生支持Docker；2014年11月，AWS加码押注Docker，推出了高性能容器管理服务EC2Container服务，用户可以在AWS上使用容器轻松地运行和管理分布式应用；2014年12月，Docker宣布发布跨容器的分布式应用编排服务，编排服务可以帮助开发者创建并管理新一代的可移植的分布式应用程序。 Docker的竞争对手是CoreOS公司的容器技术Rocket，现在Rocket得到谷歌、Red Hat以及 VMware等一批大公司的支持。 参考 Docker 传奇之 dotCloud Docker，云时代的程序交付方式 Docker项目研究 Docker之父Solomon Hykes谈项目开发的初衷和挑战 解读2014之Docker篇：才气、勇气、运气 八个Docker的真实应用场景 Google支持Docker的竞争对手，云计算恩怨又起

打开一个HDFS文件，获得一个FSDataInputStream对象，其实现类到底是什么？小小探究一下。 package com.yqu.hadoop; import java.io.IOException; import java.io.InputStream; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FSDataInputStream; import org.apache.hadoop.fs.FileSystem; import org.apache.hadoop.fs.Path; public class LearnFS { public static void main(String[] args) { Configuration config = new Configuration(); FSDataInputStream in = null; Path path = new Path("/user/hadoop/input/access_log.txt"); try { FileSystem fs = FileSystem.get(config); System.out.println("Scheme: " + fs.getScheme()); System.out.println("Uri: " + fs.getUri().toString()); in = fs.open(path); if (in != null) { System.out.println("FSDataInputStream impl:" + in.getClass().getCanonicalName()); InputStream is = in.getWrappedStream(); if (is !

集群规划 |节点|角色 |—– |node50064|NameNode RessourceManager |node50069|Datanode SecondNameNode |node51054|Datanade 准备工作 （在全部机器上）创建hadoop用户 $ sudo useradd -m hadoop -s /bin/bash $ sudo passwd hadoop $ sudo adduser hadoop sudo （在全部机器上）配置/etc/hosts 10.120.12.135 node50064.mryqu.com node50064 10.120.11.201 node50069.mryqu.com node50069 10.120.14.226 node51054.mryqu.com node51054 （在全部机器上）禁止掉IPv6 参见之前的博文在Ubuntu中禁掉IPv6。 （在全部机器上）关闭防火墙 ufw disable //关闭 sudo apt-get remove ufw //卸载 sudo ufw status //查看 （在全部机器上）安装并配置Java JDK 安装Java JDK： $ sudo apt-get update $ sudo apt-get install openjdk-7-jre openjdk-7-jdk 通过下列命令确定JDK安装路径为/usr/lib/jvm/java-7-openjdk-amd64： 通过sudovi /etc/profile添加如下内容： export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 export CLASSPATH=.

Java Code Geeks有一篇文章Microservice Design Patterns，提供了六种微服务架构的设计模式，用于组合微服务。 聚合器微服务设计模式 这是一种最常用也最简单的设计模式，如下图所示： 聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。 代理微服务设计模式 这是聚合器模式的一个变种，如下图所示： 在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。一个很好的实例就是针对不同设备的表现层可以封装在代理微服务内。 链式微服务设计模式 这种模式在接收到请求后会产生一个经过合并的响应，如下图所示： 在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。 分支微服务设计模式 这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示： 数据共享微服务设计模式 自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithicapplication）”时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示： 在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。 异步消息传递微服务设计模式 虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示： 感兴趣的读者可以参考《微服务中的耦合与自治》一文为自己的微服务选择合适的消息传递模式。

开发web程序的最早期时间，最被广泛使用的企业程序架构是将程序的服务器端组件打包为单个单元。很多企业Java应用程序由单个WAR或EAR文件组成。其它语言（比如Ruby，甚至C++）编写的应用程序也大抵如此。这种单体架构模式(monolithicapplication architecturepattern)往往通过一个数据访问层与单一类型的数据库相连接，所有不同用途的数据存储都存储在该数据库内。 数据库环境在过去的十多年里增长巨大。每个新出现的数据库相较于其它数据库，都在某些方面有着优势，但同时它们也做了各种各样的折衷。事实上，根据CAP定理不可能拥有完美的数据库，我们需要根据应用程序来选择哪种折衷是可接受的。带有这些约束的工作场景符合Martin Fowler推广的混合持久化思路。混合持久化的思路是指，你应该根据工作的不同需求选择相应合适的数据库，这样我们就能两者兼得了。 混合持久化的优点显而易见：一个复杂的企业应用程序会使用很多类型的数据，对每种数据采用最适合的存储技术，可以带来性能的提升。随着微服务架构模式（Microservicearchitecturepattern）越来越受欢迎，复杂的企业应用程序将会被分解成很多的微服务，每个微服务内将对所操作的数据采用最适合的存储技术。 混合持久化的缺点也同样鲜明：以增加复杂性为代价。每种数据存储机制都有其学习成本，选择正确的数据存储也有决策成本。需要了解每种数据存储的性能瓶颈并不断迎接挑战。 Martin Fowler建议对战略性的项目采用混合持久化，这样才能通过新技术获得足够收益。 参考 Polyglot Persistence The featuer is: Polyglot Persistence NoSQL精粹 第13章混合持久化

随着软件开发复杂度的不断提高，团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来，敏捷（Agile）在软件工程领域越来越红火，如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。持续集成正是针对这一类问题的一种软件开发实践。它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。 Gerrit Gerrit是基于GWT web应用的开源代码审查系统，为使用Git版本控制系统的项目提供在线代码审查。安卓开源项目（AOSP）用其来管理多代码库的庞大项目。Gerrit通过在自身代码库跟踪提交的Git变更集来提供代码审查的。它并排显示新旧文件，让审查者更容易对变更进行审查，并允许审查者添加内嵌注释。 提交的变更既可以被Jenkins这样的自动系统进行审查，也可以由同事进行审查。每个审查者检查代码变更、添加注释，然后将变更标记为“在我看来代码不错”(“没有打分”或“我期望你不要提交代码”)。验证者(例如Jenkins或其他人)通过构建和测试代码来验证变更。如果他们认为代码可行，则设置“在我看来代码不错”标记，Gerrit将尝试将变更合并到公开的“权威”代码库。文章Life of a Patch描述了这一工作流: Gradle 在Java构建工具的世界里，先有了Ant，然后有了Maven。Maven的CoC（约定优于配置）、依赖管理以及项目构建规则重用性等特点，让Maven几乎成为Java构建工具的事实标准。然而，冗余的依赖管理配置、复杂并且难以扩展的构建生命周期，都成为使用Maven的困扰。Gradle作为新的构建工具，是基于Groovy语言的构建工具，既保持了Maven的优点，又通过使用Groovy定义的DSL克服了Maven中使用XML繁冗以及不灵活等缺点，支持依赖管理和多项目，而且它有非常完善的说明文档。目前，SpringSource、Hibernate等都采用Gradle来构建。 Jenkins Jenkins，之前叫做Hudson，是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时Jenkins能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。Jenkins通过Gerrit触发器插件可在新的Gerrit补丁集创建时开始使用Gerrit代码库中的代码进行构建项目，通过Gradle插件调用Gradle构建脚本，以帮助变更验证。 参考 Git权威指南-第5篇-第32章 Gerrit 代码审核服务器 Git+Gerrit+Gradle+Jenkins持续集成设置

最近又搜集到Martin L. Abbott和Michael T. Fisher的两本好书： The Art of Scalability Scalability Rules：50 Principles for Scaling Web Sites 第一本书将近六百页，最近没时间看，就先粗略学习一下其中的三维伸缩性模型： 在该模型中，将应用程序水平复制，通过负载均衡运行应用程序的多个完全一样的副本的方式来实现应用程序伸缩性，这种方式称为X轴伸缩性。这是一种很好的方式来提高应用程序的容量和可用度。 当使用Z轴伸缩性，每个服务器运行代码的一个完全相同的副本。在该方面，它与X轴伸缩性很相似。最大的不同是每个服务器只负责数据的一个子集。该系统的一些组件负责将每个请求路由给适当的服务器。一个常见的路由规则是把请求的一个属性作为被访问的实体的主键，比如分区。另一个常见的路由规则是客户类型。例如，应用程序可以向付费用户提供比免费用户更高的SLA，实现方式是将付费用户的请求路由到具有更高容量的一组服务器上。 Z轴伸缩性与X轴伸缩性类似，提高了应用程序的容量和可用度。然而，没有任何一个方式能够解决不断增加的开发工作和程序复杂度的问题。解决这些问题需要Y轴伸缩性。 伸缩性的第三个维度是针对功能性分解的Y轴伸缩性。Y轴伸缩性与Z轴伸缩性分解事情的方式相似但有不同。在应用程序层级，Y轴伸缩性将单体应用程序拆分成一组服务。每个服务实现了一组相关的功能特性，例如订单管理，客户管理等。 决定如何将系统分割为一组服务更像是一门艺术，但是可借助于一些策略。一种方式是通过动词或使用情况拆分服务。另一个拆分方式是通过名词或资源分割系统。这种服务负责处理给定的实体/资源的所有操作。 Unix提供了大量的工具，比如grep，cat和find。每个工具只做一件事，效果往往非常好，并且可以使用shell脚本组合多个工具以执行复杂的任务。服务分割也应采用类似的策略。

Java Code Geeks有一篇文章Microservices, Monoliths, and NoOps，分析了单体应用与微服务的优缺点，并建议使用微服务重构现有的应用程序。 单体应用 通俗地讲，“单体应用（monolithapplication）”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它归档格式。 单体应用优点 单体应用有如下优点： 为人所熟知：现有的大部分工具、应用服务器、框架和脚本都是这种应用程序； IDE 友好：像NetBeans、Eclipse、IntelliJ这些开发环境都是针对开发、部署、调试这样的单个应用而设计的； 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享； 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始； 容易部署：只需将单个归档文件复制到单个目录下。 单体应用缺点 目前为止，单体应用已经很好地服务了我们，未来无疑还会继续发挥重要作用。但是，不管如何模块化，单体应用最终都会因为团队壮大、成员变动、应用范围扩展等出现问题。下面是单体应用的一些不足： 不够灵活：对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率； 妨碍持续交付：单体应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重； 受技术栈限制：对于这类应用，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具，无法根据具体的场景做出其它选择； 技术债务：“不坏不修（Not broken，don’tfix）”，这在软件开发中非常常见，单体应用尤其如此。系统设计或写好的代码难以修改，因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭，这必然会增加应用程序的技术债务。 什么是微服务？ 而随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序。这里的“微”不是针对代码行数而言，而是说服务的范围限定到单个功能。 微服务的特征 微服务有如下特征： 领域驱动设计：应用程序功能分解可以通过Eric Evans在《领域驱动设计》中明确定义的规则实现，领域驱动设计不是分解应用程序的唯一方法，但肯定是很常用的一种；每个团队负责与一个领域或业务功能相关的全部开发；团队遵循全栈开发方法拥有全系列的开发人员，具备用户界面、业务逻辑和持久化存储等方面的开发技能； 单一职责原则：每个服务应该负责该功能的一个单独的部分，这是SOLID原则之一，Unix工具程序很好地证明这一原则的重要性； 明确发布接口：每个服务都会发布一个定义明确的接口，而且保持不变；服务消费者只关心接口，而对于被消费的服务没有任何运行依赖；服务之间就业务模型、API、负载或其他契约达成一致并使用符合契约的方式进行通信。接口可能会产生新版本，但接口的老版本可以继续使用，且新服务保持后续兼容。不可以通过改变契约破坏兼容性。 独立部署、升级、扩展和替换：每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级，例如增加更多的功能点。每个服务都可以沿着《Art of Scalability》一书定义的X轴（水平复制）和Z轴（面向查询的分割，数据分区）进行独立扩展；由于其他服务仅依赖发布的接口，只要发布相同的契约，服务实现甚至是底层技术栈都可以修改； 可以异构/采用多种语言：每个服务的实现细节都与其它服务无关，这使得服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、持久化存储、工具和方法；一个需要在关系型数据库存储数据的服务可以选择MySQL，另一个需要存储文档的服务可以选择MongoDB。不同的团队可以根据自己的需求选择JavaEE、NodeJS、Python、Vert.x或其他对本团队最有效的技术； 轻量级通信：服务通信使用轻量级的通信协议，例如在HTTP上承载的REST。由于REST本质是同步的，可能会有某些潜在的瓶颈。另一个可选机制是使用支持异步消息的发布/订阅机制。任何符合需求的消息协议，例如AMQP、STOMP、MQTT或WebSocket，都可以使用。简单消息实现，例如ActiveMQ，提供了可靠的异步组构尤其适用于这种用途。每个开发团队可以根据服务的具体需求对同步还是异步消息做适宜的选择，当然也可以混用。 Netflix是微服务的一个典型代表，这里有几篇文章介绍他们对微服务的应用。 Netflix’s Viewing Data: How We Know Where You Are in House of Cards A Microscope on Microservices Scalable Microservices at Netflix. Challenges and Tools of the Trade Adopting Microservices at Netflix: Lessons for Architectural Design 很多增强Netflix微服务架构的工具可在netflix.

学习SAS Visual Analytics Explorer时看到了地图提供程序模式竟然没有GoogleMap，而是OpenStreetMap和Esri。对没接触过的东东还比较好奇，搜了一下。 OpenStreetMap 开放街道地图（OpenStreetMap，简称OSM）是一个由地图制作爱好者组成的社区。这些爱好者提供并维护世界各地关于道路、小道、咖啡馆、铁路车站等各种各样的数据，目标是创造一个内容自由且能让所有人编辑的世界地图，并且让一般便宜的移动设备有方便的导航方案。OSM项目由英国人SteveCoast创立，概念启发自维基百科网站，以及英国以及其他地区私有地图数据占尽优势。一如维基百科等网站，OSM网站地图页有“编辑”按钮，亦有纪录修订历史。经注册的用户可上传GPS路径，及可编辑地图的矢量数据，包括使用OSM网站的编辑器或其他自由地理信息系统软件，如JOSM。OSM的地图由用户根据手持GPS设备、航空摄影照片、卫星视频、其他自由内容以至单靠用户由于对有关区域的熟悉而具有的本地知识绘制。地图的矢量数据以开放数据库授权方式授权。OSM网站由英国非营利组织OpenStreetMap基金会赞助维运。 既然有Google和Nokia这样的公司提供很好的地图商业产品，那为什么还需要一个像OpenStreetMap项目了？答案是简单的，作为一个社会，不应当有一家或几家公司在地理信息上进行垄断。地理信息是分享资源，当你将所有的这些权力给予一个单独的实体，你给予他们的权力就不止是告诉他们你的地理位置，更是在塑造它，从自己商业利益的角度显示地图上的内容。而在地图内容方面，OpenStreetMap即是中立的又是透明的。 Esri 美国环境系统研究所公司（Environmental Systems Research Institute,Inc.，简称Esri），是目前世界最大的地理信息系统技术供应商，其地理信息系统软件目前的全球市场占有率最高，公司最知名产品为ArcGIS。ArcGISOnline是一个面向全球用户的公有云GIS平台，是一种全新的GIS软件应用模式。ArcGISOnline包含了全球范围内的底图、地图数据、应用程序，以及可配置的应用模板和开发人员使用的 GIS 工具和 API，可用于创建Web 地图、发布GIS服务、共享地图、数据和应用程序等，以及管理组织的内容和多个用户。 SAS Visual Analysis Explorer里面在Esri模式下还需要选择ArcGISOnline的数据源（例如World Cities、World Street Map）。 参考 OpenStreetMap网站 Esri公司 Wiki: 开放街图 为什么世界需要 OpenStreetMap 开源道路地图 Wiki: 美国环境系统研究所公司

Jenkins在构建部署镜像时发生超时： Build timed out (after 10 minutes). Marking the build as aborted. Build was aborted Finished: ABORTED 解决方法是在Jenkins当前项目下点击Configure菜单后，在BuildEnvironment配置项里修改超时策略。我把超时绝对值改大点就好了。