今晚吃什么:咖喱鸡肉饭

用料:   鸡胸肉、土豆、胡萝卜、好侍百梦多咖喱、洋葱、番茄、生姜、生抽、黄酒、食用油、食盐   (按用餐人数准备食材分量。我们家4个人吃,用料见下图,实际操作时多加了一个土豆,胡萝卜去掉一半。供大家参考!)     做法(4人份): 1.鸡胸肉洗净切块放入碗中,加入生姜、黄酒、生抽、食盐腌渍40分钟,后入炒锅煸炒至变色,起锅待用。 2.土豆和胡萝卜洗净去皮后切块,洋葱和西红柿洗净后切碎。 3.炒锅倒入适量食用油,烧热,放入洋葱西红柿碎翻炒出香气,倒入5碗清水,大火烧开后转小火慢炖直至洋葱西红柿成糊状。 (成品图完全看不出有放西红柿和洋葱,好吃的重点就在这里!洋葱西红柿糊和咖喱融合后特别美味,它们起到提味的作用!) 4.糊中加入土豆、胡萝卜和煸炒好的鸡肉一起焖煮,煮一会试出土豆熟透后加入咖喱块,不断用锅铲搅拌,以免糊底。 (如果喜欢胡萝卜软烂一些,可以把它放到第三个步骤里去) 5.待汤汁变浓稠后尝一尝味道,根据个人口味选择是否再加盐。 6.完美出锅!

MariaDB Galera Cluster 部署

如何快速部署MariaDB集群 陈亮 — July 02, 2015   MariaDB作为Mysql的一个分支,在开源项目中已经广泛使用,例如大热的openstack,所以,为了保证服务的高可用性,同时提高系统的负载能力,集群部署是必不可少的。 MariaDB Galera Cluster 介绍 MariaDB集群是MariaDB同步多主机集群。它仅支持XtraDB/ InnoDB存储引擎(虽然有对MyISAM实验支持 – 看wsrep_replicate_myisam系统变量)。 主要功能: 同步复制 真正的multi-master,即所有节点可以同时读写数据库 自动的节点成员控制,失效节点自动被清除 新节点加入数据自动复制 真正的并行复制,行级 用户可以直接连接集群,使用感受上与MySQL完全一致 优势: 因为是多主,所以不存在Slavelag(延迟) 不存在丢失事务的情况 同时具有读和写的扩展能力 更小的客户端延迟 节点间数据是同步的,而Master/Slave模式是异步的,不同slave上的binlog可能是不同的 技术: Galera集群的复制功能基于Galeralibrary实现,为了让MySQL与Galera library通讯,特别针对MySQL开发了wsrep API。 Galera插件保证集群同步数据,保持数据的一致性,靠的就是可认证的复制,工作原理如下图: 当客户端发出一个commit的指令,在事务被提交之前,所有对数据库的更改都会被 write-set 收集起来,并且将 write-set 纪录的内容发送给其他节点。 write-set 将在每个节点进行认证测试,测试结果决定着节点是否应用write-set更改数据。 如果认证测试失败,节点将丢弃 write-set ;如果认证测试成功,则事务提交。 1 安装环境准备 安装MariaDB集群至少需要3台服务器(如果只有两台的话需要特殊配置,请参照官方文档) 在这里,我列出试验机器的配置: 操作系统版本:centos7 node4:10.128.20.16 node5:10.128.20.17 node6:10.128.20.18 以第一行为例,node4为 hostname ,10.128.20.16为 ip ,在三台机器修改 /etc/hosts 文件,我的文件如下: 10.128.20.16…

Read More

