Linuxeden Open Source Community: 九月 2017

2017年9月30日星期六

开源美图 2017 10 01

Linuxeden 开源社区 --

The post 开源美图 2017 10 01 appeared first on Linuxeden开源社区.

http://ift.tt/2yzXtCw

LinkedIn 计划开源不增加开销的 MySQL 查询分析工具 Query Analyzer

Linuxeden 开源社区 --

LinkedIn 有超过 500 个内部应用程序基于 MySQL。为了便于管理，提高利用率，他们构建了 MySQL 即服务模型。该模型有个缺点，一个应用程序的查询可能会影响其他应用程序的查询。为了控制查询，他们希望收集数据库中运行的查询的完整信息，以便分析优化。近日，LinkedIn 工程师 Karthik Appigatla撰文介绍了他们在这方面所做的工作。

MySQL Performance Schema 是摆在他们面前的一个选项。MySQL 从 5.5.3 版本开始提供这个特性，它可以从底层监控 MySQL 服务器的运行。这种方法的缺点是，启用或禁用 performance_schema 需要重启。而且，启用该模式会增加大约 8%到 25%的开销。另外，分析 Performance Schema 的结果也异常复杂。

还有一个选项是借助查询日志。他们可以预先设定一个阈值，并把所有超过阈值的查询记录在一个文件里用于后续分析。这种方法的缺点是无法捕获所有查询。虽然将阈值设为 0 可以捕获所有查询，但那会导致非常高的 I/O，严重降低系统吞吐量，所以，他们一开始就没有考虑使用这种方式。

为了保证开销最小同时又能有效地度量所有查询，他们构建了 Query Analyzer。该工具包含三个组件，如下图所示：

代理 ——运行在数据库服务器上。
中央服务器 ——存储查询信息；
UI——位于中央服务器之上，用于展示 SQL 分析结果。

Query Analyzer 的高层架构

其中，代理使用原始套接字捕获 TCP 数据包并解码，然后使用 MySQL Protocol 从数据包流构建出查询。它会计算查询的响应时间，并将查询发送给一个 Go 例程（他们使用了 Percona GO 程序包），由后者识别出查询指纹。代理会以这个指纹为基础计算生成一个哈希值，作为查询的 KEY。代理会把查询的哈希值、总响应时间、次数、用户、数据库名称等信息存储在哈希表中。如果服务器执行了哈希值相同的查询，那么次数及总响应时间会增加。此外，代理还会存储查询的元数据，包括查询的哈希值、指纹、第一次执行时间、最大时间、最小时间等。代理会定期将收集到的信息发送给中央服务器，并重置计数器。元数据信息只有在发生变化时才会发送。该代理只需要几个 MB 的内存来管理这些数据结构，而其发送信息所占用的带宽则可以忽略不计。

UI 会显示所有不同的查询，如下图所示：

其中有个有趣的指标是查询负载占比，查询负载的计算方法为：

而查询负载占比的计算方法为：

查询负载占比高的查询是需要特别关注的，即使该查询的单次执行时间并不长。点击任意查询，可以查看该查询的趋势图及其他更多信息，如下图所示：

LinkedIn 使用 sysbench 在 MySQL 5.6.29-76.2-log Percona Server (GPL) 上做了基准测试。当并发线程小于 128 时，Query Analyzer 基本不会影响吞吐量。当并发线程数到达 256 时，每秒事务数减少了 5%，这仍然好于 Performance Schema 的 10%。在整个测试过程中，Query Analyzer 占用的 CPU 不足 1%，当并发线程数超过 128 时，其占用的 CPU 也仅为 5%。

Query Analyzer 可以带来许多好处。数据库工程师可以快速定位有问题的查询，高效地分析解决数据库速度变慢的问题。开发人员和业务分析师可以查看查询趋势，检查查询负载。在安全方面，Query Analyzer 可以在数据库收到新的查询请求时发出警告。

最后，虽然时间还没有确定，但 LinkedIn 的最终目标是将 Query Analyzer 开源。

转自 http://ift.tt/2yOOdLJ

The post LinkedIn 计划开源不增加开销的 MySQL 查询分析工具 Query Analyzer appeared first on Linuxeden开源社区.

http://ift.tt/2ygzagM

KNOPPIX 8.1 发布，GNU/Linux 系统

Linuxeden 开源社区 --

KNOPPIX 8.1 发布了，KNOPPIX 是一套光盘启动的 GNU/Linux 系统 (LiveCD)，功能包括：自动硬件监测、支持常见的显卡、声卡、SCSI 和 USB 设备，以及其它外设。KNOPPIX 可用于 Linux 演示、光盘教学、系统急救，经过适当改造，还可以用于商业软件的产品演示。KNOPPIX 采用了特殊的解压缩技术，不需要硬盘安装，一张 CD，就容纳了 2GB 的可执行程序，供用户自由使用。

8.1 版本使用 Linux Kernel 4.12.7 和 X.Org 7.7 支持去当前计算机硬件。主页更新内容包括：

BFQ（Budget Fair Queue）调度程序，现已包含在多路径调度程序中的标准内核中，为慢磁盘，内核和系统软件（Debian Stretch + Buster）自动激活;
LibreOffice 5.4.1，GIMP 2.8.20;
Chromium 60.0.3112.78
和 Firefox 55 网络浏览器，带有 Ublock Origin 和 NoScript 安全插件;
……

更多内容请查看发布说明。

下载地址：

