分类目录归档：Docker

基于 Docker 搭建 Mac 本地 HBase 环境

发表于由
回复

说起玩大数据，相信很多人都会因为 Apache 全家桶软件配置而菊花一紧。Docker 的出现，把很多玩大数据就是配机器、配环境的开发者从泥潭中拯救了出来，虽然还不能完全替代线上环境，但是在开发环境，无疑为开发者节约了大量搭建本地环境的时间。比较遗憾的是，我们团队之前也是没有独立的数据测试环境?，于是把在本地搭建 HBase 环境整理和记录如下。

系统环境：

  • MacBook Pro (Retina, 15-inch, Mid 2015)
  • 2.2 GHz Intel Core i7
  • 16 GB 1600 MHz DDR3
  • macOS 10.13.6

安装 Docker CE for Mac

从Docker Community Edition for Mac下载安装。

Mac 上的 Docker 环境经过 docker-machine/virtualbox 几次变化，如今的 Docker CE 已经支持原生 Mac 环境，因此当前阶段 Docker CE for Mac 就是唯一推荐的 Mac Docker 环境，再也不用通过安装 virtualbox 这种借蛋生鸡的方式了，实在是很赞。此外，现在的 Docker CE 集成了 Kubernetes, 因此本地玩 k8s 也不需要额外进行安装配置。如果你计划以后就是玩 k8s, 那么你以前安装的 Kitematic 也可以卸载掉了。Kitematic 除了一个图形化的 container 管理界面，实在没有什么值得留恋的，因此官方停止其开发无疑是个正确的决定。

获取和启动 HBase Docker 镜像

  • 获取容器镜像

更多大数据全家桶 Docker 镜像可以参见 HariSekhon/Dockerfiles。

  • 启动容器

参数解释:

  • -d: 后台启动。
  • -h: 容器主机名，必须设置该项并配置 hosts，否则无法连通容器。
  • -p: 网络端口映射，这里只把要使用的端口（zookeeper端口、HBase Master端口、HBase RegionServer端口等）映射了出来，你可以根据自己需要进行端口映射。常用 HBase端口可以参见下表：

但是，harisekhon/hbase 修改了默认端口：

因此，你看到启动参数中的端口参数是那样的。

  • --name: 容器别名。

设置hosts (推荐使用 Gas Mask):

成功启动后，就可以在 http://localhost:16010/master-status 查看 HBase 状态了：

需要注意的一点是：容器销毁后，数据也也会被同时销毁。因此你可以通过 -v YOUR_DIR:/hbase-data 的方式将数据目录映射到宿主机目录，防止数据丢失。

编写测试代码

  • 创建 table

  • 读写 table

Maven 添加依赖：

HelloHBase.java:

扩展阅读

容器环境下 go 服务性能诊断方案设计与实现

发表于由
回复

背景

业务上量以后，对程序进行 profiling 性能诊断对很多后端程序员来说就是家常便饭。一个趁手的工具往往能让这个事情做起来事半功倍。

在这方面，go 有着天然的优势：继承 Google’s pprof C++ profiler 的衣钵，从出生就有 go tool pprof 工具。并且，标准库里面提供 runtime/pprof 和 net/http/pprof 两个package, 使得 profiling 可编程化。

在非容器环境下，我们的研发同学喜欢使用 net/http/pprof 来提供http接口供 go tool pprof 工具进行 profiling:

import _ "net/http/pprof"

func main(){
    ...
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()
    ...
}

获取 CPU profile 数据：

go tool pprof http://localhost:6060/debug/pprof/profile