学会用各种姿势备份MySQL数据库

  前言 为什么需要备份数据? 数据的备份类型 MySQL备份数据的方式 备份需要考虑的问题 设计合适的备份策略 实战演练 使用cp进行备份 使用mysqldump+复制BINARY LOG备份 使用lvm2快照备份数据 使用Xtrabackup备份 总结 前言 我们试着想一想, 在生产环境中什么最重要?如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢?这可能是最恐怖的事情了吧, 我感觉在生产环境中应该没有什么比数据跟更为重要. 那么我们该如何保证数据不丢失、或者丢失后可以快速恢复呢?只要看完这篇, 大家应该就能对MySQL中实现数据备份和恢复能有一定的了解。 为什么需要备份数据? 其实在前言中也大概说明了为什么要备份数据, 但是我们还是应该具体了解一下为什么要备份数据 在生产环境中我们数据库可能会遭遇各种各样的不测从而导致数据丢失, 大概分为以下几种. 硬件故障 软件故障 自然灾害 黑客攻击 误操作 (占比最大) 所以, 为了在数据丢失之后能够恢复数据, 我们就需要定期的备份数据, 备份数据的策略要根据不同的应用场景进行定制, 大致有几个参考数值, 我们可以根据这些数值从而定制符合特定环境中的数据备份策略 能够容忍丢失多少数据 恢复数据需要多长时间 需要恢复哪一些数据 数据的备份类型 数据的备份类型根据其自身的特性主要分为以下几组 完全备份 部分备份 完全备份指的是备份整个数据集( 即整个数据库 )、部分备份指的是备份部分数据集(例如: 只备份一个表) 而部分备份又分为以下两种 增量备份 差异备份 增量备份指的是备份自上一次备份以来(增量或完全)以来变化的数据; 特点: 节约空间、还原麻烦 差异备份指的是备份自上一次完全备份以来变化的数据 特点: 浪费空间、还原比增量备份简单 示意图 MySQL备份数据的方式…

Read More

在Service Fabric上运行微服务

