发表于 | 更新于 | 分类于 ， | 阅读次数：

定义

为其他对象提供一种代理便以控制这个对象的访问。

介绍

代理模式（Proxy）属于结构型模式，也叫委托模式。

代理模式的特征是代理类与委托类实现同样的接口，代理类主要负责为委托类预处理消息，过滤消息，把消息转发给委托类，以及事后消息处理。

代理类与委托类之间通常会存在关联关系，一个代理类的对象与一个委托类的对象关联，代理类的对象本身并不真正实现服务，而是通过调用委托类的对象的相关方法，来提供特定的服务。

日常生活中，代购，买房、租房都是属于常见的代理模式。

阅读全文 »

发表于 | 更新于 | 分类于 ， | 阅读次数：

摘要

CentOS 6 或早期的版本中提供的是 MySQL 的服务器/客户端安装包，但 CentOS 7 已使用了 MariaDB 替代了默认的 MySQL。MariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可 MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。

阅读全文 »

发表于 | 更新于 | 分类于 ， | 阅读次数：

摘要

“工欲善其事，必先利其器”，在学习Hadoop之前，我们需要有个好的开发环境。

版本选择

Apache Hadoop

Hadoop是Apache顶级项目，我们可以直接从Apache官网下载。

官网：http://hadoop.apache.org/releases.html

目前稳定版本为 2.8.2

CDH

Cloidera提供Hadoop支持、咨询和管理工具的公司，在Hadoop生态圈地位举足轻重。其著名产品Cloudera’s Distribution for Hadoop，即CDH。

CDH包括Hadoop、HBase、Hive、Pig、Sqoop、Flume、Xookeeper、Oozie、Mahout等，几乎覆盖整个Hadoop生态圈，保证组件之间的兼容性。

CDH最新版本CDH5，基于Hadoop 2.3.
CDH经典版本CDH3，基于Hadoop0.20.2，生产稳定版本。

笔者在学习中决定采用最新的CDH5进行研究。

下载地址：官网
CDH5

阅读全文 »

发表于 | 更新于 | 分类于 ， | 阅读次数：

认识Hadoop

Hadoop是Apache开源组织的一个分布式计算开源框架http://hadoop.apache.org/,可编写和运行分布式应用处理大规模数据。 Hadoop框架的核心是HDFS和MapReduce。其中 HDFS 是分布式文件系统，MapReduce 是分布式数据处理模型和执行环境。

特点：

  1. 运行方便：Hadoop是运行在由一般商用机器构成的大型集群上。Hadoop在云计算服务层次中属于PaaS(Platform-as-a- Service)：平台即服务。
  2. 健壮性：Hadoop致力于在一般的商用硬件上运行，能够从容的处理类似硬件失效这类的故障。
  3. 可扩展性：Hadoop通过增加集群节点，可以线性地扩展以处理更大的数据集。
  4. 简单：Hadoop允许用户快速编写高效的并行代码。
阅读全文 »

发表于 | 更新于 | 分类于 | 阅读次数：

摘要

这是用微服务开发应用系列博客的第七篇也是最后一篇。第一篇中介绍了微服务架构模式，并且讨论了微服架构的优缺点；接续文章讨论了微服务架构不同方面：使用API网关，进程间通信，服务发现，事件驱动数据管理以及部署微服务。本篇，我们将探讨将应用从单体式架构迁移到微服务架构需要考虑的策略。

迁移到微服务综述

迁移单体式应用到微服务架构意味着一系列现代化过程，有点像这几代开发者一直在做的事情，实时上，当迁移时，我们可以重用一些想法。

一个策略是：不要大规模（big bang）重写代码（只有当你承担重建一套全新基于微服务的应用时候可以采用重写这种方法）。重写代码听起来很不错，但实际上充满了风险最终可能会失败，就如Martin Fowler所说：“the only thing a Big Bang rewrite guarantees is a Big Bang!”

相反，应该采取逐步迁移单体式应用的策略，通过逐步生成微服务新应用，与旧的单体式应用集成，随着时间推移，单体式应用在整个架构中比例逐渐下降直到消失或者成为微服务架构一部分。这个策略有点像在高速路上限速到70迈对车做维护，尽管有挑战，但是比起重写的风险小很多。

