centos微服务 centos官网

微服务基础服务之docker篇

什么是docker

Docker最初是 dotCloud公司创始人 Solomon Hykes在法国期间发起的一个公司内部项目，它是基于 dotCloud公司多年云服务技术的一次革新，并于 2013年 3月以 Apache 2.0授权协议开源，主要项目代码在 GitHub上进行维护。Docker项目后来还加入了 Linux基金会，并成立推动开放容器联盟（OCI）。

Docker使用 Google公司推出的 Go语言进行开发实现，基于 Linux内核的 cgroup，namespace，以及 AUFS类的 Union FS等技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 LXC，从 0.7版本以后开始去除 LXC，转而使用自行开发的 libcontainer，从 1.11开始，则进一步演进为使用 runC和 containerd。

Docker在容器的基础上，进行了进一步的封装，从文件系统、网络互联到进程隔离等等，极大的简化了容器的创建和维护。使得 Docker技术比虚拟机技术更为轻便、快捷。

下面的图片比较了 Docker和传统虚拟化方式的不同之处。传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。



传统虚拟化



Docker

为什么要用docker

对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。

使用 Docker可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile来进行镜像构建，并结合持续集成(Continuous Integration)系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合持续部署(Continuous Delivery/Deployment)系统进行自动部署。

而且使用 Dockerfile使镜像构建透明化，不仅仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。

特性容器虚拟机启动秒级分钟级硬盘使用一般为MB一般为GB性能接近原生弱于系统支持量单机支持上千个容器一般几十个

基本概念

我们都知道，操作系统分为内核和用户空间。对于 Linux而言，内核启动后，会挂载 root文件系统为其提供用户空间支持。而 Docker镜像（Image），就相当于是一个 root文件系统。比如官方镜像 ubuntu:18.04就包含了完整的一套 Ubuntu 18.04最小系统的 root文件系统。

Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为容器存储层。

按照 Docker最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入操作，都应该使用数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。

数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此，使用数据卷后，容器删除或者重新运行之后，数据却不会丢失。

镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry就是这样的服务。

一个 Docker Registry中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。

通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过<仓库名>:<标签>的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest作为默认标签。

Centos安装docker18

常用的docker命令

常用的docker镜像

redis

mysql

RocketMQ 千锤百炼哈啰在分布式消息治理和微服务治理中的实践

简介：随着公司业务的不断发展，流量也在不断增长。我们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。

哈啰已进化为包括两轮出行（哈啰单车、哈啰助力车、哈啰电动车、小哈换电）、四轮出行（哈啰顺风车、全网叫车、哈啰打车）等的综合化移动出行平台，并向酒店、到店团购等众多本地生活化生态探索。

随着公司业务的不断发展，流量也在不断增长。我们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。

本文就哈啰在消息流量和微服务调用的治理中踩过的坑、积累的经验进行分享。

梁勇(老梁)，《 RocketMQ实战与进阶》专栏联合作者、参与了《 RocketMQ技术内幕》审稿工作。ArchSummit全球架构师大会讲师、QCon案例研习社讲师。

当前主要在后端中间件方向，在公众号【瓜农老梁】已陆续发表百余篇源码实战类文章，涵盖 RocketMQ系列、Kafka系列、GRPC系列、Nacosl系列、Sentinel系列、Java NIO系列。目前就职于哈啰出行，任职高级技术专家。

开始之前先聊聊治理这件事情，下面是老梁个人理解：

公司之前使用 RabbitMQ，下面在使用 RabbitMQ时的痛点，其中很多事故由于 RabbitMQ集群限流引起的。

曾经有这么一个故障，多个业务共用一个数据库。在一次晚高峰流量陡增，把数据库打挂了。

思考：无论消息还是服务都需要完善的治理措施

哪些是我们的关键指标，哪些是我们的次要指标，这是消息治理的首要问题。

设计目标

旨在屏蔽底层各个中间件（ RocketMQ/ Kafka）的复杂性，通过唯一标识动态路由消息。同时打造集资源管控、检索、监控、告警、巡检、容灾、可视化运维等一体化的消息治理平台，保障消息中间件平稳健康运行。

把复杂的问题搞简单，那是能耐。

极简统一 API

提供统一的 SDK封装了（ Kafka/ RocketMQ）两种消息中间件。