原文:Microservices à la Service Fabric 作者:Chase Aucoin 翻译:张鑫健;审校:孙薇 责编:钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,另有「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguang2008申请入群,备注姓名+公司+职位。 Service Fabric框架对微软而言是一大进步。其核心部分是一个分布式系统平台,用于构建可扩展的可靠应用。在便于封装可部署代码的同时,还内置了微服务最佳实践案例。 本文将带您最快地上手使用Service Fabric框架,并保证您会爱不释手。但想要了解Service Fabric框架以及它的重大意义,就有必要了解现代软件发展到今天,在采用Service Fabric框架前,前人们血与泪的历史。 面向对象的黄金时代 在引入面向对象和现代的计算模式之后,计算机界发生了翻天覆地的变化。Visual Basic在1991年面世,真正揭开了现代风格软件开发的序幕,使得开发人员可以专注于商业价值,而不用像之前那样顾虑一大堆硬件特性的问题。之后在这种开发思路下,出现了后来的运行库,比如1995年的Java,2000年的.NET framework和C#。尽管在之后几年中,Java和C#出现了些许变化,但采用的模式和实践方式却没有太大变化。 这些实践、模式以及运行库在进化过程中都有如下共性:内部构架变得原来越抽象,然而使用门槛却越来越低。终端开发者无需操心细枝末节、重复任务和管道问题,从而专注于传达产品的业务价值。 敏捷的诞生 在整个计算机行业的代码编译出现模式和实践范例的同时,我们却忽视了改进提炼围绕着产品开发与SDLC的商业进程。 当时大多数人认为SDLC相关的模式(瀑布、大爆炸/一次性集成、螺旋等)过于死板受限,无法适应开发者新的快速任务执行的能力。开发者在功能构建上的速度已经超过了商业进程的速度,他们将大多时间花在构建需求文档和不注重价值的产品上。 2001年在犹他州Snowbird举行的会议上,有一批先驱者提出了关于SDLC思考方式的指导思想,也就是后人所称的敏捷宣言(Agile Manifesto)。 agileSHERPA提出: “相比于强调提前规划和需求详尽,本指导思想的重点在于:如何进行持续规划、团队授权、彼此协作、紧急设计、早期测试和经常探究根本,最重要的是能在短期快速迭代中交付软件。” 但在实际应用中,各公司尤其是企业组织最初非常抵触这种思考方式与抽象化商业进程。 而其他人迫切渴望采用这种思想,却完全无法理解。 最终敏捷获得大家的共识。“网络泡沫”崩溃前,各家公司都在追求敏捷,最终演变成了公司之间的军备竞赛。市场上对于敏捷的需求激增,但资源不足使得人们更加关注产品的价值主张和快速迭代。 敏捷性思维的广泛影响一改业内产品产出缓慢(一到两年一个产品)的情况,通过流线化作业,现在可以按季度或者每半年发布一次版本了。实际可用的代码一般会在发布日期前交付使用,但在整个行业内,开发的速度与工程及商业进程的发展仍有断层。 DevOps 尽管在商业与开发进程中出现了前文说的种种进步,但软件的交付流程本质上仍是瀑布式的。一切按部就班,我们仍有季度或月度发布。让事情更为复杂的,则是开发自由与商业敏捷导致面向服务开发所占的比重增加。不同于之前的单一应用部署,现在我们还有很多需求各异的小型应用需要协调。 大部分协调需求都只是因为软件发布不够频繁:只要单体功能已经完成,并且符合质量和业务需求的审验,就应当能够交付使用。 在2008年,工程师、企业领导和运营专家开始推动DevOps,人们渴望一种在整个软件开发周期中工程师和运营者更为协调,同时重视重复工作自动化的环境。 点击这里可以查看视频:DevOps的历史。 风暴来袭 随着公司、工程师和运营者日臻磨合,过去5-10年间有大量代码快速出炉,质量也大幅提高,远胜之前的30年。 现在大部分代码开始老化。八年前我们所使用的编程模式可能也很优秀,但直到两年前商业模式都还不够好。或者开始时想要使用敏捷,却没能坚持最佳实践的开发标准。这方面有很多类似的情况,不过我们的底限是:所有资源无论是现代化的还是较早期的,都要能为企业提供商业价值,需要维护的内容也要满足这个要求。 许多公司开始花费大量精力进行资源协调,努力均匀分切。假设公司有2到5个敏捷开发团队负责一个产品的不同部分,或者干脆就是不同的产品,就会有各种问题:这些项目的着陆点在哪,硬件是哪个队伍的?在最初设计不适用水平扩展或容错性不佳的情况下,如何确保关键程序的高可用性?如果某台机器宕机怎么办?是要继续手头的工作,还是选择损失掉一些信誉,还可能带来负面的口碑? 让服务器不再娇贵,而要成为顶用的老黄牛 许多公司都对于基础架构的需求,都依赖内部独立的交付团队是否有意识,通常的表现就是:公司只针对特定的框架需求设置服务器,所用的部署实践也是多年来逐渐构建的。我们多用神灵、星球甚至飓风的命来给硬件命名,将它们看作脆弱、唯一的雪花般宝贵。然后,某个公司的阿波罗服务器宕机了。 全公司都乱套了,一时间公司内哀鸿遍野,大家都想拼命做些什么来解决问题。最疯狂的是:由于这台服务器太过关键,所有人都向它致以最深切的哀悼,整个公司都在经历“悲伤的七个阶段”。 之后他们启用全新的硬件,比之前的更加庞大快速。几个月之后,阿波罗服务器完全被遗忘了,就像没存在过一样。尽管大家都知道不久的将来还会有宙斯和阿瑞斯这样更先进的设备,但知道有这件事不代表已经做好了准备。 进入封装技术时代 讲到这里推荐大家去阅读一篇由Zach Gardner撰写的博文《Docker: VMs, Code Migration, and SOA Solved》,介绍了封装技术在Docker中应用的一些注意事项,值得一读。 坦率地说,我本人是个微软粉,但微软在封装技术领域有些落后于其它公司。在Docker发布了近三年之后,微软才跟上趟。不仅如此,在微服务的问题上 .NET社群在工具和创新方式无法与Java社群中的Netflix和Amazon公司的成果比肩。 但我仍然喜欢微软:尽管他们在这点上落后于他人,但他们发行的产品更容易上手,而且售后与支持服务更好,Service Fabric也不例外。 Service Fabric框架不仅能让开发者封装可部署代码,另外还内置了微服务的最佳实践案例。想要查看更多信息,请移步《Discussion…

