MongoDB 安全门事件 此前，MongoDB 也多次出现安全问题。无需身份验证的开放式 MongoDB 数据库曾遭到多个黑客组织的攻击，被攻破的数据库内容会被加密，受害者必须支付赎金才能找回自己的数据。 2016 年 12 月底,MongoDB 遭黑客攻击，事情在 2017 年 1 月达到顶峰。攻击者利用配置存在纰漏的 MongoDB 展开勒索行为，自称 Harak1r1 的黑客组织将网络上公开的 MongoDB 资料库中的资料汇出，并将 MongoDB 服务器上的资料移除。起初两百个 MongoDB 数据库实例的数据被非法清除，几天之内，受感染的 MongoDB 数据库实例已经增长至一万多台。开始攻击者要求受害人支付 0.2 个比特币 (当时的价值约为…
来源：内容来自「华为、蓝血研究（lanxueyanjiu）」。 全面提升软件工程能力与实践，打造可信的高质量产品 ——致全体员工的一封信 我今天写信，是要和大家沟通公司如何全面提升软件工程能力和实践。二十年前的 IPD 变革，重构了我们的研发模式，实现了从依赖个人、偶然性推出成功产品，到制度化、持续地推出高质量产品的转变。至今为止，我们的产品和解决方案已经在 170 多个国家安全稳定运行，并因此积累和赢得了全球数万客户的信任。今天，我们又处在一个新的起点，全面云化、智能化、软件定义一切等发展趋势，对 ICT 基础设施产品的可信提出了前所未有的要求。可信将成为客户愿买、敢买和政府接受、信任华为的基本条件。可信不仅仅是产品外在表现的高质量结果，更是产品内在实现的高质量过程，是结果和过程的双重可验证的高质量。而只有全面提升软件工程能力和实践，才有可能打造出可信的高质量产品。 公司已经明确，把网络安全和隐私保护作为公司的最高纲领。我们要在每一个 ICT 基础设施产品和解决方案中，都融入信任、构建高质量，关键内容包括： 安全性（Security）。产品有良好的抗攻击能力，保护业务和数据的机密性、完整性和可用性。 韧性（Resilience）。系统受攻击时保持有定义的运行状态，包括降级，以及遭遇攻击时快速恢复的能力。 隐私性（Privacy）。遵从隐私保护既是法律法规的要求，也是价值观的体现。用户应该能够适当地控制他们的数据的使用方式。信息的使用政策应该是对用户透明的。用户应该根据自己的需要来控制何时接收以及是否接收信息。用户的隐私数据要有完善的保护能力和机制。 可靠性和可用性（Reliability &Availability）。产品能在生命周期内长期保障业务无故障运行，具备快速恢复和自我管理的能力，提供可预期的、一致的服务。 全面提升软件工程能力和实践，关乎公司未来的生存和发展，与我们每一个人都息息相关。在此，我希望全体员工、特别是软件工程师们主动参与进来，从自己做起，踏踏实实，共同打造可信的高质量产品。 我们要转变观念，追求打造可信的高质量产品，不仅仅是功能、特性的高质量，也包括产品开发到交付过程的高质量。 我们知道，功能、特性对产品至关重要，我们更知道，进度对满足客户需求也至关重要。今天，我们要把可信作为第一优先级，放在功能、特性和进度之上。除非客户信任我们的产品，否则这些优秀的特性都没有机会发挥价值。我们各级管理者和全体员工都不得以进度、功能、特性等为理由来降低可信的要求，确保可信的要求在执行过程中不变形。 我们要从最基础的编码质量做起，视高质量代码为尊严和个人声誉。 代码就像是高楼大厦的一砖一瓦，没有高质量的代码，可信的产品就是空中楼阁。我们要优化并遵循公司各种编程规范，遵从架构与设计原则，熟练使用各种编程库和 API，编写出简洁、规范、可读性强、健壮安全的代码。 我们要深刻理解架构的核心要素，基于可信导向来进行架构与设计。 在确保可信的前提下，要在性能、功能、扩展性等方面做好权衡；慎重地定义我们的模块与接口，真正做到高内聚与低耦合；我们要遵循权限和攻击面最小化等安全设计原则，科学设计模块之间的隔离与接口，提升安全性；低阶架构与设计要遵循高阶的架构与设计原则，在充分理解原有架构与设计的情况下，持续优化；我们要熟悉各种设计模式，重用公共成熟组件和服务，避免重复劳动。 我们要重构腐化的架构及不符合软件工程规范和质量要求的历史代码。 我们知道，再好的架构，其生命力也是有限的。随着时间的推移、环境的变化以及新技术、新功能特性的引入，架构也会腐化。面对腐化了的架构，要毫不犹豫地去重构它。同时主动以可信设计原则为导向，去重构不符合软件工程规范和质量要求的历史代码，提升软件架构的生命力。…
开发人员一直在努力提高 Docker 的使用率和性能，命令也在不停变化。Docker 命令经常被弃用，或被替换为更新且更有效的命令，本文总结了近年来资深专家最常用的命令列表并给出部分使用方法。 目前，Docker 共有 13 个管理命令和 41 个通用命令，以下是常用 Docker 命令列表： docker help—检查最新 Docker 可用命令； docker attach—将本地输入、输出、错误流附加到正在运行的容器； docker commit—从当前更改的容器状态创建新镜像； docker exec—在活动或正在运行的容器中运行命令； docker history—显示镜像历史记录； docker info—显示系统范围信息； docker inspect—查找有关 docker 容器和镜像的系统级信息； docker login—登录到本地注册表或 Docker Hub； docker pull—从本地注册表或 Docker Hub…
微服务架构中最核心的部分是服务治理，服务治理最基础的组件是注册中心。随着微服务架构的发展，出现了很多微服务架构的解决方案，其中包括我们熟知的 Dubbo 和 Spring Cloud。 关于注册中心的解决方案，dubbo 支持了 Zookeeper、Redis、Multicast 和 Simple，官方推荐 Zookeeper。Spring Cloud 支持了 Zookeeper、Consul 和 Eureka，官方推荐 Eureka。 两者之所以推荐不同的实现方式，原因在于组件的特点以及适用场景不同。简单来说： ZK 的设计原则是 CP，即强一致性和分区容错性。他保证数据的强一致性，但舍弃了可用性，如果出现网络问题可能会影响 ZK 的选举，导致 ZK 注册中心的不可用。 Eureka 的设计原则是 AP，即可用性和分区容错性。他保证了注册中心的可用性，但舍弃了数据一致性，各节点上的数据有可能是不一致的（会最终一致）。 Eureka 采用纯…
本文来源于微信公众号鲜枣课堂（ID：xzclasscom），作者： 小枣君，IT之家获授权转载。前情阅读：《涨知识！云计算到底是怎么玩的》 2010年，几个搞IT的年轻人，在美国旧金山成立了一家名叫“dotCloud”的公司。 这家公司主要提供基于PaaS的云计算技术服务。具体来说，是和LXC有关的容器技术。 LXC，就是Linux容器虚拟技术（Linux container） 后来，dotCloud公司将自己的容器技术进行了简化和标准化，并命名为——Docker。 Docker技术诞生之后，并没有引起行业的关注。而dotCloud公司，作为一家小型创业企业，在激烈的竞争之下，也步履维艰。 正当他们快要坚持不下去的时候，脑子里蹦出了“开源”的想法。 什么是“开源”？开源，就是开放源代码。也就是将原来内部保密的程序源代码开放给所有人，然后让大家一起参与进来，贡献代码和意见。 Open Source，开源 有的软件是一开始就开源的。也有的软件，是混不下去，创造者又不想放弃，所以选择开源。自己养不活，就吃“百家饭”嘛。 2013年3月，dotCloud公司的创始人之一，Docker之父，28岁的Solomon Hykes正式决定，将Docker项目开源。 Solomon Hykes（今年刚从Docker离职） 不开则已，一开惊人。 越来越多的IT工程师发现了Docker的优点，然后蜂拥而至，加入Docker开源社区。 Docker的人气迅速攀升，速度之快，令人瞠目结舌。 开源当月，Docker 0.1版本发布。此后的每一个月，Docker都会发布一个版本。到2014年6月9日，Docker 1.0版本正式发布。 此时的Docker，已经成为行业里人气最火爆的开源技术，没有之一。甚至像Google、微软、Amazon、VMware这样的巨头，都对它青睐有加，表示将全力支持。 Docker火了之后，dotCloud公司干脆把公司名字也改成了Docker Inc.。 Docker和容器技术为什么会这么火爆？说白了，就是因为它“轻”。 在容器技术之前，业界的网红是虚拟机。虚拟机技术的代表，是VMWare和OpenStack。 相信很多人都用过虚拟机。虚拟机，就是在你的操作系统里面，装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。 虚拟机，类似于“子电脑” 在“子电脑”里，你可以和正常电脑一样运行程序，例如开QQ。如果你愿意，你可以变出好几个“子电脑”，里面都开上QQ。“子电脑”和“子电脑”之间，是相互隔离的，互不影响。 虚拟机属于虚拟化技术。而Docker这样的容器技术，也是虚拟化技术，属于轻量级的虚拟化。…
Introduction Syncthing is a free, Open Source tool that can be used to sync files/folders between your networked computers. Unlike other sync tools, such as BitTorrent Sync or Dropbox, Syncthing transfers data directly from…
大家可以想象一个这样的场景，上班的时候听同事介绍了一个很好看的片子，找到资源后，直接通过远程迅雷下载，安心的工作，然后远程迅雷默默的将你的资源下载放到你家里的下载服务器上，回家后通过手机访问到你的下载服务器愉快的看片。是不是很方便呢？ 一、材料准备 1、一台linux的机器作为下载服务器。 我的机器是一台老掉牙的台式机CUP是赛扬1G，内存1G，硬盘120G，废物利用装了个64位版CentOS 7，既然是下载机肯定要装个samba服务，方便局域网内其他设备访问。 2、下载迅雷Xware 我下载的版本是 Xware1.0.31_x86_32_glibc 下载地址：http://g.xunlei.com/thread-12545-1-1.html 二、安装 1、建立xunlei的安装目录 mkdir /home/xunlei 2、将安装包Xware1.0.31_x86_32_glibc解压后上传到该目录 chmod 777 -R /home/xunlei 将该目录设置读写执行权限 3、挂载下载目录 mount --bind /home/myshare /mnt/xunlei 我挂载的是samba的共享目录，这样通过远程下载的资源就可以直接在手机或电脑上访问了。 4、启动远程迅雷 到安装目录下执行portal 就可以了。 我的目录为/home/xunlei/Xware1.0.31_x86_32_glibc/portal 执行完成后就会显示出激活码。…
过去我们项目组的应用都是用 supervisord 托管的。最近因为某些因素，无法使用 supervisord，因此考虑改用 systemd。 作为主流 Linux 发行版的默认选项，之前多多少少用过一点 systemd。不过这次需要上生产环境，所以抽空深入研究一番。 为什么要用 supervisord? 实现进程的分组管理，比如支持一同启动/停止多个生产者/消费者实例。 进程崩溃的时候可以重启 要想改用 systemd，需要看下 systemd 如何应对这两个问题。 （如无指明，在本文中，supervisord 的配置项在 [program:x] 下面，而 systemd 的配置项则位于 [Service]） 进程控制 无论 supervisord 还是 systemd，都采用 ini 作为配置文件的格式。跟 supervisord 不同的是，systemd…
Kafka Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 1.前言 消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 1.1 Kafka的特性: - 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 - 可扩展性：kafka集群支持热扩展 - 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 - 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） - 高并发：支持数千个客户端同时读写 1.2 Kafka的使用场景： - 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。 - 消息系统：解耦和生产者和消费者、缓存消息等。 - 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。 -…
简介 kafka是一个分布式消息队列。具有高性能、持久化、多副本备份、横向扩展能力。生产者往队列里写消息，消费者从队列里取消息进行业务逻辑。一般在架构设计中起到解耦、削峰、异步处理的作用。 kafka对外使用topic的概念，生产者往topic里写消息，消费者从读消息。为了做到水平扩展，一个topic实际是由多个partition组成的，遇到瓶颈时，可以通过增加partition的数量来进行横向扩容。单个parition内是保证消息有序。 每新写一条消息，kafka就是在对应的文件append写，所以性能非常高。 kafka的总体数据流是这样的： kafka data flow 大概用法就是，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉去指定Topic的消息，然后进行业务处理。 图中有两个topic，topic 0有两个partition，topic 1有一个partition，三副本备份。可以看到consumer gourp 1中的consumer 2没有分到partition处理，这是有可能出现的，下面会讲到。 关于broker、topics、partitions的一些元信息用zk来存，监控和路由啥的也都会用到zk。 生产 基本流程是这样的： kafka sdk product flow.png 创建一条记录，记录中一个要指定对应的topic和value，key和partition可选。 先序列化，然后按照topic和partition，放进对应的发送队列中。kafka produce都是批量请求，会积攒一批，然后一起发送，不是调send()就进行立刻进行网络发包。 如果partition没填，那么情况会是这样的： key有填 按照key进行哈希，相同key去一个partition。（如果扩展了partition的数量那么就不能保证了） key没填 round-robin来选partition…