KNOPPIX_V8.1-2017-09-05-EN.iso (4,342MB, SHA256, signature, torrent, pkglist)
KNOPPIX_V8.1-2017-09-05-DE.iso (4,342MB, SHA256, signature, torrent)

转自 http://ift.tt/2yPx0BJ

The post KNOPPIX 8.1 发布，GNU/Linux 系统 appeared first on Linuxeden开源社区.

http://ift.tt/2yfujML

Sabayon Linux 17.10 发布

Linuxeden 开源社区 --

Sabayon Linux 17.10 发布了。

Sabayon 是一份自启动运行 DVD，它被设计为能在 5 分钟以内使一台电脑进入强大的 Gentoo Linux 系统。Gentoo Linux 是一份 Linux 发行，它由软件安装管理引擎 Portage 来驱动。除了作为自启动运行 DVD 使用，Sabayon Linux 也能安装到硬盘上，实际上相当于一张易于使用的 Gentoo 安装盘。该自启动运行 DVD 包含了大量的桌面环境及开源应用软件，例如 KDE、 GNOME、Xfce、Fluxbox、LibreOffice、FreeNX、Amarok、Kaffeine 等等。

最新改进动态请点击这里关注。

下载地址：17.10

转自 http://ift.tt/2g0NzTi

The post Sabayon Linux 17.10 发布 appeared first on Linuxeden开源社区.

http://ift.tt/2xHy1y6

MongooseJS 4.11.14 发布，MongoDB 连接包

Linuxeden 开源社区 --

MongooseJS 4.11.14 已发布，MongooseJS 是使用 JavaScript 编程，连接 MongoDB 数据库的软件包，使 MongoDB 的文档数据模型变的优雅起来，方便对 MongoDB 文档型数据库的连接和增删改查等常规数据操作。

更新内容：

chore: add nsp check to the CI build #5679 hairyhenderson
fix: bump mquery because of security issue with debug package #5677 #5675 jonathanprl
fix(populate): automatically select() populated()-ed fields #5669
fix(connection): make force close work as expected #5664
fix(document): treat $elemMatch as inclusive projection #5661
docs(model/query): clarify which functions fire which middleware #5654
fix(model): make init() public and return a promise that resolves when indexes are done building #5563

Sequelize v4.13.0 发布，Node.js 的 ORM

Linuxeden 开源社区 --

Sequelize v4.13.0 已发布，Sequelize.js 提供对 MySQL，MariaDB，SQLite 和 PostgreSQL 数据库的简单访问，通过映射数据库条目到对象，或者对象到数据库条目。简而言之，就是 ORM（Object-Relational-Mapper）。Sequelize.js 完全是使用 JavaScript 编写，适用于 Node.js 的环境。

更新内容：

