首页 文章 精选 留言 我的

精选列表

搜索[推荐引擎],共10000篇文章
优秀的个人博客,低调大师

推荐个开源在线文档,助道友领悟 Django 之“道”

本文面向有手(需要一点点 Python Django 基础)的小伙伴,急需文档管理者食用最佳。 作者:HelloGitHub-吱吱(首发于 HelloGitHub 公众号) 嗷嗷待哺的小白:“今天又是沉迷花里胡哨博客的一天,我希望归档一类知识或者是连载一些教程,而博客都是一篇篇散落的,没有连贯性,阅读体验不太良好,怎么办呢?” HelloGitHub:“那你可是问对人了,这期 《讲解开源项目》 系列的新项目:MrDoc 觅道文档,将会解决你的烦恼。” 小白:“这又是什么神奇的开源工具。” HelloGitHub:“这是一个基于 Django 开发的在线文档系统,适合作为个人和小型团队的私有云文档、云笔记和知识管理工具。你看它界面简洁,功能俱全,部署简单。话不多说,直接开始实践检验真理!” 一、简单测试 HelloGitHub:“嘿嘿,先别着急,我们先在本地平台运行,测试测试功能,了解这个项目的基本使用,再一步步往前走。” 仅需 6 步你就可以从零运行起来这个项目! 1、我们本地的实验环境是: Windows 10 64 位操作系统 Python 3.7,pip 21.0.1 2、我们需要将开源项目克隆到本地,使用如下命令: git clone https://github.com/zmister2016/MrDoc 3、为 MrDoc 安装好所需的第三方库:进入 Mrdoc/ 目录,运行如下命令: 4、初始化数据库,该项目默认使用 sqlite 数据库。在命令行下执行: 5、创建管理员账户,来管理整个 MrDoc 应用。注意用户名和电子邮箱地址在整个 MrDoc 应用中是唯一的。 6、本地上线测试:在测试环境中,可以使用 Django 自带的服务器运行 MrDoc。 二、食用说明 小白搓搓手,期待:“我也在本地测试成功了,是不是可以探索一番里面的彩蛋呢?” HelloGitHub:“好嘞,项目主打的关键字就是:个人团队协作和文档管理,让我现在来给你展现一下五脏俱全的 MrDoc。” 2.1 注册登录 HelloGitHub:“当我们访问网站的时候,以游客身份进行的。假如我们需要注册一个普通用户的帐号,则需要填写相应的表单信息,注册完毕后会自动跳转到已登录界面。” 小白:“补充:其实如果游客想点击 新建 → 新建文档,也是需要登录操作的哟。” 2.2 文集文档 HelloGitHub:“当我们登录以后,可以在 新建 → 新建文集 中创建一个文集。” 小白:“我发现了,可以点击首页的文集,进入到文集的浏览阅读页面,还可以用 添加 新建一个文档。在进入文档编辑器页面,我们可以 点击文档树 选择当前文档对应的上级或者 取消上级,以及通过输入 文档排序值,来给不同文档排序。” HelloGitHub:“嗯呐,现在我们就不用担心教程学习类的文章不连续啦,因为他们都有层次顺序的分布在我们的文集中。不过因为目前 MrDoc 最多支持 3 级的文档,可别让自己的文档树太大鸭。” HelloGitHub:“非常重要的一点是团队的共享和协作。我们普通用户可以对自己的文集进行管理,点击 个人中心 → 我的文集 → 文集管理 → 文集成员 处的 协作管理 小图标,可以添加协作人。而且在 文集管理 → 操作 → 文集设置 小图标可以修改 基础信息、权限配置 和 管理控制。当权限设置为公开时,则当以游客身份访问网页的时候能够看到该文集;当权限设置为私密,则只有自己能看到。当然也可以给固定的人看,这也就能实现了小团队的共享。” 2.3 文档编辑 HelloGitHub:“现在我们把目光投向 MrDoc 的文档编辑和修改模块,它支持以 Markdown 和富文本两种方式进行文档编写,给我们提供了 3 种编辑器使用。它能支持插入数学公式、流程图、序列图、脑图、Echarts 图形图表和时间线,能够添加音视频链接和图片附件等,能够创建文档模板,总之是概括不完了,图也上不完了,需要在使用过程中慢慢的熟练。” 小白:“我现在也看得懂了,在 个人中心 → 我的文档 → 文档管理 中可以统一管理创建的所有文档,还可以看到 历史版本管理 信息呢,方便了用户进行对比,也方便了团队协作的管理。” 2.4 后台管理【管理员】 HelloGitHub:“大 boss 的权限必然是很高的,一切都收之眼底,包括用户的文集、文档、文档模块,还可以进行用户管理和站点设置。” 小白:“那我就做自己的主宰好了。” 三、上线部署 HelloGitHub:“已经了解了一些功能了,但是只在本地跑会不会太拉垮了,是不是得考虑将这个项目部署到我们的云服务器上,让自己的小团队实现高大上的知识协作管理呀。” 小白:“可以和组里的小伙伴多了一个摸鱼工具,想想就很开心~” HelloGitHub:“先部署好吧,谁知道过程中会出现一堆坑呢。为了比较顺利的进行,我们这次的方法就选用官方提供的比较完整的教程:使用 Nginx + uWSGI 部署 MrDoc。” 1、我们云主机的环境是: Ubuntu 18.04.4 LTS Python 3.6.9,pip 21.0.1 在 ~ 目录下进行,即用 pwd 命令查看为:/home/purple,小伙伴们改成自己对应的目录 2、安装 uWSGI 和 Nginx: sudo apt-get install uwsgi sudo apt install uwsgi-plugin-python3 sudo apt-get install nginx 3、将 MrDoc 的源码拉取至本地(用之前的命令),但是为了不对服务器上现存的环境造成影响,我们这次需要用到虚拟环境: 4、进入 MrDoc 文件夹,重复简单测试的 3、4、5 步骤,分别实现依赖库的安装、初始化数据库以及创建管理员账号(略)。 5、我们在 ~ 目录下新建一个名为 mrdoc_deploy 的文件夹,命令如下所示,用于存放部署的相关文件。 mkdir /home/purple/mrdoc_deploy (1) uWSGI 配置文件: 在 mrdoc_deploy 目录下新建一个名为 uwsgi_params 的文件,用 vim uwsgi_params 命令进行写入: uwsgi_param QUERY_STRING $query_string; uwsgi_param REQUEST_METHOD $request_method; uwsgi_param CONTENT_TYPE $content_type; uwsgi_param CONTENT_LENGTH $content_length; uwsgi_param REQUEST_URI $request_uri; uwsgi_param PATH_INFO $document_uri; uwsgi_param DOCUMENT_ROOT $document_root; uwsgi_param SERVER_PROTOCOL $server_protocol; uwsgi_param REQUEST_SCHEME $scheme; uwsgi_param HTTPS $https if_not_empty; uwsgi_param REMOTE_ADDR $remote_addr; uwsgi_param REMOTE_PORT $remote_port; uwsgi_param SERVER_PORT $server_port; uwsgi_param SERVER_NAME $server_name; 在 mrdoc_deploy 目录下新建一个名为 mrdoc_uwsgi.ini 的文件,同理用 vim mrdoc_uwsgi.ini 写入: [uwsgi] # Django-related settings socket = :8008 # the base directory (full path) chdir = /home/purple/MrDoc virtualenv = /home/purple/mrdoc_env # Django s wsgi file module = MrDoc.wsgi:application wsgi-file = MrDoc/wsgi.py # process-related settings # master master = true # maximum number of worker processes processes = 1 threads = 2 # ... with appropriate permissions - may be needed # chmod-socket = 664 # clear environment on exit plugins = python3 vacuum = true python-autoreload = 1 # buffer size buffer-size = 65536 注:如果后续运行服务的时候出现如下问题,则需要调整 mrdoc_uwsgi.ini 下的 buffer-size 参数。 spawned uWSGI master process (pid: 21172) spawned uWSGI worker 1 (pid: 21173, cores: 2) invalid request block size: 21573 (max 4096)...skip invalid request block size: 21573 (max 4096)...skip (2) Nginx 配置文件 在 mrdoc_deploy 目录下新建一个名为 mrdoc_nginx.conf 的文件,使用命令 vim mrdoc_nginx.conf 写入如下内容: server { listen 80; server_name 此处填入域名; charset UTF-8; access_log /var/log/nginx/mrdoc_access.log; error_log /var/log/nginx/mrdoc_error.log; client_max_body_size 75M; location / { include /home/purple/mrdoc_deploy/uwsgi_params; uwsgi_pass 127.0.0.1:8008; uwsgi_read_timeout 60; } location /static { expires 30d; autoindex on; add_header Cache-Control private; alias /home/purple/MrDoc/static; } location /media { alias /home/purple/MrDoc/media; } } 注意在 server_name 参数中,需要填入自己的域名。此处我填的是云主机的公网 IP 地址,之后访问网站则需要输入该 IP 地址。 (3) 为了能让 MrDoc 应用按我们的要求运行,使用 systemctl 工具来管理服务。 在 mrdoc_deploy 目录下新建一个名为 mrdoc.service 的文件,用命令 vim mrdoc.service 将如下内容写入文件: [Unit] Description = MrdocApp After = syslog.target [Install] WantedBy = multi-user.target [Service] WorkingDirectory = /home/purple/MrDoc ExecStart = /usr/bin/uwsgi --ini /home/purple/mrdoc_deploy/mrdoc_uwsgi.ini User = purple Restart = always StandardError = syslog~ 6、添加进程管理 sudo systemctl enable /home/zmister/mrdoc_deploy/mrdoc.service 7、创建 Nginx 站点软链接 sudo ln -s /home/zmister/mrdoc_deploy/mrdoc_nginx.conf /etc/nginx/sites-enabled/mrdoc_nginx.conf 8、启动 MrDoc 服务 sudo systemctl start mrdoc.service 注意:当试图启动的时候,出现如下报错。原因是:在配置 mrdoc.service 的时候 ExecStart 参数如果按照官方文档写的是 uwsgi,但实际上应该写成绝对路径(可以查看一下自己的路径),我的是 /usr/bin/uwsgi。 (mrdoc_env) purple@VM-Purplezi-Ubuntu ~ % sudo systemctl start mrdoc.service Failed to start mrdoc.service: Unit mrdoc.service is not loaded properly: Exec format error. See system logs and 'systemctl status mrdoc.service' for details. 四、最后的最后 小白:“课代表来了,一句话总结,只需要在部署的时候费点劲,之后就可以体验这个项目带给我们的方便快捷了,有手即可。” HelloGitHub:“在官方文档中,其实还有一些功能没有覆盖到,比如说作者还提供了 MrDoc 浏览器扩展,有空记得去看看哇。记得要第一时间关注我们,我们将会不间断正常运行为您带来有趣的开源项目分享。” 关注 HelloGitHub 公众号 第一时间收到更新。 还有更多开源项目的介绍和宝藏项目等待你的发现。

