分布式部署

2011年底，我加入大众点评网，出于很偶然的机会，决定开发CAT，为各个业务线打造分布式实时监控系统，CAT的核心概念源自eBay闭源系统CAL----eBay的几大法宝之一。 在当今互联网时代，业务需求旺盛，开发团队往往采用scrum等敏捷开发流程，加班加点快速迭代以满足业务需求，是常态。采用分布式系统设计和服务化，由多台机器协作来共同完成用户请求，是典型的解决方案。网站故障频发，内部关系错综复杂，故障定位缓慢，甚至找不到问题根源，也是常有的事。虽然已经有很多日志监控工具，或许单个工具功能还不错，但整体服务化水平参差不齐，工具间不能互通互联；另一方面，由于日志数据量大，且分散，使得查找问题根源基本靠人品。 这些也是我们要开发CAT的初衷。 CAT简介 CAT（Central Application Tracking），是基于纯Java开发的分布式实时监控系统。开源代码托管在GitHub（搜索CAT即可），作者是吴其敏（qmwu2000）和尤勇（youyong205）。 产品相关分享在网上可以找到： 看大众点评如何通过实时监控系统CAT打造7*24服务-尤勇@QCon高可用架构群 2015 分布式监控系统的设计与实现-尤勇@QCon上海2015 大众点评网监控系统架构剖析-尤勇@2013第二届华东架构师大会 大众点评网监控平台剖析-吴其敏@QCon杭州2012 CAT现状

一、为了使分布式服务彻底表现，笔者采用8台虚拟机，docker部署的方式来测试demo，demo使用的是spring cloud。读者可先到github上拉取LCN源码。 1、四台数据库 四个服务器依次用docker启动四个mysql数据库 下面四台服务器为部署应用准备 采用eureka做为服务注册跟发现，部署在125服务器，下面是eureka的配置文件 测试应用分三个服务，消费服务(microservice-consumer-user)，两个提供服务(microservice-provider-Two、microservice-provider-Thrid)，没有业务逻辑，只是对提供的两个服务做数据库DDL操作，测试如果两个服务的事务是否成功。 注：这里是用docker部署的，spring-cloud是默认按主机名来查找服务的，docker的主机名是找不到注册到eureka上服务的。所以注册到eureka的服务需要采用IP注册方式。在所有的要注册到eureka的服务端都增加如下配置，如本案中的三个服务的配置文件中都要增加各自的配置。 点击链接会看地址栏如下，说明使用IP的配置生效 关于spring-cloud方面的知识这里不提到，下面是microservice-consumer-user服务的调用逻辑 要使用LCN分布式框架需要在服务中加如下两个jar文件 在上面两处增加

摘要 为了更好的解决分布式环境下多台服务实例的配置统一管理问题，本文提出了一套完整的分布式配置管理解决方案（简称为disconf[4]，下同）。首先，实现了同构系统的配置发布统一化，提供了配置服务server，该服务可以对配置进行持久化管理并对外提供restful接口，在此基础上，基于zookeeper实现对配置更改的实时推送，并且，提供了稳定有效的容灾方案，以及用户体验良好的编程模型和WEB用户管理界面。其次，实现了异构系统的配置包管理，提出基于zookeeper的全局分布式一致性锁来实现主备统一部署、系统异常时的主备自主切换。通过在百度内部以及外部等多个产品线的实践结果表明，本解决方案是有效且稳定的。 技术背景 在一个分布式环境中，同类型的服务往往会部署很多实例。这些实例使用了一些配置，为了更好地维护这些配置就产生了配置管理服务。通过这个服务可以轻松地管理成千上百个服务实例的配置问题。 王阿晶提出了基于zooKeeper的配置信息存储方案的设计与实现[1], 它将所有配置存储在zookeeper上，这会导致配置的管理不那么方便，而且他们没有相关的源码实现。淘宝的diamond[2]是淘宝内部使用的一个管理持久配置的系统，它具有完整的开源源码实现，它的特点是简单、可靠、易用，淘宝内部绝大多数系统的配置都采用diamond来进行统一管理。他将所有配置文件里的配置打散化进行存储