主题消费组自动创建不适合生产环境，自动创建会导致失控，不利于整个生命周期管理和集群稳定。需要对申请流程进行控制，但是应尽可能简单。例如：一次申请各个环境均生效、生成关联告警规则等。

监控客户端使用是否规范，找到合适的措施治理

场景一瞬时流量与集群的流控

假设现在集群 Tps有 1万，瞬时翻到 2万甚至更多，这种过度陡增的流量极有可能引发集群流控。针对这类场景需监控客户端的发送速度，在满足速度和陡增幅度阈值后将发送变的平缓一些。

场景二大消息与集群抖动

当客户端发送大消息时，例如：发送几百KB甚至几兆的消息，可能造成 IO时间过长与集群抖动。针对这类场景治理需监控发送消息的大小，我们采取通过事后巡检的方式识别出大消息的服务，推动使用同学压缩或重构，消息控制在 10KB以内。

场景三过低客户端版本

随着功能的迭代 SDK的版本也会升级，变更除了功能外还有可能引入风险。当使用过低的版本时一个是功能不能得到支持，另外一个是也可能存在安全隐患。为了解 SDK使用情况，可以采取将 SDK版本上报，通过巡检的方式推动使用同学升级。

场景四消费流量摘除和恢复

消费流量摘除和恢复通常有以下使用场景，第一个是发布应用时需要先摘流量，另外一个是问题定位时希望先把流量摘除掉再去排查。为了支持这种场景，需要在客户端监听摘除/恢复事件，将消费暂停和恢复。

场景五发送/消费耗时检测

发送/消费一条消息用了多久，通过监控耗时情况，巡检摸排出性能过低的应用，针对性推动改造达到提升性能的目的。

场景六提升排查定位效率

在排查问题时，往往需要检索发了什么消息、存在哪里、什么时候消费的等消息生命周期相关的内容。这部分可以通过 msgId在消息内部将生命周期串联起来。另外是通过在消息头部埋入 rpcId/ traceId类似链路标识，在一次请求中将消息串起来。

需要的监控信息

常用治理措施

监控主题消费组资源使用情况

场景一消费积压对业务的影响

有些业务场景对消费堆积很敏感，有些业务对积压不敏感，只要后面追上来消费掉即可。例如单车开锁是秒级的事情，而信息汇总相关的批处理场景对积压不敏感。通过采集消费积压指标，对满足阈值的应用采取实时告警的方式通知到应用负责的同学，让他们实时掌握消费情况。

场景二消费/发送速度的影响

发送/消费速度跌零告警？有些场景速度不能跌零，如果跌零意味着业务出现异常。通过采集速度指标，对满足阈值的应用实时告警。

场景三消费节点掉线

消费节点掉线需要通知给应用负责的同学，这类需要采集注册节点信息，当掉线时能实时触发告警通知。

场景四发送/消费不均衡

发送/消费的不均衡往往影响其性能。记得有一次咨询时有同学将发送消息的key设置成常量，默认按照 key进行 hash选择分区，所有的消息进入了一个分区里，这个性能是无论如何也上不来的。另外还要检测各个分区的消费积压情况，出现过度不均衡时触发实时告警通知。

需要的监控信息

常用治理措施

度量集群健康的核心指标有哪些？

场景一集群健康检测

集群健康检测回答一个问题：这个集群是不是好的。通过检测集群节点数量、集群中每个节点心跳、集群写入Tps水位、集群消费Tps水位都是在解决这个问题。

场景二集群的稳定性

集群流控往往体现出集群性能的不足，集群抖动也会引发客户端发送超时。通过采集集群中每个节点心跳耗时情况、集群写入Tps水位的变化率来掌握集群是否稳定。

场景三集群的高可用

高可用主要针对极端场景中导致某个可用区不可用、或者集群上某些主题和消费组异常需要有一些针对性的措施。例如：MQ可以通过同城跨可用区主从交叉部署、动态将主题和消费组迁移到灾备集群、多活等方式进行解决。

需要的监控信息

常用治理措施

如果说这些关键指标中哪一个最重要？我会选择集群中每个节点的心跳检测，即：响应时间（ RT），下面看看影响 RT可能哪些原因。

我们总会遇到坑，遇到就把它填了。

**