但是，当架构逐步演进为微服务架构并使用k8s等容器化技术进行部署以后，这种这种方式面临的问题也越来越多：

  1. 我们生产环境使用k8s进行容器编排和部署。service类型是 NodePort. 因此研发同学无法直接对某个 service 的特定 pod 进行 profiling. 之前的解决方式是：
    1. 如果要诊断的问题是这个service普遍存在的问题，则直接进行 profiling。
    2. 如果要诊断的问题只出现在这个service的某个特定的pod上，则由运维同学定位到该pod所处的宿主机后登录到该容器中进行profiling。耗时耗力，效率低。
  2. 架构微服务化以后，服务数量呈量级增加。以前那种出现问题再去诊断服务现场的方式越来越难满足频率和数量越来越多的profiling需求（很多情况下，我们才做好profiling的准备，问题可能已经过去了……）。我们迫切的需要一种能够在程序出问题时，自动对程序进行profiling的方案，最大可能获取程序现场数据。
  3. 同时，我们希望这种自动profiling机制对程序性能影响尽可能小，并且可以与现有告警系统集成，直接将诊断结果通知到程序的owner.

方案设计与实现

  • 我们使用 heapster 对k8s的容器集群进行监控。并将监控到的时序数据写入influxDB进行持久化。
  • gopprof 是我们容器环境下对其他 go 服务进行性能诊断的核心服务：
    • 通过对influxDB中的监控数据分析，对于异常的pod自动进行 profiling. 当前设置的策略是如果该pod在两个1分钟分析周期内，资源使用率都超过设定的阈值0.8，则触发profiling。
    • 将 gopprof 作为一个服务部署在k8s集群中主要是使其可以通过内网IP直接访问pod的 http profile接口，已实现对特定pod的profiling:
    go tool pprof http://POD_LAN_IP:NodePort/debug/pprof/profile
    • gopprof 完成profiling后，会自动生成 profile svg 调用关系图，并将profile 数据和调用关系图上传云存储，并向服务的owner推送诊断结果通知：

    • 由于 gopprof 依赖工具 go tool pprof 和 graphivz, 因此gopprof的基础镜像需要预装这两个工具。参考Dockerfile：
    # base image contains golang env and graphivz

FROM ubuntu:16.04

MAINTAINER Daniel liudan@codoon.com

RUN apt-get update
RUN apt-get install wget -y
RUN wget -O go.tar.gz https://dl.google.com/go/go1.9.2.linux-amd64.tar.gz && \
    tar -C /usr/local -xzf go.tar.gz && \
    rm go.tar.gz

ENV PATH=$PATH:/usr/local/go/bin

RUN go version

RUN apt-get install graphviz -y
    • gopprof 向研发同学提供了对特定pod以及特定一组pod进行手动profiling的的接口。在解放运维同学生产力的同时，也让研发同学在出现难以复现的问题时，能够有更大可能性获取到程序现场。
    • 在高可用方面，当前只支持部署一个 gopprof pod, 服务可用性依赖于k8s的的auto restart. 后期如果有这方面的需求，可能会修改为依赖于etcd支持多个gopprof pod部署。

小结

gopprof 服务已经在我们内部落地试运行了一段时间，整个上达到了我们的设计预期，并辅助我们发现和解决了一些之前没有意识到的性能问题。由于有一些内部代码依赖，暂时还无法开源出来。但是整个方案所依赖的组件都是通用的，因此你也可以很容易的实现这个方案。如果你对我们实现中的一些细节感兴趣，欢迎评论和留言。

Service Mesh 及其主流开源实现解析

发表于由
回复

什么是 Service mesh

Service Mesh 直译过来是 服务网格，目的是解决系统架构微服务化后的服务间通信和治理问题。服务网格由 sidecar 节点组成。在介绍 service mesh 之前，我们先来看一下什么是 sidecar.

Sidecar 在软件系统架构中特指边车模式。这个模式的灵感来源于我们生活中的边三轮：即在两轮摩托车的旁边添加一个边车的方式扩展现有的服务和功能。在绝地求生吃鸡游戏中，摩托车是无敌的，应该也与这个模式有关吧? 这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦：原来两轮摩托车的驾驶者集中注意力跑赛道，边车上的领航员专注周围信息和地图，专注导航。