优秀的个人博客,低调大师

动态高并发时为什么推荐ReentrantLock而不是Synchronized?

前言碎语 Synchronized 和 ReentrantLock 大家应该都不陌生了,作为java中最常用的本地锁,最初版本中 ReentrantLock 的性能是远远强于 Synchronized 的,后续java在一次次的版本迭代中 对 Synchronized 进行了大量的优化,直到 jdk1.6 之后,两种锁的性能已经相差无几,甚至 Synchronized 的自动释放锁会更好用。 在面试时被问到 Synchronized 和 ReentrantLock 的使用选择时,很多朋友都脱口而出的说用 Synchronized ,甚至在我面试的时候问面试者,也很少有人能够答出所以然来,moon 想说,这可不一定,只对标题感兴趣的同学可以直接划到最后,我可不是标题党~ Synchronized使用 在 java 代码中 synchronized 的使用是非常简单的 1.直接贴在方法上 2.贴在代码块儿上 程序运行期间,Synchronized那一块儿代码发生么什么? 来看一张图 在多线程运行过程中,线程会去先抢对象的监视器,这个监视器是对象独有的,其实就相当于一把钥匙,抢到了,那你就获得了当前代码块儿的执行权。 其他没有抢到的线程会进入队列(SynchronizedQueue)当中等待,等待当前线程执行完后,释放锁. 最后当前线程执行完毕后通知出队然后继续重复当前过程. 从 jvm 的角度来看 monitorenter 和 monitorexit 指令代表着代码的执行与结束。 SynchronizedQueue: SynchronizedQueue 是一个比较特殊的队列,它没有存储功能,它的功能就是维护一组线程,其中每个插入操作必须等待另一个线程的移除操作,同样任何一个移除操作都等待另一个线程的插入操作。因此此队列内部其 实没有任何一个元素,或者说容量是0,严格说并不是一种容器。由于队列没有容量,因此不能调用 peek 操作,因为只有移除元素时才有元素。 举个例子: 喝酒的时候,先把酒倒入酒盅,然后再倒入酒杯,这就是正常的队列。 喝酒的时候,把酒直接倒入酒杯,这就是 SynchronizedQueue 。 这个例子应该很清晰易懂了,它的好处就是可以直接传递,省去了一个第三方传递的过程。 聊聊细节,锁升级的过程 在 jdk1.6 以前,Synchronized 是一个重量级锁,还是先贴一张图 这就是为什么说,Synchronized 是一个重量级锁的原因,因为每一次锁的资源都是直接和 cpu 去申请的,而 cpu 的锁数量是固定的,当 cpu 锁资源使用完后还会进行锁等待,这是一个非常耗时的操作。 但是在jdk1.6,针对代码层面进行了大量的优化,也就是我们常说的锁升级的过程。 这就是一个锁升级的过程,我们简单的说说: 无锁:对象一开始就是无锁状态。 偏向锁:相当于给对象贴了一个标签(将自己的线程 id 存入对象头中),下次我再进来时,发现标签是我的,我就可以继续使用了。 自旋锁:想象一下有一个厕所,里面有一个人在,你很想上但是只有一个坑位,所以你只能徘徊等待,等那个人出来以后,你就可以使用了。 这个自旋是使用 cas 来保证原子性的,关于 cas 我这里就不再赘述了。 重量级锁:直接向 cpu 去申请申请锁,其他的线程都进入队列中等待。 锁升级是什么时候发生的? 偏向锁:一个线程获取锁时会由无锁升级为偏向锁 自旋锁:当产生线程竞争时由偏向锁升级为自旋锁,想象一下 while(true) ; 重量级锁:当线程竞争到达一定数量或超过一定时间时,晋升为重量级锁 锁的信息是记录在哪里的? 这张图是对象头中 markword 的数据结构,锁的信息就是在这里存放的,很清楚的表明了锁在升级的时候锁信息的变动,其实就是通过二进制的数值,来对对象进行一个标记,每个数值代表一种状态。 既然synchronized有锁升级那么有锁降级吗? 这个问题和我们的题目就有很大的关联了。 在 HotSpot 虚拟机中是有锁降级的,但是仅仅只发生在 STW 的时候,只有垃圾回收线程能够观测到它,也就是说,在我们正常使用的过程中是不会发生锁降级的,只有在 GC 的时候才会降级。 所以题目的答案,你懂了吗?哈哈,我们接着往下走。 ReentrantLock的使用 ReentrantLock 的使用也是非常简单的,与 Synchronized 的不同就是需要自己去手动释放锁,为了保证一定释放,所以通常都是和 try~finally 配合使用的。 ReentrantLock的原理 ReentrantLock 意为可重入锁,说起 ReentrantLock 就不得不说 AQS ,因为其底层就是使用 AQS 去实现的。 ReentrantLock有两种模式,一种是公平锁,一种是非公平锁。 公平模式下等待线程入队列后会严格按照队列顺序去执行 非公平模式下等待线程入队列后有可能会出现插队情况 这就是ReentrantLock的结构图,我们看这张图其实是很简单的,因为主要的实现都交给AQS去做了,我们下面着重聊一下AQS。 AQS AQS(AbstractQueuedSynchronizer): AQS 可以理解为就是一个可以实现锁的框架。 简单的流程理解: 公平锁: 第一步:获取状态的 state 的值。 如果 state=0 即代表锁没有被其它线程占用,执行第二步。 如果 state!=0 则代表锁正在被其它线程占用,执行第三步。 第二步:判断队列中是否有线程在排队等待。 如果不存在则直接将锁的所有者设置成当前线程,且更新状态 state 。 如果存在就入队。 第三步:判断锁的所有者是不是当前线程。 如果是则更新状态 state 的值。 如果不是,线程进入队列排队等待。 非公平锁: 第一步:获取状态的 state 的值。 如果 state=0 即代表锁没有被其它线程占用,则设置当前锁的持有者为当前线程,该操作用 CAS 完成。 如果不为0或者设置失败,代表锁被占用进行下一步。 此时获取 state 的值, 如果是0,代表刚好线程释放了锁,此时将锁的持有者设为自己 如果不是0,则查看线程持有者是不是自己 如果是,则给state+1,获取锁 如果不是,则进入队列等待 读完以上的部分相信你对AQS已经有了一个比较清楚的概念了,所以我们来聊聊小细节。 AQS使用state同步状态(0代表无锁,1代表有),并暴露出 getState 、 setState 以及 compareAndSet 操作来读取和更新这个状态,使得仅当同步状态拥有一个期望值的时候,才会被原子地设置成新值。 当有线程获取锁失败后,AQS是通过一个双向的同步队列来完成同步状态的管理,就被添加到队列末尾。 这是定义头尾节点的代码,我们可以先使用 volatile 去修饰的,就是保证让其他线程可见,AQS 实际上就是修改头尾两个节点来完成入队和出队操作的。 AQS 在锁的获取时,并不一定只有一个线程才能持有这个锁,所以此时有了独占模式和共享模式的区别,我们本篇文章中的 ReentrantLock 使用的就是独占模式,在多线程的情况下只会有一个线程获取锁。 独占模式的流程是比较简单的,就根据state是否为0来判断是否有线程已经获得了锁,没有就阻塞,有就继续执行后续代码逻辑。 共享模式的流程根据state是否大于0来判断是否有线程已经获得了锁,如果不大于0,就阻塞,如果大于0,通过CAS的原子操作来自减state的值,然后继续执行后续代码逻辑。 ReentrantLock和Synchronized的区别 其实ReentrantLock和Synchronized最核心的区别就在于Synchronized适合于并发竞争低的情况,因为Synchronized的锁升级如果最终升级为重量级锁在使用的过程中是没有办法消除的,意味着每次都要和cpu去请求锁资源,而ReentrantLock主要是提供了阻塞的能力,通过在高并发下线程的挂起,来减少竞争,提高并发能力,所以我们文章标题的答案,也就显而易见了。 synchronized是一个关键字,是由jvm层面去实现的,而ReentrantLock是由java api去实现的。 synchronized是隐式锁,可以自动释放锁,ReentrantLock是显式锁,需要手动释放锁。 ReentrantLock可以让等待锁的线程响应中断,而synchronized却不行,使用synchronized时,等待的线程会一直等待下去,不能够响应中断。 ReentrantLock可以获取锁状态,而synchronized不能。 说说标题的答案 其实题目的答案就在上一栏目的第一条,也是核心的区别,synchronized升级为重量级锁后无法在正常情况下完成降级,而ReentrantLock是通过阻塞来提高性能的,在设计模式上就体现出了对多线程情况的支持。