RocketMQ从节点、主节点频繁 CPU飙高，很明显的毛刺，很多次从节点直接挂掉了。

只有系统日志有错误提示

2020-03-16T17:56:07.505715+08:00 VECS0xxxx kernel:[]? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505717+08:00 VECS0xxxx kernel: java: page allocation failure. order:0, mode:0x202020-03-16T17:56:07.505719+08:00 VECS0xxxx kernel: Pid: 12845, comm: java Not tainted 2.6.32-754.17.1.el6.x86_64#12020-03-16T17:56:07.505721+08:00 VECS0xxxx kernel: Call Trace:2020-03-16T17:56:07.505724+08:00 VECS0xxxx kernel:[]? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505726+08:00 VECS0xxxx kernel: []? dev_queue_xmit+0xd0/0x3602020-03-16T17:56:07.505729+08:00 VECS0xxxx kernel: []? ip_finish_output+0x192/0x3802020-03-16T17:56:07.505732+08:00 VECS0xxxx kernel: []?

各种调试系统参数只能减缓但是不能根除，依然毛刺超过 50%

将集群所有系统升级从 centos 6升级到 centos 7，内核版本也从从 2.6升级到 3.10，CPU毛刺消失。

RocketMQ社区版默认本支持 18个延迟级别，每个级别在设定的时间都被会消费者准确消费到。为此也专门测试过消费的间隔是不是准确，测试结果显示很准确。然而，如此准确的特性居然出问题了，接到业务同学报告线上某个集群延迟消息消费不到，诡异！

将" delayOffset.json"和" consumequeue/ SCHEDULE_TOPIC_XXXX"移到其他目录，相当于删除；逐台重启 broker节点。重启结束后，经过验证，延迟消息功能正常发送和消费。

哪些是我们的核心服务，哪些是我们的非核心服务，这是服务治理的首要问题

服务能应对突如其来的陡增流量，尤其保障核心服务的平稳运行。

根据用户和业务影响两个纬度来进行评估设定的，将应用分成了四个等级。

S1：核心产品，产生故障会引起外部用户无法使用或造成较大资损，比如主营业务核心链路，如单车、助力车开关锁、顺风车的发单和接单核心链路，以及其核心链路强依赖的应用。

S2:不直接影响交易，但关系到前台业务重要配置的管理与维护或业务后台处理的功能。

S3:服务故障对用户或核心产品逻辑影响非常小，且对主要业务没影响，或量较小的新业务；面向内部用户使用的重要工具，不直接影响业务，但相关管理功能对前台业务影响也较小。

S4:面向内部用户使用，不直接影响业务，或后续需要推动下线的系统。

S1服务是公司的核心服务，是重点保障的对象，需保障其不被非核心服务流量意外冲击。

**

**

Alpine、Debian、Ubuntu、Centos,谁是最佳选择

本文将为您比较几种常见的Linux基础镜像：Alpine、Debian、Ubuntu和CentOS，以帮助您根据应用程序的需求做出最佳选择。

1. Alpine

轻量级的Alpine Linux以其小巧（通常几MB）和安全性闻名，是构建微服务和容器化应用的理想选择。其包管理工具apk支持从官方和社区仓库安装，例如使用docker build-f Dockerfile-Alpine-t hello-py:alpine.构建镜像。

2. Debian/Ubuntu

Debian和Ubuntu提供广泛的软件包和工具，适合不同应用场景。apt是它们的包管理器，如apt update和apt install-y。它们的镜像较大，但功能全面。例如，构建Dockerfile为hello-py:debian。

3. CentOS

CentOS基于RHEL，提供稳定环境，但新版本更新较少。对于稳定性和兼容性，推荐考虑更小的基础镜像。通过yum进行包管理，但构建时可能需要考虑镜像大小。

镜像大小对比

Alpine镜像最小（108MB），其次是Ubuntu（548MB），Debian（124MB），CentOS（231MB）。通常推荐使用Alpine以减小镜像体积。

实践建议

在选择基础镜像时，首先在Docker Hub查找官方或合适的镜像，如基于python:3.11.9-alpine3.19构建。根据需要，使用对应的包管理工具在Dockerfile中安装软件包。

总结来说，最佳选择取决于你的具体需求，但Alpine以其小巧和高效通常被推荐为首选。