Monthly Archives: February 2018

原文：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提出： “相比于强调提前规划和需求详尽，本指导思想的重点在于：如何进行持续规划、团队授权、彼此协作、紧急设计、早期测试和经常探究根本，最重要的是能在短期快速迭代中交付软件。” 但在实际应用中，各公司尤其是企业组织最初非常抵触这种思考方式与抽象化商业进程。 而其他人迫切渴望采用这种思想，却完全无法理解。…

本文由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…

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…

方法一： 本模块在编译的时候默认是不编译的，如果你是从源码编译安装的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…

作者｜杨波 编辑｜郭蕾一、前言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. 标准输入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…

目前线上服务使用了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,…

最近为了做一些数据分析，把我自己服务器上所有应用的日志都通过 fluentd 转存到 mongodb 了，第一次用 fluentd，记录一些笔记。 因为是初学，绝大部分内容来源于官方文档2，等实际线上使用一段时间后再来更新一些心得。 一、Install fluent 比较烦的一点是，从 gem 安装和从 rpm、yum 安装的名字不一样，连配置文件的路径都不一样，需要记住的是： 从 gem 安装的，配置文件和执行程序都叫做 fluent； 从 rpm 安装的，配置文件和执行程序都叫做 td-agent。 1、安装 fluentd 详细可参见官方文档。 以 CentOS 为例： # 安装…

Note: This is an RHCSA 7 exam objective and an RHCE 7 exam objective. Presentation NTP (Network Time Protocol) is a protocol to keep servers time synchronized: one or several master servers provide time to client…

更新时间：2018-01-24 13:13:08     阿里云日志服务是针对日志类数据的一站式服务，用户只需要将精力集中在分析上，过程中数据采集、对接各种存储计算、数据索引和查询等琐碎工作等都可以交给日志服务完成。2017年9月日志服务升级日志实时分析功能（LogSearch/Analytics），可以使用查询+SQL92语法对日志进行实时分析。 在结果分析可视化上，除了使用自带Dashboard外，还支持DataV、Grafana、Tableua、QuickBI等对接方式。本文主要通过Grafana示例演示如何通过日志服务对Nginx日志进行分析与可视化。 在线成果演示请查看线上Demo。配置视频： 流程架构 日志从收集到分析的流程架构如下。 配置流程 日志数据采集。详细步骤请参考5分钟快速入门。 索引设置与控制台查询配置。详细步骤请参考索引设置与可视化或最佳实践网站日志分析案例。 安装Grafana插件，将实时查询SQL转化为视图。 本文档演示步骤3。 在做完1、2步骤后，在查询页面可以看到原始日志。 配置步骤 安装Grafana Grafana的详细安装步骤请参见Grafana官方文档。 以Ubuntu为例，安装命令为： wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.5.2_amd64.deb sudo apt-get install -y adduser libfontconfig sudo dpkg -i grafana_4.5.2_amd64.deb…