mysql/errors: foreign key errors with more useful information (#8379) (6b11669)

下载地址：

转自 http://ift.tt/2fzRF4e

The post Sequelize v4.13.0 发布，Node.js 的 ORM appeared first on Linuxeden开源社区.

http://ift.tt/2xOK2RF

一周文章精选 2017 09 30

Linuxeden 开源社区 --

最强免费虚拟机：VirtualBox 5.1.28 下载

可能是国内最火的开源项目 —— C/C++ 篇

Firefox 57 更名为 Firefox Quantum，速度是 Firefox 52 两倍

AI 系统首次实现真正自主编程，完爆初级程序员

PHP 成弃子，Facebook 引擎转用 Hack 语言

盘点各种程序员常用的框架，有你用的吗？

RMS 谈 Windows Subsystem for Linux

The post 一周文章精选 2017 09 30 appeared first on Linuxeden开源社区.

http://ift.tt/2hBT3I2

Linux LTS 内核将提供六年的支持时间

Linuxeden 开源社区 -- Linux

Linux 长期支持版内核（LTS）提供了两年的安全更新，然而前不久发布的 Android 8.0 使用的仍然是 2014 年发布的 3.18 内核，Android 系统和设备作为主要的 LTS 内核使用者，现有的支持时间显然太短，今天有大量 Android 设备仍然运行着已经停止更新的内核。为了帮助 Android，Linux LTS 的支持时间将延长到六年。扩展支持将从最新的 LTS 内核 Linux 4.4 开始，下一个 LTS 版本 Linux 4.14 将一直支持到 2023 年，六年的支持时间应该足以覆盖 Android 设备的生命周期了。

转自 http://ift.tt/2x3xRwE

The post Linux LTS 内核将提供六年的支持时间 appeared first on Linuxeden开源社区.

http://ift.tt/2x4OwzF

初创企业开源许可证管理九大法则

Linuxeden 开源社区 --

原文出处： Heather Meeker 译文出处：Linux 中国/薛亮

开源软件虽然可以免费使用，但就如同饲养一条幼犬一样（开始虽然花钱不多，后边越养越费钱）。在采用开源之前，确保能够了解其隐藏的成本和陷阱。

对于初创公司来说，开源软件是一把双刃剑。它可以成为一家创业公司的生命线，因为开源软件可以帮助初创企业快速创新，而不必从头开始。不过，正如有些人所说的，开源软件虽然可以免费使用，但就如同饲养一条幼犬一样，开始虽然花钱不多，后边越养越费钱。开源软件的真正代价是开源许可证合规成本。

滥用开源软件可能会造成获得投资的机遇被延迟或破坏。但是，如果遵守这些简单的法则，初创企业可以轻松地实现开源许可证合规。

法则一：不使用没有许可条款的软件

互联网上的一些软件不包含许可证通知，但这不意味它们可以自由使用。发布软件的人可能没有遵守上游许可条款。或者软件的作者可能尚未为其软件指定许可协议——无论是以开源方式亦或是其他方式。“没有许可条款”是指没有许可证：您应该避免使用该软件或要求作者为其该软件指定许可证。

法则二：不要违反开源许可证

开源软件的使用可能难以让其作者进行追踪，但并不意味着该软件的使用和不合规行为会被忽视。违反开源许可证可能会使初创公司面临法律责任和公众谴责，甚至可能会影响其被投资或收购。也可能导致潜在客户由于担心下游责任而拒绝购买您的产品。软件开发人员为实现其软件开源付出了巨大的努力，其中也包括上述的许可费用。滥用开源软件对这些开发人员是不公平的，并且损害了他们希望促成的创新。

法则三：跟踪您正在使用的软件

将来有一天您将必须提供您正在使用的开源软件的列表。及时维护该列表将会为您节约大量的时间和精力，因为潜在的投资者和收购方将会要求您提供该列表。大多数开源软件下载包中都包括一个 “license.txt” 或 “copy.txt” 文件。保留该许可证的副本，并记录其涵盖的软件。大多数创业公司都使用简单的电子表格跟踪软件许可情况。

法则四：了解宽松（permissive）许可证和左版（copyleft）许可证

开源许可证大致分为两种类型：宽松许可证（BSD、MIT 和 Apache）和左版许可证（GPL、LGPL、Eclipse 公共许可证、Mozilla 公共许可证以及通用开发和分发许可证（Common Development and Distribution License））。大多数公司及其客户对于使用遵循宽松许可证的软件没有什么法律上的担心。不过，遵循左版许可证需要更加谨慎，将软件保留为专有可能会与某些特定计划不一致。

法则五：遵守许可证通知（notice）要求

无论是宽松许可证还是左版许可证，所有开源许可都有通知要求。通常，这意味着在分发开源软件时，您需要包含其所适用的许可证的副本，仅仅包括许可证的链接或缩略形式通常是不完备的。为了避免混淆或疏离您的客户，开发一个符合大多数开源许可证的通知传送策略非常重要。

法则六：了解哪些开源许可证与分布式软件兼容

除了 Affero GPL 之外，大多数开源许可证都没有涉及软件即服务（SaaS）的情境。对于 SaaS 和云系统的分布式组件（如 JavaScript）或分布式软件（包括移动 APP 和测试版），您可以使用遵循宽松许可证的软件，但在使用遵循左版许可证的软件之前，您需要特别小心。仅在其完全在自己的进程中执行并且没有链接的代码时才去使用遵循 GPL 的软件，而不要相信以下如何让 GPL 合规的谣传：动态链接至 GPL 代码或让客户下载 GPL 软件。仅将 LGPL 软件作为动态链接库进行使用。在不修改 API 的前提下使用遵循其它左版许可证的软件。遵循移动 APP 市场的分发规定也许与遵循某些特定的左版许可证有冲突（例如 GPL 或者 LGPL）。

法则七：在咨询律师之前不要贡献或发布开源软件

贡献和发布开源软件可能是公众的福音，但它可能不是您业务上的正确选择。一旦作出贡献或发布，您在软件中拥有的任何知识产权将不大可能构成您公司估值的依据。您的律师可以帮助您更好地理解在专有和开源软件之间如何选择，并对这一重要业务决策提供指导。

法则八：确保您的员工和第三方开发人员遵守这些规则

不管是由于您的员工或第三方承包商造成的开源违规行为，所引起的法律和宣传问题都将砸在您的头上。您可以通过适当的培训和跟踪开源软件来避免这些问题。

法则九：规划未来

初创公司业务模式可以快速变化。SaaS 模式可以快速转变为分布式软件模式。无论您当前的模式是什么，遵守分布式软件的规则将为您转变为分布式软件模式提供更大的灵活性，而无需删除某些开源软件并更改相关功能。

采用这些法则将有助于初创企业利用开源软件的优势，降低您在获取投资或收购时遇到的风险。对您的初创企业感兴趣的第三方想知道您如何应对开源软件问题，确保您做好准备，并能够为他们提供积极和专业的答案。

（题图：Beth Cortez-Neavel on Flickr. Public Domain. Modified by Opensource.com）

作者简介：Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人，为客户提供技术交易和知识产权方面的建议，是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。《最佳律师》（Best Lawyers）将她提名为 2018 年年度 IT 律师。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

转自 http://ift.tt/2xJBFVK

The post 初创企业开源许可证管理九大法则 appeared first on Linuxeden开源社区.

http://ift.tt/2yzP9T4

Gradle 4.2 版本发布，Groovy 构建工具

Linuxeden 开源社区 -- Gradle

Gradle 4.2 已发布，Gradle 是一个基于 Apache Ant 和 Apache Maven 概念的项目自动化构建工具。它使用一种基于 Groovy 的特定领域语言来声明项目设置，而不是传统的 XML。

该版本主要是改善了对构建原生应用的支持，将原生性能场景的构建时间减少了一半以上。

此外，还改进了缓存构建的开销; 由于解包过程的改进，可以将构建缓存中的所有任务输出解析速度提高 20％。另一个显着的性能改进来自于 zipTree 和 tarTree ，现在可以避免冗余树访问。

更多内容请查阅发行说明

下载地址：

转自 http://ift.tt/2yzCTSq

The post Gradle 4.2 版本发布，Groovy 构建工具 appeared first on Linuxeden开源社区.

http://ift.tt/2fG5kdU

2017年9月29日星期五

开源美图 2017 09 30

Linuxeden 开源社区 --

The post 开源美图 2017 09 30 appeared first on Linuxeden开源社区.

http://ift.tt/2yNUfft

苏宁调用链监控系统如何为 818 保驾护航？

Linuxeden 开源社区 --

作者朱健荣

网上商场大促时，快速发现问题并精准定位根因所在是保障活动顺利进行的关键任务。HIRO 调用链监控系统在 818 苏宁发烧节期间为商城系统保驾护航，抗住了压力，这其中的设计经验值得借鉴。

当顾客在苏宁易购下单出现异常时，问题究竟出在会员系统、价格系统、库存系统、支付系统……？技术人员面对复杂的系统构成与系统交互，如果在缺乏有效的监控机制情况下，想准确高效的定位问题是很困难的。

我们可以想象到一般大促保障的场景：系统负责人和技术人员在现场通过拉取业务 / 系统日志进行问题排查，耗费大量工时后才发现根因，仅仅是一条 SQL 语句迟迟没有返回导致。

但究竟是什么原因导致的呢？是网络问题、数据库服务端问题、还是客户端问题？……由于大促保障需要的是 时效性 ，如何能够 快速发现问题并精准定位根因所在 成为关键，因此苏宁云迹调用链监控系统（以下简称 HIRO）应运而生。

调用链监控系统

简介

把用户发起的每次请求生成一个全局 ID（以下统称为 TraceId），通过它们将不同系统采集的日志按照时序和调用逻辑串起来，组成一条条链路，这就是 调用链 。调用链监控系统就是用这种技术来理解系统行为用于分析性能问题的一种工具。

作用

调用链监控系统是基于网络调用日志的分布式跟踪系统，它可以分析网络请求在各个分布式系统之间的调用情况，从而得到处理请求的调用链上的入口 URL、应用、服务的调用关系，从而找到请求处理瓶颈，定位错误异常的根源位置。

同时，业务方也可以在调用链上添加自己的业务埋点日志，使各个系统的网络调用与实际业务内容得到关联。

在实际应用中，每一个请求过来后，会经过多个业务系统并留下足迹，并产生对各种 Cache 或 DB 的访问，但是这些分散的数据对于问题排查，或是流程优化都帮助有限。

对于这么一个跨进程 / 跨线程的场景， 汇总收集 并 分析海量日志 就显得尤为重要。具体要求能够做到：

追踪每个请求的完整调用链路
收集调用链路上每个服务的性能数据
计算性能数据和比对性能指标（SLA）
在出现故障后能精确的给出有问题的链路详情并且精确报警甚至给出解决此故障的一般性方法。

使用场景

应用运行时突然发现执行某一个服务耗时很长，此时希望能够有一种方式定位运行时代码各个部分的耗时，以确定耗时点在什么地方
应用运行时一切正常，绝大部分情况下服务运行都非常顺畅，但有用户反馈，当传入 xxx 参数时，服务响应非常缓慢，此时希望能够有一种方式针对特定的方法入参来观察代码执行情况
一个业务逻辑比较复杂的程序方法，在运行时无法确定具体调用了哪些逻辑以及调用时序，此时希望能够有一种方式详细地展现出方法执行的具体逻辑、时序等

苏宁 HIRO 实现原理

中间件研发中心从 2015 年开始着手研究调用链的相关技术，截至 2017 年 7 月底 HIRO 已经承载了 530 个系统，其中核心系统超过 60 个。

HIRO 能够分析分布式系统的每一次系统调用、消息发送和数据库访问，从而精准发现系统的瓶颈和隐患。目前每天经过 HIRO 分析的链路总量超过亿条，监控日志峰值达 500 万消息 / 秒。

HIRO 有如下特性：

它是基于字节码、日志的分布式跟踪系统
侵入性低，安全稳定
基于大数据分析
安装部署简单，Agent 自动升级
每次请求都生成全局唯一的 TraceId，通过 TraceId 将不同系统采集的日志串在一起，组成调用链
支持对部分 C/C++ 系统场景的调用穿透
支持业界主流的 Java 应用服务器，包括：WildFly、WebSphere Application Server、WebLogic、Tomcat 等
支持多种数据库和缓存，包括：MySQL、Oracle、DB2、Redis 等
支持消息中间件 Kafka，MQ（JMS Base）
支持苏宁内部 RPC 框架（RSF）

架构

HIRO 整体分为四层，从底层到前端分别是：

第一层 ：在各应用服务器上埋点 Agent 并用 Flume 采集所有埋点的日志
第二层 ：用 Spark 对日志进行分析和统计
第三层 ：把计算结果保存在 Elasticsearch 中
第四层 ：前端 Portal 的展示

具体架构如下图所示：

(点击放大图像)

与之相对应的，HIRO 内部共分为三大块，分别是 Agent、Spark 实时计算和 Spark 离线计算。其各部组件如图所示：

(点击放大图像)

埋点和输出日志

在前端请求到达服务器时，应用容器在执行实际业务处理之前，会先执行埋点逻辑。埋点逻辑为这个前端请求分配一个全局唯一的 TraceId，然后把它放在一个调用上下文对象中，该对象会存储在 ThreadLocal 里面。

调用上下文里还有一个 ID 非常重要，在 HIRO 中被称作 RpcId，它用于区分同一个调用链下的 多个网络调用 的发生顺序和嵌套层次关系。

当执行业务处理时需要发起 RPC 调用时，苏宁 RPC 远程服务框架 (以下简称 RSF) 会首先从当前线程 ThreadLocal 上面获取之前 HIRO 设置的调用上下文。

然后，把 RpcId 递增一个序号。在 HIRO 里使用多级序号来表示 RpcId，比如前端刚接到请求之后的 RpcId 是 0，那么它第一次调用 RPC 服务 A 时，会把 RpcId 改成 0.1。之后，调用上下文会作为附件随这次请求一起发送到远程的 RSF 服务器。

RSF 服务端收到这个请求之后，会从请求附件里取出调用上下文，并放到当前线程 ThreadLocal 上面。

如果服务 A 在处理时，需要调用另一个服务，这个时候它会重复之前提到的操作，唯一的差别就是 RpcId 会先改成 0.1.1 再传过去。

服务 A 的逻辑全部处理完毕之后，RSF 在返回响应对象之前，会把这次调用情况以及 TraceId、RpcId 都打印到它的访问日志之中，同时会从 ThreadLocal 清理掉调用上下文。

下图展示的是埋点和生成日志的时序关系：

(点击放大图像)

下图展示的是多个系统间的调用关系：

(点击放大图像)

输出日志时面临如下挑战：

需要减少对业务线程的影响，降低资源消耗
QPS 越高日志产生越快，监控数据就越多

对此，HIRO 的解决方案如下：

异步线程写日志
无锁循环日志，按秒刷新
对日志大小做限制，对调用链做采样，不破坏调用链构成
日志文件按大小滚动，自动清理

收集和存储日志

调用链的日志分散在调用经过的各个服务器上，离线分析需要将同一条链路上的日志汇总在一起。HIRO 用 Flume 去采集全量的日志，经过 Kafka 集群，最终全量存储在 HDFS 中。

汇总和重组链路

由于实时收集的日志上的链路都是分散的、断断续续的，这时需要通过 SparkStreaming 的计算功能，把相同的 TraceId 的链路分拣出来，组装成一条完整的链路。

下面给出了一个典型的调用链图示（由于链路太过庞大只能截取一小部分）：

(点击放大图像)

分析和统计调用链

根据重组后链路中的应用、服务以及相互间关系进行数据建模，将分析出来的数据在应用层面和服务层面上统计出错误数、访问量、最大耗时和平均耗时、依赖度等。

同时利用 Elasticsearch 可以对 DB、Redis、RSF、ESB 做大盘分析，还可以统计出各个应用的报表和对比统计。

下图展示了一条链路分析后统计的数据：

(点击放大图像)

下图展示了 DB 分析的结果：

(点击放大图像)

下图展示了应用数据报表统计的结果

(点击放大图像)

HIRO 应用

问题定位

(点击放大图像)

上图是苏宁生产环境的某一条实际链路。用户收到告警：某个应用访问失败。通过 HIRO，可以清晰地看到该应用当前一条链路的详情，这是因为底层的一个 HTTP 请求返回 404 导致访问失败。

系统分析

HIRO 不仅仅是用来做问题定位，还可以防范问题。如下图所示，HIRO 管理员发现易购上的一条交易耗时较长引起警觉，通过 HIRO 的深入排查 没有发现链路上有问题 。

(点击放大图像)

但是谨慎起见把该耗时数据发给业务方，并提出是否由于配置不当或者当前系统压力过大导致耗时过长的疑问，业务方根据此思路排查系统修改了相关参数后，耗时恢复到正常水平，避免了可能发生的系统故障。

调用还原

当用户怀疑系统的业务流程有问题或者不是用户预想的调用场景，HIRO 也可以派上用场。如下图所示，前台销售系统数据处理有问题，客户怀疑是否是调用流程出错，用 HIRO 查看拓扑后，发现调用少了一层，很快就定位到是哪段代码的 bug 并及时修复。

(点击放大图像)

品质分析

HIRO 可以统计出服务调用的次数，用户能看到应用是否有大量无用调用的情况，从而反向检查代码，提高代码的品质。

如下图所示，Redis 应用性能下降，经过 HIRO 的分析，发现是某个应用短期内频繁访问导致的，经过代码分析，最终找到根本原因：业务逻辑出错了，bug 修复后问题随之解决。

(点击放大图像)

容量评估

如果对同一个前端入口的多条调用链做汇总统计，也就是说，把这个入口 URL 下面的所有调用按照调用链的树形结构全部叠加在一起，就可以得到一个新的树形结构（如下图所示）。这就是入口下面所有依赖的调用路径的情况。

(点击放大图像)

这种分析能力对于复杂的分布式环境调用关系的梳理尤为重要。传统的调用统计日志是按固定时间窗口预先做了统计的日志，上面缺少了链路细节导致没办法对超过两层以上的调用情况进行分析。

例如，后端数据库就无法评估数据库访问是来源于最上层的哪些入口，每个前端系统也无法清楚确定当前入口由于大促活动流量翻倍，会对后端哪些系统造成多大的压力，需要分别准备多少机器。有了 HIRO，这些问题就会迎刃而解。

HIRO 未来规划

HIRO 在苏宁才刚刚起步，但是已经向用户展示了其强大的功能。为了进一步满足用户对 HIRO 的需求，未来 HIRO 将陆续完善和提供如下功能：

进一步优化实时数据的处理机制，使得时延更低，达到真正的实时
完善实时的错误发现及报警机制，进一步提高发现问题的及时性
接入更多的中间件，进一步丰富调用链内容，使调用链更长更完整
借助深度学习算法，充分运用数据挖掘技术把 HIRO 产出的数据价值化，力争在更多维度上提供出有价值的分析数据
提供各种 API 接口，将 HIRO 数据开放出来，方便用户可以构建自己的调用链系统，从而达到对业务监控的效果

作者介绍

朱健荣 ，现任职于苏宁云商 IT 总部。主要负责中心产品推广和技术保障工作。在苏宁，经历了多次 818、双 11 等大促保障工作，深知应用系统的稳定对电商平台的重要性。现正在和研发团队一起建设应用系统监控层整体解决方案，已经落地的产品有服务端和调用链监控、智能告警和决策分析平台等。

转自 http://ift.tt/2yyMusS

The post 苏宁调用链监控系统如何为 818 保驾护航？ appeared first on Linuxeden开源社区.

http://ift.tt/2x3IM9l

一文了解云目录服务

Linuxeden 开源社区 --

作者虞雷

云目录服务，在云计算的领域里并不是一个为人熟知的产品类型，但是在企业应用的场景下，它的价值会凸显出来，甚至会对云服务和 SaaS 提供商带来战略层面的意义。

Cloud Directory Services，云目录服务，在云计算的领域里并不是一个为人熟知的产品类型。对于大多数互联网应用和 SaaS 产品来说，用户的元数据往往被认为是产品的一部分，表面上看起来不容易作为独立的服务层。

然而在企业应用的场景下，云目录服务的价值会凸显出来，甚至会对云服务和 SaaS 提供商带来战略层面的意义。

国际主要的云服务商都在 PaaS 的目录服务方面作出布局以适应各自的业务发展：

微软有 Azure Active Directory
Amazon 在现有的 AWS Directory Service 之外又推出 AWS Cloud Directory 和 AWS Cognito
Google 也有 G Suite Directory Service

相比之下，国内的阿里云和腾讯云等云计算领导者，尽管已经在 PaaS 和 SaaS 上发力，但还没有将目录服务作为主要的中间件产品推出。华为云虽然包含了一个叫做云目录的产品，但它只是一个给研发团队用来登记常用开发工具的用户界面，不是本文要讨论的一般意义的目录服务。

本人结合自己这几年的相关工作经验，在这里和大家简单讨论一点云目录服务的相关话题。

目录服务和云

通俗地讲目录服务是一个 根据索引来查找对象 的服务，最常见的例子是通过姓名或用户名来查找一个用户对象并使用其关联的信息。

这种听起来很常见的数据库查询之所以被专门称为“目录”，主要在于其数据对象的通用性和查找的高重用性。

关于目录服务的现实应用场景，首先来看一个互联网用户登录的问题。

互联网发展初期，用户经常需要到很多网站上去注册账户，在每个网站都要填写用户名、密码、邮箱等等信息。这给用户和网站都带来诸多不便，甚至导致帐号安全问题，而其繁琐步骤常常成为用户放弃注册的原因。

随着互联网发展到一定成熟的阶段，所有参与者都清楚地知道只有拥有用户和数据才可能有竞争力，因此互联网巨头们向开发者提供验证服务来帮助构建自己的生态圈和开发者平台。

随着巨头对社交网络的垄断，基于 OAuth 的第三方用户登录服务越来越成熟和流行，国外有 Facebook、Google＋、MSA；国内有微博、微信、QQ 和支付宝。

在身份验证的基础上，应用程序也能根据自身需要请求获得用户的基本信息，例如昵称和好友列表。这种现代的验证方式极大地帮助了网站开发者，既减少了工作量，又避免了因为注册过程的繁琐而造成的用户流失。

(点击放大图像)

上面提到的身份 (Identity) 验证服务，某种程度上可以看做是一种扁平化了的用户目录服务。在企业应用的背景下，目录服务的功能场景则更加复杂和有意义。

举个例子，一名新员工即将加入一个中等规模的公司，在该员工入职之前，公司的 IT 系统就在目录里创建好了该员工的帐号，并生成了临时密码。

之后人力资源专员将给他分配的员工编号、电话和工位信息也录入到了目录中。该员工的上级领导也在此时将他加入了平时工作所需要的邮件和即时通讯群组中，并且开通了访问共享文档的权限。

该员工入职以后，他所有的电脑和办公自动化软件就可以立即使用，并能迅速查找任何同事的联系方式。

可以想象，如果没有基于 整个组织 的 目录数据 ，而需要他本人手动添加同事的电子邮件或者即时通讯地址的的话，将是效率低下而且容易出错的过程。

假设该员工入职以后需要报销入职的差旅费，于是他使用公司的电脑自动登录到相应的 ERP 系统提交了报销的表格和收据的照片，ERP 系统会将该报销请求以电子邮件的方式发到各级领导处等待批复，并发送通知短信。当报销单被批准后，ERP 系统会发邮件通知该员工。

在这个流程里面 ERP 系统需要获得员工和领导的电子邮件和手机号，而且可能根据组织结构图决定谁需要批复、谁需要收到抄送邮件等。可以看出，对于这样的 ERP 系统，一个可靠的目录服务是该类型软件业务逻辑的基础。

(点击放大图像)

目录服务从广义上讲是一种提供通用对象信息的 数据库服务 ，通常包括用户信息的浏览和查找、身份验证等功能。这种类型数据库一般来说有以下特性：

读请求的访问量极高，但写请求的访问量相对较低，Schema 相对静态
具有层级的树状结构
对象之间有引用或者隶属关系
对象数据有较高的通用性，能够被多种应用程序所使用
强调高可用性（Availability）
通常支持数据同步协议

部分读者可能对微软的 活动目录 Active Directory（以下简称 AD）有所了解，也许还知道早些年一个叫做 MCSE 的微软认证。

AD 是最具有代表性的目录服务，除了支持微软自己的多个服务器或客户端软件之外，也是大量第三方软件的用户平台。

但 AD 是 Windows Server 的一部分，是一套典型的 组织内部 部署的系统，也就是平时说的 on-premises 解决方案，并且对网络拓扑结构和安全模型都有要求，不容易用来支撑来自互联网的外部应用。

随着计算逐渐移到云端，企业 SaaS 应用的发展，验证方式和协议的完全 HTTP 化， 目录服务也顺应需求成为了云计算服务的一部分 。

微软借助其 Office 365 的市场地位，在 Azure 上推出了全托管（fully-managed，即客户完全通过 Internet 访问而无需关心物理服务器的部署）的 Azure AD。

AWS 最初只提供基于 AD 的托管目录服务，后来也推出了完全自主设计的目录服务。

云目录服务促进了 SaaS 产品的开发和市场采用，同时也简化了行业（Line of Business）应用程序的开发和部署。一些面向个人用户的网站和服务在稍加修改后，也可以支持企业用户登录和使用。

对象和纬度

数据类型

理论上目录服务可以支持 任何对象类型 ，但现实情况下 通用的数据类型 才有作为目录服务的价值。常见的数据类型包括：

用户 User
群组 Group（包括角色 Role）
应用程序 App（一般意义上指 OAuth 中的 app）
程序账户 Service Account 和 Security Principal
设备资源 Device（包括会议室、仓库、打印机、工作站、货车、IoT 等）

基于这些基本对象可以实现大量的办公自动化和 ERP 相关的功能，举几个最简单的例子：

基于 OAuth 2.0 和 OpenID Connect 的用户登录和身份验证
组织结构图和通讯录，查询某用户所在的部门以及其上级领导
查询某用户是否是一个群组的成员，从而作出相应的授权（Authorization）决定，给用户访问某一资源的权限

角色

基于目录服务的生态系统通常由以下几方角色组成：

目录服务提供商，通常是云计算平台的提供者
隶属于公司和组织的终端用户
公司和组织的管理员
应用程序
被访问的服务或资源

(点击放大图像)

相比于个人用户的 OAuth 场景，企业目录服务的一大不同点是 管理员 这个角色的加入。在企业环境下，用户本身的操作和授权通常是受管控的，比如管理员可以禁止用户登录某一个应用程序。

价值和战略意义

对于 SaaS 客户

前面提到，目录服务能帮助应用程序简化处理用户和群组的相关逻辑。某些公司因为安全合规要求，要求用户登录时进行 多重身份验证（Multi－Factor Authentication），在输入用户名密码以后还需要手机验证。

这样复杂的验证流程应该由目录服务来统一高效提供，而不是应用程序来实现。计算机和互联网已经发展到相对成熟的阶段，如果把每一个互联网用户都当做是潜在的应用程序用户的话，用户的实体和基本画像是相对稳定的，但应用程序的数量却在爆炸性增长，并且以很快的速度更新换代。

SaaS 的代表产品 Office 365 就将用户和群组的基本信息和具体应用本身分离开来，由 Azure AD（后文简称 AAD）来统一管理。

很多 SaaS 产品中都有群组的概念，但传统的群组都是产品本身的群组，要在产品内部创建和管理。

Office 365 则采用了基于另一种纬度的模式：一个工作群组在 AAD 中创建，而属于该群组的应用程序数据则由各自的程序负责和管理。Exchange 存储电子邮件和日历，SharePoint 存储共享文档，Skype 和 Teams 存储群聊天记录等。

去年 Office 365 中加入了 Teams 作为 Slack 的竞争产品，让 Office 365 的用户免费得到现成的协作工具。

Teams 能够横空出世并且直接获取用户的原因之一就是因为它的用户空间其实已经在 AAD 中创建好了。AAD 也使微软能够很快整合从公司外部收购来的产品。

除了能很好与微软及其合作伙伴的产品协同工作外，AAD 同时也是完全面向第三方应用的，所以能让用户的组织更易于采用其它第三方或者自己 IT 部门开发的 LOB 应用。

从设计和开发的角度来看，类似于 AAD 和 Office 365 这样的架构也对应用程序开发的敏捷性起到了积极作用。各种应用之间有很低的耦合度甚至完全独立，还可以基于某一个应用的 API 进行二次开发，这也和目前比较流行的 微服务 的思想是一致的。

国内的云计算巨头腾讯和阿里，在 SaaS 层都有各自的企业邮箱服务和企业即时通讯工具，例如企业微信、企业 QQ、阿里钉钉等。

未来腾讯和阿里都会开发更多的办公自动化及 ERP 系统，那么这些产品之间的用户及群组的同步和一致性就变得很有意义。

政府市场的 SaaS 应用对于用户和权限的管理有更严格的要求，而这也是腾讯和阿里拓展企业应用市场要解决的问题之一。

对于 PaaS 服务商

上面讨论的是云目录服务对于其客户 SaaS 的意义，那么作为 PaaS 的一部分，提供目录服务的商业价值又何在？

云计算平台都从 IaaS 开始，然后逐步提供上层托管式的 PaaS 服务，同时大部分云计算提供商也借助自己的平台提供一些 SaaS 层面的应用。这三层平台最终要形成一个有机的生态系统，并和各个层的用户和开发者紧密结合。

和互联网社交平台提供用户登录服务类似，企业目录服务是构建整体生态圈的重要支柱，而这也是微软，Amazon 和 Google 在各自平台上都推目录服务的原因。

值得强调的是，企业应用和互联网产品相比，其生态系统的黏性更加重要，因为企业客户往往会选择一家提供商长期合作，而且偏向于采购多个产品。

在全民云计算的时代，食物链上的每一级生产者和消费者在选择依赖对象的时候都会考虑生态系统的长期稳定和发展前景。

作为云计算平台的一部分，身份识别及访问控制管理工具（IAM）也是基于用户、群组和角色等对象的 RBAC 模型，和目录服务有大部分重合的空间。

举个例子，一个互联网公司使用了某个云计算平台来部署和运行自己的系统，公司的每个开发和运维工程师都可能需要登录该云计算平台的 IAM 控制台，这个时候该互联网公司的用户和群组目录与 IAM 中的用户就可能有较大的重合。

如果这个公司的规模相对较大，而且人员流动频繁的话，那么 IAM 用户的管理可能会变成一件繁琐的工作，而且疏忽的情况下甚至可能成为一个安全问题。

传统的观点认为云计算平台是完全面向开发者的，对最终用户是不可见的，但随着云计算的发展和普及，生态系统和功能逐渐丰富完善，一些服务是 PaaS 还是 SaaS 的界定逐渐模糊，甚至可能 SaaS 的用户入口和云计算平台的入口被统一。

企业应用的用户本身就是潜在的云计算平台用户，而搭建目录服务对云计算平台而言就可能上升到战略层面意义。从企业应用的角度来看，云计算提供商的终极目标之一是将所有到公司和组织收录到自己的目录服务中。

PaaS 提供者同时也是提供单点登录（Single Sign-on）最理想的中间经纪人和仲裁者。由 PaaS 托管的验证服务可以比较容易地实现跨应用程序之间或者跨公司组织之间的 SSO。

应用设计

目录服务的存储对象是具有通用性的，并且目录服务都是为读操作而非写操作优化的。这些特性在很大程度上会影响使用云目录服务的应用程序的设计。

假设目录中已经导入了一个组织所有用户的基本信息，那么一些基于用户对象的轻量应用程序数据，是否可以直接存储在目录中？

这样的做法等于直接将数据追加在用户对象上，好像也符合当前 NoSQL 数据模型的思想，但事实上需要谨慎考虑多个因素。

首先应用程序很可能没有权限对目录数据进行写操作，因为目录服务的提供商，或者目录数据的拥有者企业客户，通常情况下都不愿意让第三方应用程序更改用户数据。

其次要考虑数据是不是要求高频率的写操作，高写操作的数据并不适合直接使用目录来存储。另外某些应用程序的最终实际用户集合也许只是整个组织用户集合的一个小子集，那么使用额外的数据库更加合理。

现实当中的大多数应用场景下，应用程序需要使用自己的数据库来存储用户数据，然后在自己的用户对象或者记录中保存目录服务中对象的 ID 作为关联。

尽管应用程序有自己的用户数据库，仍应该将目录服务中的用户信息作为 Single-Source-of-Truth 来构建用户对象的映射。

应用程序可以使用简单的延迟创建（Lazy Provisioning）的方式，在本地数据库中查询不到用户数据时候建立用户映射。对于支持数据同步的目录服务，应用程序也可以选择定期去轮询目录的更新情况，将需要的信息同步到本地数据库。

目录服务的实现

目录服务实际上是一种封装了的数据库服务，其下层实现则需要依赖某种 通用的数据库引擎 。

Azure AD 和 AWS Directory Service 的 后台都是 Active Directory，其下层是微软早期实现的一种叫做 JET 的数据库引擎，而 AWS 新的 Cloud Directory 据猜测可能是用 DynamoDB 实现的。

和上个世纪相比，现如今市面上有很多种开源的数据库引擎可以选择，对实现自有云目录服务来说是个好消息。

目前主流的观点认为 NoSQL 类型的数据库是实现目录服务的较好选择，在 CAP 原则中，高可用性是目录服务的重心，而数据一致性一般来说则是可以适当让步的 。

除了原生数据库所提供的数据读写和查询功能外，现实中还需要引入 缓存机制 来提高性能。

用户登录和获取 token 直接影响用户体验和系统整体吞吐量，整个请求和响应过程必须低延时完成。

分布式系统的缓存总是一个复杂的问题，尽管有像 Redis 这样很成熟的工具，仍需要根据业务逻辑的需求来做一些处理。

当由于安全原因需要立即停用一个用户的账号，或者撤销某个 app 的权限的时候，这种比较敏感的的变动不应当因为缓存数据更新不及时而被延迟。

(点击放大图像)

对于新开发的目录服务，将客户组织信息导入到目录中是一项有挑战性的工作，不仅要在市场和销售方面下足功夫，技术上也要准备好相应的数据迁移工具。

除了支持最基本的 Excel 表格和 CSV 格式之外，还应该提供一些面向主流企业数据库或者企业 AD 的工具。

对于大型企业和组织，向云端迁移不是短时间就能完成的，可能要长期以混合云（Hybrid）的方式运行。在这种情况下，和 on-premises 的数据同步就是一个持续的过程，而云目录服务也应当提供相应的解决方案。

作者介绍

虞雷，Jason Yu，微软 Office 365 Core 部门首席软件工程师，在生态系统项目组负责架构设计和项目协调。

转自 http://ift.tt/2yyD3JZ

The post 一文了解云目录服务 appeared first on Linuxeden开源社区.

http://ift.tt/2x45gXL

订阅：博文 (Atom)