优秀的个人博客,低调大师

微服务海量日志怎么处理,推荐你试试这款工具....

云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 背景 在企业级的微服务环境中,跑着成百上千个服务都算是比较小的规模了。在生产环境上,日志扮演着很重要的角色,排查异常需要日志,性能优化需要日志,业务排查需要业务等等。然而在生产上跑着成百上千个服务,每个服务都只会简单的本地化存储,当需要日志协助排查问题时,很难找到日志所在的节点。也很难挖掘业务日志的数据价值。 那么将日志统一输出到一个地方集中管理,然后将日志处理化,把结果输出成运维、研发可用的数据是解决日志管理、协助运维的可行方案,也是企业迫切解决日志的需求。 我们的解决方案 通过上面的需求我们推出了日志监控系统。 日志统一收集、过滤清洗。 生成可视化界面、监控,告警,日志搜索。 功能流程概览 在每个服务节点上埋点,实时采集相关日志。 统一日志收集服务、过滤、清洗日志后生成可视化界面、告警功能。 我们的架构 1、日志文件采集端我们使用filebeat,运维通过我们的后台管理界面化配置,每个机器对应一个filebeat,每个filebeat日志对应的topic可以是一对一、多对一,根据日常的日志量配置不同的策略。 除了采集业务服务日志外,我们还收集了mysql的慢查询日志和错误日志,还有别的第三方服务日志,如:nginx等。最后结合我们的自动化发布平台,自动发布并启动每一个filebeat进程。 2、调用栈、链路、进程监控指标我们使用的代理方式:Elastic APM,这样对于业务侧的程序无需任何改动。对于已经在运营中的业务系统来说,为了加入监控而需要改动代码,那是不可取的,也是无法接受的。Elastic APM可以帮我们收集http接口的调用链路、内部方法调用栈、使用的sql、进程的cpu、内存使用指标等。 可能有人会有疑问,用了Elastic APM,其它日志基本都可以不用采集了。还要用filebeat干嘛?是的,Elastic APM采集的信息确实能帮我们定位80%以上的问题,但是它不是所有的语言都支持的比如:C。 其二、它无法帮你采集你想要的非error日志和所谓的关键日志,比如:某个接口调用时出了错,你想看出错时间点的前后日志;还有打印业务相关方便做分析的日志。 其三、自定义的业务异常,该异常属于非系统异常,属于业务范畴,APM会把这类异常当成系统异常上报,如果你后面对系统异常做告警,那这些异常将会干扰告警的准确度,你也不能去过滤业务异常,因为自定义的业务异常种类也不少。 3、同时我们对agent进行了二开。采集更详细的gc、堆栈、内存、线程信息。 4、服务器采集我们采用普罗米修斯。 5、由于我们是saas服务化,服务N多,很多的服务日志做不到统一规范化,这也跟历史遗留问题有关,一个与业务系统无关的系统去间接或直接地去对接已有的业务系统,为了适配自己而让其更改代码,那是推不动的。牛逼的设计是让自己去兼容别人,把对方当成攻击自己的对象。 很多日志是没有意义的,比如:开发过程中为了方便排查跟踪问题,在if else里打印只是有标志性的日志,代表是走了if代码块还是else代码块。甚至有些服务还打印着debug级别的日志。在成本、资源的有限条件下,所有所有的日志是不现实的,即使资源允许,一年下来将是一比很大的开销。所以我们采用了过滤、清洗、动态调整日志优先级采集等方案。首先把日志全量采集到kafka集群中,设定一个很短的有效期。我们目前设置的是一个小时,一个小时的数据量,我们的资源暂时还能接受。 6、Log Streams是我们的日志过滤、清洗的流处理服务。为什么还要ETL过滤器呢?因为我们的日志服务资源有限,但不对啊,原来的日志分散在各各服务的本地存储介质上也是需要资源的哈。现在我们也只是汇集而已哈,收集上来后,原来在各服务上的资源就可以释放掉日志占用的部分资源了呀。 没错,这样算确实是把原来在各服务上的资源化分到了日志服务资源上来而已,并没有增加资源。不过这只是理论上的,在线上的服务,资源扩大容易,收缩就没那么容易了,实施起来极其困难。所以短时间内是不可能在各服务上使用的日志资源化分到日志服务上来的。这样的话,日志服务的资源就是当前所有服务日志使用资源的量。随存储的时间越长,资源消耗越大。如果解决一个非业务或非解决不可的问题,在短时间内需要投入的成本大于解决当前问题所带来收益的话,我想,在资金有限的情况下,没有哪个领导、公司愿意采纳的方案。 所以从成本上考虑,我们在Log Streams服务引入了过滤器,过滤没有价值的日志数据,从而减少了日志服务使用的资源成本。技术我们采用Kafka Streams作为ETL流处理。通过界面化配置实现动态过滤清洗的规则: 界面化配置日志采集。默认error级别的日志全量采集 以错误时间点为中心,在流处理中开窗,辐射上下可配的N时间点采集非error级别日志,默认只采info级别 每个服务可配100个关键日志,默认关键日志全量采集 在慢sql的基础上,按业务分类配置不同的耗时再次过滤 按业务需求实时统计业务sql,比如:高峰期阶段,统计一小时内同类业务sql的查询频率。可为dba提供优化数据库的依据,如按查询的sql创建索引 高峰时段按业务类型的权重指标、日志等级指标、每个服务在一个时段内日志最大限制量指标、时间段指标等动态清洗过滤日志 根据不同的时间段动态收缩时间窗口 日志索引生成规则:按服务生成的日志文件规则生成对应的index,比如:某个服务日志分为:debug、info、error、xx_keyword,那么生成的索引也是debug、info、error、xx_keyword加日期作后缀。这样做的目的是为研发以原习惯性地去使用日志 7、可视化界面我们主要使用grafana,它支持的众多数据源中,其中就有普罗米修斯和elasticsearch,与普罗米修斯可谓是无缝对接。而kibana我们主要用于apm的可视分析。 日志可视化 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/zhibo 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-07-14本文作者: 非洲羚羊本文来自:“互联网架构师”,了解相关信息可以关注“互联网架构师”