什么是分布式锁 要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。 1.线程锁 主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。 2.进程锁 为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。 3.分布式锁 当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。 分布式锁的由来 在传统单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。 但是在分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁的由来。 当多个进程不在同一个系统中，就需要用分布式锁控制多个进程对资源的访问。 分布式锁的特点 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件： **1、互斥性：**任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。 **2、安全性：*

1. 问题描述 分布式组件项目使用了Redis，在Windows平台使用QT+VS2010编译环境。但Redis客户端库hiredis在Windows平台只提供静态库，而且必须用VS2013以上的版本才能编译。由于VS2013要更新部分组件才能避免编译错误，最终以VS2015编译hiredis.lib静态库。这样就面临如下问题： VS2010不支持完整的C++11特性，linux能直接使用std::thread的代码在Windows无法编译。 但使用该组件的应用程序在Windows系统以VS2010编译，不能直接用VS2015编译出的hiredis.lib继续编译应用程序。 2. 解决过程 2.1. 跨系统移植 2.1.1.务必初始化所有变量 因为某个ID变量没有初始化，在linux运行正常，但移植到windows就出现错误。原因是该变量在linux被缺省初始化为0，单在Windows是随机值。 从代码的质量考虑，不能依赖系统的缺省值，必须养成初始化所有变量的习惯。 2.1.2.VS早期版本不支持C++11的全部标准 代码中使用了C++11的thread，在linux和Windows的VS2015运行正常，但在VS2010编译出错。原因是VS2012之前的版本不支持C++11标准。为此不得不大量使用条件编译，改用CreateThread等函数。 2.2.

最近看了google的分布式追踪系统dapper的论文： http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN//pubs/archive/36356.pdf ，结合自己的理解描述下。 一、 引子： 用户输入关键字后只要敲个回车键就能返回搜索结果（图1a），这样一个简单的过程可能涉及到上千个服务，可能需要上千个服务器协作完成。如图1b所示，user发了RequestX请求到达A，A通过rpc（远程过程调用，如thrift）调用B以及C，而C又需要通过rpc调用D以及E等等。 对user的一次请求，他迟迟未收到响应ReplyX，或者响应时间很慢，我们需要确认性能到底消耗在哪个环节，这个时候我们该怎么办呢？自然是分析我们的日志。 我们每个服务都会有请求日志，请求日志记录着一次调用所花费的时间，比如对A来说，记录着调用B所花费的时间以及调用C所花费的时间，同理C的请求日志记录着调用D以及E所花费的时间。对于互联网应用来说，各个服务比如B，同一时刻可能有成百上千次请求记录。 这种日志有个致命 缺点---没有将这些记录与特定的请求关联一起 。对于user的一条特定的请求RequestX，我们不知道B日志中哪条记录与之对应，也不知道C日志中哪条记录与之对应。。

备份 备份软件 Amanda -客户端-服务器模型备份工具 Bacula - 另一个客户端-服务器模型备份工具 Backupninja -轻量级，可扩展的元数据备份系统 Backuppc -客户端-服务器模型备份工具和文件共享方案。 Burp -网络备份和还原程序 Duplicity -使用rsync算法加密的带宽-效率备份 Lsyncd -监控一个本地目录树的变化,然后产生一个进程去同步变化。默认使用rsync。 Rsnapshot -文件系统快照工具 SafeKeep -使用rdiff-backup，集中的，基于pull的备份 TarSnap - 具有一个开源客户端的安全备份服务 UrBackup -另一个客户端-服务器备份系统 DREBS - AWS EBS支持策略的备份脚本 克隆 克隆软件 Clonezilla -分区和磁盘镜像/克隆程序 Fog - 另一个计算机克隆解决方案 Redo Backup -简单的备份，恢复和还原 云计算 AppScale – 兼容Google App引擎的开源云计算软件. Archipel -使用Libvirt管理和监视虚拟机 CloudStack -创建，管理和部署基础云服务的云计算软件 Cobbler -Cobbler是一个Linux安装服务器，允许快速地构建网络安装环境 Eucalyptus -兼容AWS的开源私有云软件 Mesos