Read More

超长干货:基于Docker的DevOps CI/CD实践——来自iHealth的分享

本文由1月31日晚iHealth运维技术负责人郭拓在Rancher官方技术交流群内所做分享的内容整理而成,分享了iHealth从最初的服务器端直接部署,到现在实现全自动CI/CD的实践经验。文末添加Rancher小助手为好友加入技术交流群,可实时参加下一次技术分享~ 前言 相信我,一切事情的发生都是赶鸭子上架,没有例外。人类所有伟大的变革都是迫不得已,可又是那么顺其自然。比如容器(docker)技术的诞生,比如箭在弦上的创业,比如野心勃勃的kubernetes,比如如今已作为左膀右臂的rancher,比如这篇文章。 不同于郑兄的CI/CD实践《如何利用Docker构建基于DevOps的全自动CI》,我们结合自身状况,构建了一套我们自己的DevOps CI/CD流程,更轻更小,更适合Startup。 合适的才是最好的(Node.js & Docker) 如果世界只有FLAG、BAT,那就太无趣了。iHealth是一家初创型公司,我所在的部门有大概10名研发人员,在担负着三端研发工作的同时,所有围绕服务的交付和运维工作也都是我们来做。 技术的选型上,服务端、Web端和移动端(Android、iOS)都要上,但人少。所以招人的时候并没有以貌取人的资格,部门对外的Title都是全栈。能一门语言通吃三端,群众基础广泛,恐怕没有比Javascript/Typescript(Node.js)更合适的了。 服务端有Express、Koa、Feather、Nest、Meteor等各有其长的框架,前端大而火的Reactjs、Vuejs和Angular,不管是Server Render还是前后端分离,都可以得心应手。因为公司的健康设备(血糖仪、血压计、体温计、血氧、体脂秤等等)会有专门的部门研发设计以及提供SDK,所以移动端的研发工作更多是在设计实现和性能优化上,React Native是一枚大杀器。虽然现在公司并没有桌面端的需求,但不能否认的是Electron是一个很有趣的项目,也为“全栈”这个词增加了更多背书。     另外,选择使用Node/Js/Ts作为全栈的基础会附带有RPC的好处。无需集成传统意义上的RPC框架(如gRPC),只需在编写远程(微)服务方法时,编写相应的npm package,也可以达到相同的目的,且成本更小,更易理解。 运维环境的选型上,所有的业务都运行在云端,省去了机房维护和服务器运维的成本。其实在盘古开荒时,我们也是编写了Node程序后,使用PM2部署在服务器上,并没有使用Docker。当然也存在没有使用Docker所带来的一切问题:三端不同步、环境无法隔离……而Docker带给我最大的惊喜除了超强的可移植性,更在于研发人员可以非常容易对程序的顶级架构进行推理。 事实上,我们直接使用docker-compose做容器编排着实有一段时间,在一次大规模的服务器迁移中,发现需要重新思考越来越多的container管理和更完善的编排方案。Rancher(Cattle)就是在这时被应用到技术栈中。 一切从Github开始 在运维环境一波三折的同时,DevOps的征程也是亦步亦趋,步步惊心。幸运的是,我们知道自己缺乏什么,想要什么,所以能比较容易的做到“哪里不会点哪里”。如同上一章节所述,合适的才是最好的。持续集成(CI)与持续交付(CD)的迭代过程,从最初的代码拷贝,到结合docker-compose与rsync命令,到使用CI/CD工具,做到相对意义上的自动化……迄今为止,我们摸索出一套相对好用并且好玩的流程:     故事大致是这样的,当一只代码猴提交代码之后,他需要去接一杯咖啡。在猫屎氤氲的雾气里45°角仰望天花板,手机微信提醒这次构建成功(或失败,并附带污言秽语)。这时他可以开始往工位走,坐下时,微信又会提醒本次部署到Rancher成功(或失败)。 这一切开始的地方是github。当开发者写完 BUG 功能之后,需要有地方保存这些宝贵的资料。之所以没有使用Gitlab或Bitbucket搭建私有的Git服务器,是因为我们认为代码是最直接的价值体现。服务如骨架,终端如皮肤,UE如衣服,三者组成让人赏心悦目的风景,代码是这背后的基础。我们认为在团队精力无法更分散、人口规模尚小时,购买Github的商业版是稳妥且必要的,毕竟那帮人修复一次故障就像把网线拔下来再插上那样简单。 Drone CI Drone这个单词在翻译中译作雄蜂、无人机。我特意咨询了一位精通一千零二十四国语言的英国朋友,说这个词的意思是autonomous,works by itself。白话就是有活它自己干,而且是自主的。不过这个解释对于Drone来说名副其实。这个在Github上拥有13,000+ Stars的开源项目,使用Golang编写,相比Jenkins的大而全,Drone是为Docker而生的CI软件。如果有使用过Gitlab CI的小伙伴,相信对Drone的使用方式不会感到陌生,他们都是使用Yaml风格文件来定义pipeline: build: image: node:latest commands: – npm install – npm run lint – npm run test publish: image: plugins/npm when: branch: master Drone的安装方式如同Rancher一样简单,一行docker命令即可。当然,大家也可以看Drone的官方文档,在这里,只讲一下使用Rancher catalog安装Drone的方式:     查看大图大家可以看到Drone使用Rancher…