优秀的个人博客,低调大师

推荐:一款分布式的对象存储服务

最近公司在准备内部数据上云,并且内部数据库每天的数据量很大,需要采用大数据存储的方案。 方案调研每个程序技术在实现之前,需要进行开源产品的调研,适合自己产品的技术方案才是最好的。 需求我们需要处理是图像信息,大小在1M左右。 供以后各个项目组用来拉取图像。 自定义了一个按照标准存储的一批图像,这批图像大小可能在几百兆或者小到几兆大小 技术选型我们选取了两种技术方案 采用hdfs的集群存储的方案,将数据进行流读取,存储二进制文;将相关的文件内容进行整合成一个大文件存储到hdfs上。 另外一个技术方案采用的是minio,分布式存储方案。 今天要给大家介绍的是minio技术方案。 Minio什么是Miniominio 是一款开源的对象存储服务。可以兼容亚马逊的S3存储服务接口,非常适合存储大容量的非结构化数据。 这些非结构化数据包含 图片,视频,日志文件,备份数据和容器、虚拟机镜像。 对象文件大小可以从几kb到最大5T. 我们可以用来做什么企业上我们可以利用其分布式的功能,内部搭建图片处理服务器,文件存储服务器,公司内部的文件存储服务器,这样就不用限制存储的大小,也不限制存储位置。 我们个人可以直接在家庭内部搭建个人的云盘服务,开心的保存家里面的数据文件,再也不担心数据丢失的问题了。 怎么安装Minio 分布式对象存储,在官网提供了很多的技术选择方案。 根据图中有5种不同的方案,让我们进行选择,可以使用docker 单机部署,也可以采用Docker-compose进行部署伪分布式。 可以使用Docker Swarm 和 k8s 部署分布式架构的选型。 因为是测试阶段,所以采用的是伪分布式的构建方式。使用docker-compose 方式进行部署。 部署docker-compose 部署方案,我们需要进行安装docker 与docker-compose ,这个在docker文档中都有,可以参考docker-compose官网。为了方便小伙伴进行学习,简单流程安装给大小说下。 安装docker centos yum install docker ubuntu apt-get install docker.io 安装docker-compose sudo curl -L"https://github.com/docker/compose/releases/download/1.23.1/ocker-compose-$(uname -s)-$(uname -m)"-o /usr/local/bin/docker-compose 执行下权限操作 sudo chmod +x /usr/local/bin/docker-compose 检验下版本是否是正确的 docker-compose --version docker-compose version 1.23.1, build 1719ceb 以上步骤操作成功后,我们就可以安装minio 来进行实战演练了。 下载docker-compose.yaml文件 version: '2' # starts 4 docker containers running minio server instances. Each # minio server's web interface will be accessible on the host at port # 9001 through 9004. services: minio1: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - data1:/data ports: - "9001:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http://minio1/data http://minio2/datahttp://minio3/data http://minio4/data minio2: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - data2:/data ports: - "9002:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http://minio1/data http://minio2/data http://minio3/data http://minio4/data minio3: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - data3:/data ports: - "9003:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http://minio1/data http://minio2/data http://minio3/datahttp://minio4/data minio4: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - data4:/data ports: - "9004:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http: //minio1/data http://minio2/data http://minio3/data http://minio4/data ## By default this config uses default local driver, ## For custom volumes replace with volume driver configuration. volumes: data1: data2: data3: data4: 在上面我们需要注意两点。 volumes 全局:如果我们不进行配置的话,使用的是默认的路径文件。 在这里向找到相关的存储的文件内容我们可以使用docker inspect 镜像id 来查看。 不配置全局:我们每个镜像id配置一个路径那么我们需要改下文件配置文件 version: '2' # starts 4 docker containers running minio server instances. Each # minio server's web interface will be accessible on the host at port # 9001 through 9004. services: minio1: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - /media/data1:/data:z ports: - "9001:9000" environment: MINIO_ACCESS_KEY:minio MINIO_SECRET_KEY: minio123 command: server http://minio1/data http://minio2/data http://minio3/data http://minio4/data minio2: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - /meida/data2:/data:z ports:-"9002:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http: //minio1/data http://minio2/data http://minio3/data http://minio4/data minio3: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: -/media/data3:/data:z ports: - "9003:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http://minio1/data http://minio2/data http://minio3/datahttp://minio4/data minio4: image: minio/minio:RELEASE.2018-12-19T23-46-24Z volumes: - /media/data4:/data:z ports: -"9004:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 command: server http://minio1/data http://minio2/datahttp://minio3/data http://minio4/data 在这个文件中,我们主要做了两项修改: /media/data1:/data ,我们将data里面的数据映射到media/data1本地目录下。 在:/data 后面增加:z ,这个是为了解决权限问题所增加的。 权限问题是这样的,在我们后面加上: z 就是我们就可以启动成功了 ERROR Unable to initialize posix backend: Unable to write to the backend. minio3_1_2ce510efd213 | > Please ensure Minio binary has write permissions for the backend 启动 首先拉取镜像 docker-compose pull 镜像启动 docker-compose up 如果没有出现错误,那么我们程序就启动成功了 浏览器查看 ip:9001 访问,第一次登陆我们需要填写 ACCESS_KEY 与 SECRET_KEY 。这个两个内容的值在我们配置文件中已存在,直接查看配置文件内容然后填写 浏览器页面展示:出现以上界面就代表我们安装成功了 使用 进入界面后我们需要先点击右下角的加号,然后创建文件目录,我们的图像是存储在文件目录下的。结束 这样我们的一个分布式系统就搭建完成了,怎么样是不是很简单?嘿嘿。 总结分布式文件系统存储,是我们搭建开始的第一步,后面性能问题,存储压力都是我们需要面临的。做好准备工作才能更好的服务我们的产品。 原文发布时间为:2018-12-20本文作者: 琪琪 本文来自云栖社区合作伙伴“ LuckQI”,了解相关信息可以关注“LuckQI”微信公众号

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册