具体到微服务架构中，即给每一个微服务实例（也可以是每个宿主机host）同步部署一个 sidecar proxy:

该 sidecar proxy 负责接管对应服务的入流量和出流量。并将微服务架构中以前有公共库、framework实现的熔断、限流、降级、服务发现、调用链分布式跟踪以及立体监控等功能从服务中抽离到该 proxy 中：

当该 sidecar 在微服务中大量部署时，这些 sidecar 节点自然就形成了一个网格：

这就是我们说的 service mesh 了。对 service mesh 有了一个感性认识后，我们看一下 Linkerd 和 Conduit 的作者 William Morgan 在What’s a service mesh? And why do I need one? 中是如何诠释什么是 Service Mesh:

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

Service Mesh 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施，并让整个架构更为的先进和 Cloud Native。在工程中，Service Mesh 基本来说是一组轻量级的与应用逻辑服务部署在一起的服务代理，并且对于应用服务是透明的。

Service Mesh的特点

  • 是一个基础设施
  • 轻量级网络代理，应用程序间通讯的中间层
  • 应用程序无感知，对应用程序透明无侵入
  • 解耦应用程序的重试/超时、监控、追踪和服务发现等控制层面的东西

Service Mesh 有哪些开源实现

Service Mesh 的概念从2016年提出至今，已经发展到了第二代。

第一代 service mesh 以 Linkerd 和 Envoy 为代表。

Linkerd 使用Scala编写，是业界第一个开源的service mesh方案。作者 William Morgan 是 service mesh 的布道师和践行者。Envoy 基于C++ 11编写，无论是理论上还是实际上，后者性能都比 Linkderd 更好。这两个开源实现都是以 sidecar 为核心，绝大部分关注点都是如何做好proxy，并完成一些通用控制面的功能。 但是，当你在容器中大量部署 sidecar 以后，如何管理和控制这些 sidecar 本身就是一个不小的挑战。于是，第二代 Service Mesh 应运而生。

第二代service mesh主要改进集中在更加强大的控制面功能（与之对应的 sidecar proxy 被称之为数据面），典型代表有 Istio 和 Conduit。

Istio 解析

Istio 是 Google 和 IBM 两位巨人联合 Lyft 的合作开源项目。是当前最主流的service mesh方案，也是事实上的第二代 service mesh 标准。

Google 和 IBM 之所以要带上小弟 Lyft 一起玩耍是因为他们不想从头开始做数据面的组件，于是在 Istio 中，直接把 Lyft 家的 Envoy 拿来做 sidecar. 除了sidecar, Istio中的控制面组件都是使用Go编写。Istio架构如下图所示：

对于一个仅提供服务与服务之间连接功能的基础设施来说，Istio的架构算不上简单。但是架构中的各个组件的理念的确非常先进和超前。

  • Envoy: 扮演sidecar的功能，协调服务网格中所有服务的出入站流量，并提供服务发现、负载均衡、限流熔断等能力，还可以收集大量与流量相关的性能指标。
  • Pilot: 负责部署在service mesh中的Envoy实例的生命周期管理。本质上是负责流量管理和控制，是将流量和基础设施扩展解耦，这是Istio的核心。感性上，可以把Pilot看做是管理sidecar的sidecar, 但是这个特殊的sidacar并不承载任何业务流量。Pilot让运维人员通过Pilot指定它们希望流量遵循什么规则，而不是哪些特定的pod/VM应该接收流量。有了 Pilot 这个组件，我们可以非常容易的实现 A/B 测试和金丝雀Canary测试：

  • Mixer: Mixer在应用程序代码和基础架构后端之间提供通用中介层。它的设计将策略决策移出应用层，用运维人员能够控制的配置取而代之。应用程序代码不再将应用程序代码与特定后端集成在一起，而是与Mixer进行相当简单的集成，然后Mixer负责与后端系统连接。也就是说，Mixer可以认为是其他后端基础设施（如数据库、监控、日志、配额等）的sidecar proxy:

  • Istio-Auth: 提供强大的服务间认证和终端用户认证，使用交互TLS，内置身份和证书管理。可以升级服务网格中的未加密流量，并为运维人员提供基于服务身份而不是网络控制来执行策略的能力。Istio的未来版本将增加细粒度的访问控制和审计，以使用各种访问控制机制（包括基于属性和角色的访问控制以及授权钩子）来控制和监视访问您的服务，API或资源的人员。