Read More

Mitigating DDoS Attacks with NGINX and NGINX Plus

A Distributed Denial‑of‑Service (DDoS) attack is an attempt to make a service, usually a website, unavailable by bombarding it with so much traffic from multiple machines that the server providing the service is no longer able to function correctly because of resource exhaustion. Typically, the attacker tries to saturate a system with so many connections and requests that it is no longer…

Read More

nginx-status开启及参数说明

方法一: 本模块在编译的时候默认是不编译的,如果你是从源码编译安装的nginx,那么需要在编译的时候加上对应的模块 ./configure –with-http_stub_status_module 使用 ./configure –help 能看到更多的模块支持。然后编译安装即可。 如果是直接 apt-get install 安装的 nginx,那么使用命令来查看是否支持 stub_status 这个模块。如下命令: www.it165.net nginx -V 看看是否有 –with-http_stub_status_module 这个模块。 ok,上面的事情告一段落,接下来需要在nginx的配置文件中增加这个配置项。打开nginx的配置文件 nginx.conf,在server段里面增加如下的内容: location /nginx-status { allow 127.0.0.1; //允许的IP deny all; stub_status on; access_log off; } 重启nginx,在浏览器中输入 http://localhost/nginx-status 就会出现相应的结果了。如下: Active connections: 1 server accepts handled requests 2         2      6 Reading: 0 Writing: 1 Waiting: 0 Active connections:对后端发起的活动连接数。 Server accepts handled…

Read More

微服务架构技术栈选型手册(万字长文)

作者|杨波 编辑|郭蕾 一、前言 2014 年可以认为是微服务 1.0 的元年,当年有几个标志性事件,一是 Martin Fowler 在其博客上发表了”Microservices”一文,正式提出微服务架构风格;二是 Netflix 微服务架构经过多年大规模生产验证,最终抽象落地形成一整套开源的微服务基础组件,统称 NetflixOSS,Netflix 的成功经验开始被业界认可并推崇;三是 Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系,推出 Spring Cloud 微服务开发技术栈。 一晃三年过去,微服务技术生态又发生了巨大变化,容器,PaaS,Cloud Native,gRPC,ServiceMesh,Serverless 等新技术新理念你方唱罢我登场,不知不觉我们又来到了微服务 2.0 时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累,我想总结并提出一些构建微服务 2.0 技术栈的选型思路,供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块,我也会给出一些定制自研的设计思路。 二、选型准则 对于技术选型,我个人有很多标准,其中下面三项是最重要的: 1.    生产级 我们选择的技术栈是要解决实际业务问题和上生产抗流量的(选择不慎可能造成生产级事故),而不是简单做个 POC 或者 Demo 展示,所以生产级(Production Ready),可运维(Ops Ready),可治理,成熟稳定的技术才是我们的首选; 2.    一线互联网公司落地产品 我们会尽量采用在一线互联网公司落地并且开源的,且在社区内形成良好口碑的产品,它们已经在这些公司经过流量冲击,坑已经基本被填平,且被社区接受形成一个良好的社区生态(本文附录部分会给出所有推荐使用或参考的开源项目的 GitHub 链接)。 3.    开源社区活跃度 GitHub 上的 stars 的数量是一个重要指标,同时会参考其代码和文档更新频率(尤其是近年),这些指标直接反应开源产品的社区活跃度或者说生命力。 另外,对于不同业务体量和团队规模的公司,技术选型标准往往是不同的,创业公司的技术选型和 BAT 级别公司的技术选型标准可能完全不同。本文主要针对日流量千万以上,研发团队规模不少于 50…

Read More

Linux脚本之>/dev/null 2>&1,以及2>1 VS 2>&1

1. 标准输入stdin文件描述符为0,标准输出stdout文件描述符为1,标准错误stderr文件描述符为2 2. /dev/null 空设备,相当于垃圾桶 3. 重定向符号:> 3. 2>1 与 2>&1 的区别 2>1, 把标准错误stderr重定向到文件1中 2>&1,把标准错误stderr重定向到标准输出stdout 4. 举例: 假设有脚本test.sh,内容如下,t是一个不存在的命令,执行脚本进行下面测试。 # cat test.sh t date 标准输出重定向到log,错误信息输出到终端上,如下: # ./test.sh > log ./test.sh: line 1: t: command not found # cat log Thu Oct 23 22:53:02 CST 2008 删除log文件,重新执行,这次是把标准输出定向到log,错误信息定向到文件1 # ./test.sh > log 2>1 # # cat log Thu Oct 23 22:56:20 CST 2008…

Read More

使用fluentd实现实时收集日志文件

目前线上服务使用了k8s进行部署,一个服务配置了多个副本,然后日志是挂载到宿主机器的目录的,所以当服务部署到三台机器时,这时要查看业务日志,就必须依次登录三台服务器来看日志。显然,这非常地不方便。团队想把日志收集到一个地方统一查看。于是开始尝试各种方案。 尝试 1. elasticsearch + fluentd + in_tail(input) + fluent-plugin-elasticsearch(output) + kibana 刚开始就测试使用网络上推荐的日志收集方案,elasticsearch + fluentd + kibana,部署完成后,经过使用,并不能很方便地对日志进行检索,因为日志格式非常多,不方便对日志进行格式化,所以收集过来的日志并不是结构化的。另一个原因是elasticsearch占用的CPU很高,这个不知道什么原因,可能给的资源不够或配置不当。不过更主要是团队成员希望最好是直接把日志收集到一台服务器,然后能够使用linux的工具,如grep,awk,less来查询日志,所以最终放弃此方案。 2. rsyslog + fluentd + in_tail(input) + fluent-plugin-remote_syslog(output) 然后开始尝试使用fluentd来收集日志并发送到rsyslog, rsyslog使用fluentd发送过来的tag来命令文件名,但由于syslog协议的限制,tag最大为32个字符,最终无奈放弃此方案。 3. fluentd-agent(input: in_tail, output: forward) fluentd-server(input: forward, ouput: fluent-plugin-forest) 最后采用agent和server端都使用fluentd,agent端的input使用in_tail,ouput使用forward,server端的input使用forward,ouput使用fluent-plugin-forest,找到fluent-plugin-forest这个插件不容易,因为它支持以tag命名文件名,并非常稳定,其它的插件由于不怎么更新了,bug挺多无法使用。 部署 server端 docker run -d -p 24224:24224 -p 24224:24224/udp -v /var/log/worker:/var/log/worker -v /etc/localtime:/etc/localtime –name fluent-server registry.cn-hangzhou.aliyuncs.com/shengjing/fluent-server agent端 在每个agent新建一个/home/fluent目录,并设置权限为777 mkdir -p /home/fluent chmod 777…

Read More