Martin Fowler将这种现代化策略成为绞杀（Strangler）应用，名字来源于雨林中的绞杀藤（strangler vine），也叫绞杀榕(strangler fig)。绞杀藤为了爬到森林顶端都要缠绕着大叔生长，一段时间后，树死了，留下树形藤。这种应用也使用同一种模式，围绕着传统应用开发了新型微服务应用，传统应用会渐渐退出舞台。

阅读全文 »

发表于 | 更新于 | 分类于 | 阅读次数：

这篇博客是用微服务建应用的第六篇，第一篇介绍了微服务架构模板，并且讨论了使用微服务的优缺点。随后的文章讨论了微服务不同方面：使用API网关，进程间通讯，服务发现和事件驱动数据管理。这篇文章，我们将讨论部署微服务的策略。

动机

部署一个单体式应用意味运行大型应用的多个副本，典型的提供若干个（N）服务器（物理或者虚拟），运行若干个（M）个应用实例。部署单体式应用不会很直接，但是肯定比部署微服务应用简单些。

一个微服务应用由上百个服务构成，服务可以采用不同语言和框架分别写就。每个服务都是一个单一应用，可以有自己的部署、资源、扩展和监控需求。例如，可以根据服务需求运行若干个服务实例，除此之外，每个实例必须有自己的CPU，内存和I/O资源。尽管很复杂，但是更挑战的是服务部署必须快速、可靠和性价比高。

有一些微服务部署的模式，先讨论一下每个主机多服务实例的模式。

阅读全文 »

发表于 | 更新于 | 分类于 | 阅读次数：

本文是使用微服务创建应用系列的第五篇文章。第一篇文章介绍了微服务架构模式，并且讨论了使用微服务的优缺点；第二和第三篇描述了微服务架构模块间通讯的不同方面；第四篇研究了服务发现中的问题。本篇中，我们从另外一个角度研究一下微服务架构带来的分布式数据管理问题。

1.1 微服务和分布式数据管理问题

单体式应用一般都会有一个关系型数据库，由此带来的好处是应用可以使用 ACID transactions，可以带来一些重要的操作特性：

  • 原子性 – 任何改变都是原子性的
  • 一致性 – 数据库状态一直是一致性的
  • 隔离性 – 即使交易并发执行，看起来也是串行的
  • Durable – 一旦交易提交了就不可回滚

鉴于以上特性，应用可以简化为：开始一个交易，改变（插入，删除，更新）很多行，然后提交这些交易。

阅读全文 »

发表于 | 更新于 | 分类于 | 阅读次数：

这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式，讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中，我们将会探讨服务发现相关问题。

为什么要使用服务发现?

设想一下，我们正在写代码使用了提供REST API或者Thrift API的服务，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬件上，服务实例的网络位置都是相对固定的。例如，代码可以从一个经常变更的配置文件中读取网络位置。

阅读全文 »

发表于 | 更新于 | 分类于 | 阅读次数：

摘要

这是采用微服务架构创建自己应用系列第三篇文章。第一篇介绍了微服务架构模式，和单体式模式进行了比较，并且讨论了使用微服务架构的优缺点。第二篇描述了采用微服务架构应用客户端之间如何采用API Gateway方式进行通信。在这篇文章中，我们将讨论系统服务之间如何通信。

简介

在单体式应用中，各个模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是一个基于微服务的分布式应用是运行在多台机器上的。一般来说，每个服务实例都是一个进程。因此，如下图所示，服务之间的交互必须通过进程间通信（IPC）来实现。

阅读全文 »

发表于 | 更新于 | 分类于 | 阅读次数：

摘要

本系列的第一篇介绍了微服务架构模式。它讨论了采用微服务的优点和缺点，除了一些复杂的微服务，这种模式还是复杂应用的理想选择。

当你决定将应用作为一组微服务时，需要决定应用客户端如何与微服务交互。在单体式程序中，通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中，每一个微服务暴露一组细粒度的服务提供点。在本篇文章中，我们来看它如何影响客户端到服务端通信，同时提出一种API Gateway的方法。

原文地址: Building Microservices: Using an API Gateway

阅读全文 »