Istio 的很多设计理念的确非常吸引人，又有 Google 和 IBM 两个巨人加持，理论上这条赛道上的其他选手都可以直接退赛回家了。但是 Istio 发布的前几个版本都在可用性和易用性上都差强人意。此外，service mesh 布道师、 Linkerd 作者 William Morgan 也心有不甘。因此， William Morgan一方面在2017年7月11日，Linkerd 发布版本 1.1.1，宣布和 Istio 项目集成，一方面夜以继日的开发Conduit.

Conduit 解析

Conduit 各方面的设计理念与 Istio 非常类似。但是作者抛弃了 Linkerd, 使用Rust重新编写了sidecar, 叫做 Conduit Data Plane, 控制面则由Go编写的 Conduit Control Plane接管：

从Conduit的架构看，作者号称Conduit吸取了很多 Linkerd 的 Scala 的教训，比 Linkerd 更快，还轻，更简单，控制面功能更强可信度还是挺高的。与Istio比较，个人其实更喜欢Conduit的架构，一方面是它足够简单，另一方面对于要解决的问题足够聚焦。

nginMesh 凑热闹？

Service Mesh 最基础的功能毕竟是 sidecar proxy. 提到 proxy 怎么能够少了 nginx? 我想nginx自己也是这么想的吧? 毫不意外，nginx也推出了其 service mesh 的开源实现：nginMesh.

不过，与 William Morgan 的死磕策略不同，nginMesh 从一开始就没有想过要做一套完整的第二代Service Mesh 开源方案，而是直接宣布兼容Istio, 作为Istio的 sidecar proxy. 由于 nginx 在反向代理方面广泛的使用，以及运维技术的相对成熟，nginMesh在sidecar proxy领域应该会有一席之地。

反思

对于大规模部署微服务（微服务数>1000）、内部服务异构程度高(交互协议/开发语言类型>5)的场景，使用service mesh是合适的。但是，可能大部分开发者面临的微服务和内部架构异构复杂度是没有这么高的。在这种情况下，使用service mesh就是一个case by case的问题了。

理论上，service mesh 实现了业务逻辑和控制的解耦。但是这并不是免费的。由于网络中多了一跳，增加了性能和延迟的开销。另一方面，由于每个服务都需要sidecar, 这会给本来就复杂的分布式系统更加复杂，尤其是在实施初期，运维对service mesh本身把控能力不足的情况下，往往会使整个系统更加难以管理。

本质上，service mesh 就是一个成规模的sidecar proxy集群。那么如果我们想渐进的改善我们的微服务架构的话，其实有针对性的部署配置gateway就可以了。该gateway的粒度可粗可细，粗可到整个api总入口，细可到每个服务实例。并且 Gateway 只负责进入的请求，不像 Sidecar 还需要负责对外的请求。因为 Gateway 可以把一组服务给聚合起来，所以服务对外的请求可以交给对方服务的 Gateway。于是，我们只需要用一个只负责进入请求的 Gateway 来简化需要同时负责进出请求的 Sidecar 的复杂度。

小结：service mesh不是银弹。对于大规模部署、异构复杂的微服务架构是不错的方案。对于中小规模的微服务架构，不妨尝试一下更简单可控的gateway, 在确定gateway已经无法解决当前问题后，再尝试渐进的完全service mesh化。

扩展阅读