分布式存储 — 硬盘容量不均衡导致的缓存盘寿命急速衰减分析 Ceph 分布式存储在扩展性、可靠性、性能上具备独特的优势，可以实现快速扩展多台服务器，动态伸缩到 PB 级容量，多副本机制保障数据高可靠，数据均衡分布，并发性能高等场景。目前广泛应用于互联网、科研、教育、制造业、政府等诸多领域。 ZStack 云平台目前支持对接 Ceph 分布式存储，使用的是分布式块存储，即使用 librbd 的块设备接口提供给 Qemu 访问，进行云主机、云盘的 IO 读写。 虽然 Ceph 分布式存储具备上述的优势特点，但在实践中，对硬件的选择及配置均存在特别要求，尤其是硬盘、网络上，如果配置不当，存储的可靠性和性能均会受到影响。 最近在日常巡检一套 ZStack 生产环境的 Ceph 分布式存储时，我们发现客户新购的五台服务器的 SSD 寿命损耗存在异常。具体的现象是使用半年后，服务器带外管理界面看到 SSD 的寿命损耗只剩下 89% ，但使用 smartctl 读取介质损耗参数依然显示为 100% 。 此时会很疑惑，到底哪个数据更可靠，如果 SSD 寿命只剩下 89% ，那么如何去调整优化 Ceph 分布式存储？ 问题回顾 针对这个问题，我们回顾一下这套分布式存储的架构。当时采用了新购 + 利旧的方案来部署分布式存储。 相应的配置信息如下： 其中，新购的 5 台机器采用了 Intel Xeon

摘要 Hadoop分布式文件系统（HDFS）设计用来可靠的存储超大数据集，同时以高速带宽将数据集传输给用户应用。 在一个超大集群中，数以千计的服务器直接接触存储器和执行用户应用任务。 通过许多服务器的分布式存储和计算，资源随需求增长的时候仍然可以保持经济性。 我们解释了HDFS架构，同时介绍了我们在雅虎使用HDFS去管理25PB企业数据的经验。 1、介绍和相关工作 Hadoop 的 一个重要特点是将数据和计算能力划分为小部分，通过许多（数千）主机运行 ，这些主机并行计算得到他们的结果。一个 Hadoop 集群通过简单增加商用服务器的数量来扩展其计算能力，存储能力和 IO 带宽。 1.1、与其他分布式系统的异同点 相同点 HDFS 分别存储文件系统元数据和应用程序数据。 与在 其他分布式文件系统 中相同， 比如 PVFS 【 2 】【 14 】， Lustre 【 7 】和 GFS 【 5 】【 8 】， HDFS 在一个专门的服务器存储元数据，这个服务器被称为名称节点。应用程序数据存储在其他被称为数据结点的服务器上。 不同点 HDFS中的数据节点 并不使用数据保护机制 比如RAID（ 独立磁盘冗余阵列 ），以确保数据持久性。 相反。比如GFS， 其文件内容在多个数据节点是重复的以确保可靠性 。 这个策略不仅仅可以确保数据持久性，还有额外的优点：数据变形带宽加倍

一、架构简介 目标 单机搭建mongodb分布式集群(副本集 + 分片集群)，演示mongodb分布式集群的安装部署、简单操作。 说明 在同一个vm启动由两个分片组成的分布式集群，每个分片都是一个PSS(Primary-Secondary-Secondary)模式的数据副本集； Config副本集采用PSS(Primary-Secondary-Secondary)模式。 二、配置说明 端口通讯 当前集群中存在shard、config、mongos共12个进程节点，端口矩阵编排如下： 编号 实例类型 1 mongos 2 mongos 3 mongos 4 config 5 config 6 config 7 shard1 8 shard1 9 shard1 10 shard2 11 shard2 12 shard2 内部鉴权 节点间鉴权采用keyfile方式实现鉴权，mongos与分片之间、副本集节点之间共享同一套keyfile文件。 官方说明 账户设置 管理员账户：admin/Admin @01 ，具有集群及所有库的管理权限 应用账号：appuser/AppUser @01 ，具有appdb的owner权限 关于初始化权限 keyfile方式默认会开启鉴权，而针对初始化安装的场景，Mongodb提供了 localhost-exception机制 ，