介绍

在完成了界面的实现后，接下来可以开始进行和云开发相关的数据对接。完成数据对接后，应用基础就打好了，接下来的就是发布上线以及一些小的功能的加入。

配置

在进行相关的配置调用的时候，你需要先登录腾讯云控制台，进行一些配置。使用你的小程序账号登录腾讯云，并在其中找到“云开发”产品。进入到“产品控制台”。

在“产品控制台”中找到你的环境，点击进入“详情页”：

在环境“详情页面”选择“用户管理”->“登录设置”->“匿名登录”：

启用匿名登录。

云开发的数据查询目前必须登录后才可以查询，因为希望给用户提供的是免登录的解决方案，因此，必须开通匿名登录，确保可以进行数据查询。

由于需要在网页中调用相应的函数，因此，也需要在同一个页面的 WEB 安全域名中添加应用的上线域名（本地调试用的 localhost 无需添加）。

为应用程序添加匿名登录的逻辑

此部分代码位置：https://github.com/LCTT/tldr.linux.cn/blob/master/src/main.js

由于希望用户可以打开网页就可以查询数据，因此，必须在用户无感的情况下，完成匿名登录逻辑。

根据对 Vue 生命周期的预研，将相应的逻辑放在了 beforeCreate 中，确保在应用初始化完成后，就可以自动完成匿名登录。

具体实现代码如下：

// main.js
new Vue({
  router,
  vuetify,
  render: h => h(App),
  beforeCreate: function(){                   // 新增匿名登陆逻辑
        const auth = this.$tcb.auth();        // 新增匿名登陆逻辑
        auth.signInAnonymously();             // 新增匿名登陆逻辑
  }                                           // 新增匿名登陆逻辑
}).$mount('#app')

加入完成后，你可以使用云开发的数据库等命令，来完成相应的数据库调用，验证自己的调用是否正常。

在这里需要注意，由于 Vue 默认的 ESLint 规则限制，默认是无法在 Vue 项目代码中使用 console.log 的，你需要使用一些命令来跳过相应的检查 只需要在你需要打印变量的前一行加入 // eslint-disable-next-line 就可以避免对应的检查了。

调用数据

此部分代码位置：https://github.com/LCTT/tldr.linux.cn/blob/master/src/views/Result.vue

完成初始化后，就需要完成相应的数据调用，这里不再针对每一个进行讲解，选择一个例子来说明。

const db = this.$tcb.database();
const cmd = db.collection('command');
if(this.id){ // 这里的 id 是 props 传入的参数，为命令对应的 doc id
    cmd.doc(this.id).get().then(res => {
      this.command = res.data
    })
    }else{
    cmd.where({
      name: this.$route.params.cmd // 命令可以从 Route 中获取，但实际场景下，因为开启了 `props: true`，也可以直接从 props 中获取。
    }).limit(1).get().then(res => {
      this.command = res.data[0]
    }).catch((err) => {
      alert("命令查询出错，请联系我们")
      // eslint-disable-next-line
      console.error(err)
    })
}

在这段代码中，首先是前期挂载的 $tcb 中抽取 database() 对象，并基于 database() 对象构建 collection() 对象。 然后就是使用 collection() 对象进行查询。

由于这里涉及到不同的页面逻辑，使用了一个 if 来判断数据。上下两种分别是获取单个数据和使用多个数据的方法。获取到数据以后，将数据更新，同步到 Vue 的 Data 中，完成相应的逻辑的调用。

云开发登录的坑

此部分代码位置：https://github.com/LCTT/tldr.linux.cn/blob/master/src/main.js

由于为用户提供的是快速查询功能，因此希望用户无论何时都是无感进行查询的。但实际测试的时候，发现用户如果直接通过命令行登录的时候，会导致报错。根据控制台返回的信息来看，是用户登录状态尚未完成，就进行了数据查询。

通过查询云开发的文档，发现云开发的 auth 对象在登录的时候，可以传入一个 persistence 参数来控制身份信息的持久化。

由于默认使用的是会话 ，所以导致用户的登录态丢失。为了确保应用的状态正常进行，将 persistence 设置为 local，确保应用在一次登录后可以将用户登录状态下放到用户的存储 中，这样可以避免用户总是会遭遇请求失败的问题。

// main.js
new Vue({
  router,
  vuetify,
  render: h => h(App),
  beforeCreate: async function(){
        const auth = this.$tcb.auth({ persistence: 'local' });
        await auth.signInAnonymously();
  }
}).$mount('#app')

总结

在实际开发中，如果你需要通过云开发的 Web SDK 调用相应的数据，则需要先行开启云开发的匿名登录并配置 Web 安全域名；在数据调用的部分和在小程序端调用云开发没有太大的区别；并通过设置 presistence 设置搞定了登录状态丢失的问题。

为了解决微信公众号文章内不能嵌入外部链接的问题，我们之前开发了一个小程序“文章助手”，用于通过微信小程序在微信文章内提供访问外部链接的最佳体验。

一般而言，公众号内是无法放超链接的。这对于一般的文章来说其实不要紧，但是对于我们这种技术类的文章，往往会带有很多链接，而不能插入链接，会导致一篇文章的价值和可信性降低。

这个小程序发布之后，除了在我们的公众号内进行了使用，而且也得到很多公众号的支持。就在刚才，我再次查看这个小程序时，发现其首页显示的累计服务次数已经超过了 10 万。

关于这个小程序如何使用，请查看它的介绍和这个小程序的辅助工具介绍。最近宅在家，欢迎大家对这个小程序提提改进意见，我估计有时间实现~

顺便提一句，我们还开发了几个小程序，欢迎大家使用：

• 文章助手：提供微信公众号文章内的外链访问
• Linux文章：Linux中国官网文章访问
• Linux：Linux 命令速查（TLDR）

有一些命令可以用来检查 Linux 系统中的内存使用情况，下面是一些更好的命令。

有许多工具可以查看 Linux 系统中的内存使用情况。一些命令被广泛使用，比如 free、ps。而另一些命令允许通过多种方式展示系统的性能统计信息，比如 top。在这篇文章中，我们将介绍一些命令以帮助你确定当前占用着最多内存资源的用户或者进程。

下面是一些按照进程查看内存使用情况的命令：

按照进程查看内存使用情况

使用 top

top 是最好的查看内存使用情况的命令之一。为了查看哪个进程使用着最多的内存，一个简单的办法就是启动 top，然后按下 shift+m，这样便可以查看按照内存占用百分比从高到底排列的进程。当你按下了 shift+m ，你的 top 应该会得到类似于下面这样的输出结果：

$top
top - 09:39:34 up 5 days, 3 min,  3 users,  load average: 4.77, 4.43, 3.72
Tasks: 251 total,   3 running, 247 sleeping,   1 stopped,   0 zombie
%Cpu(s): 50.6 us, 35.9 sy,  0.0 ni, 13.4 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   5944.4 total,    128.9 free,   2509.3 used,   3306.2 buff/cache
MiB Swap:   2048.0 total,   2045.7 free,      2.2 used.   3053.5 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  400 nemo      20   0 3309580 550188 168372 S   0.3   9.0   1:33.27 Web Content
32469 nemo      20   0 3492840 447372 163296 S   7.3   7.3   3:55.60 firefox
32542 nemo      20   0 2845732 433388 140984 S   6.0   7.1   4:11.16 Web Content
  342 nemo      20   0 2848520 352288 118972 S  10.3   5.8   4:04.89 Web Content
 2389 nemo      20   0 1774412 236700  90044 S  39.7   3.9   9:32.64 vlc
29527 nemo      20   0 2735792 225980  84744 S   9.6   3.7   3:02.35 gnome-shell
30497 nemo      30  10 1088476 159636  88884 S   0.0   2.6   0:11.99 update-manager
30058 nemo      20   0 1089464 140952  33128 S   0.0   2.3   0:04.58 gnome-software
32533 nemo      20   0 2389088 104712  79544 S   0.0   1.7   0:01.43 WebExtensions
 2256 nemo      20   0 1217884 103424  31304 T   0.0   1.7   0:00.28 vlc
 1713 nemo      20   0 2374396  79588  61452 S   0.0   1.3   0:00.49 Web Content
29306 nemo      20   0  389668  74376  54340 S   2.3   1.2   0:57.25 Xorg
32739 nemo      20   0  289528  58900  34480 S   1.0   1.0   1:04.08 RDD Process
29732 nemo      20   0  789196  57724  42428 S   0.0   0.9   0:00.38 evolution-alarm
 2373 root      20   0  150408  57000   9924 S   0.3   0.9  10:15.35 nessusd

注意 %MEM 排序。列表的大小取决于你的窗口大小，但是占据着最多的内存的进程将会显示在列表的顶端。

使用 ps

ps 命令中的一列用来展示每个进程的内存使用情况。为了展示和查看哪个进程使用着最多的内存，你可以将 ps 命令的结果传递给 sort 命令。下面是一个有用的示例：

$ ps aux | sort -rnk 4 | head -5
nemo       400  3.4  9.2 3309580 563336 ?      Sl   08:59   1:36 /usr/lib/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 9086 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo     32469  8.2  7.7 3492840 469516 ?      Sl   08:54   4:15 /usr/lib/firefox/firefox -new-window
nemo     32542  8.9  7.6 2875428 462720 ?      Sl   08:55   4:36 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 1 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo       342  9.9  5.9 2854664 363528 ?      Sl   08:59   4:44 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 8763 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo      2389 39.5  3.8 1774412 236116 pts/1  Sl+  09:15  12:21 vlc videos/edge_computing.mp4

在上面的例子中（文中已截断），sort 命令使用了 -r 选项（反转）、-n 选项（数字值）、-k 选项（关键字），使 sort 命令对 ps 命令的结果按照第四列（内存使用情况）中的数字逆序进行排列并输出。如果我们首先显示 ps 命令的标题，那么将会便于查看。

$ ps aux | head -1; ps aux | sort -rnk 4 | head -5
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
nemo       400  3.4  9.2 3309580 563336 ?      Sl   08:59   1:36 /usr/lib/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 9086 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo     32469  8.2  7.7 3492840 469516 ?      Sl   08:54   4:15 /usr/lib/firefox/firefox -new-window
nemo     32542  8.9  7.6 2875428 462720 ?      Sl   08:55   4:36 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 1 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo       342  9.9  5.9 2854664 363528 ?      Sl   08:59   4:44 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 8763 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo      2389 39.5  3.8 1774412 236116 pts/1  Sl+  09:15  12:21 vlc videos/edge_computing.mp4

如果你喜欢这个命令，你可以用下面的命令为他指定一个别名，如果你想一直使用它，不要忘记把该命令添加到你的 ~/.bashrc 文件中。

$ alias mem-by-proc="ps aux | head -1; ps aux | sort -rnk 4"

下面是一些根据用户查看内存使用情况的命令：

按用户查看内存使用情况

使用 top

按照用户检查内存使用情况会更复杂一些，因为你需要找到一种方法把用户所拥有的所有进程统计为单一的内存使用量。

如果你只想查看单个用户进程使用情况，top 命令可以采用与上文中同样的方法进行使用。只需要添加 -U 选项并在其后面指定你要查看的用户名，然后按下 shift+m 便可以按照内存使用有多到少进行查看。

$ top -U nemo
top - 10:16:33 up 5 days, 40 min,  3 users,  load average: 1.91, 1.82, 2.15
Tasks: 253 total,   2 running, 250 sleeping,   1 stopped,   0 zombie
%Cpu(s): 28.5 us, 36.8 sy,  0.0 ni, 34.4 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   5944.4 total,    224.1 free,   2752.9 used,   2967.4 buff/cache
MiB Swap:   2048.0 total,   2042.7 free,      5.2 used.   2812.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  400 nemo      20   0 3315724 623748 165440 S   1.0  10.2   1:48.78 Web Content
32469 nemo      20   0 3629380 607492 161688 S   2.3  10.0   6:06.89 firefox
32542 nemo      20   0 2886700 404980 136648 S   5.6   6.7   6:50.01 Web Content
  342 nemo      20   0 2922248 375784 116096 S  19.5   6.2   8:16.07 Web Content
 2389 nemo      20   0 1762960 234644  87452 S   0.0   3.9  13:57.53 vlc
29527 nemo      20   0 2736924 227260  86092 S   0.0   3.7   4:09.11 gnome-shell
30497 nemo      30  10 1088476 156372  85620 S   0.0   2.6   0:11.99 update-manager
30058 nemo      20   0 1089464 138160  30336 S   0.0   2.3   0:04.62 gnome-software
32533 nemo      20   0 2389088 102532  76808 S   0.0   1.7   0:01.79 WebExtensions

使用 ps

你依旧可以使用 ps 命令通过内存使用情况来排列某个用户的进程。在这个例子中，我们将使用 grep 命令来筛选得到某个用户的所有进程。

$ ps aux | head -1; ps aux | grep ^nemo| sort -rnk 4 | more
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
nemo     32469  7.1 11.5 3724364 701388 ?      Sl   08:54   7:21 /usr/lib/firefox/firefox -new-window
nemo       400  2.0  8.9 3308556 543232 ?      Sl   08:59   2:01 /usr/lib/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 9086 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni/usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo     32542  7.9  7.1 2903084 436196 ?      Sl   08:55   8:07 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 1 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo       342 10.8  7.0 2941056 426484 ?      Rl   08:59  10:45 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 8763 -prefMapSize 210653 -parentBuildID 20200107212822 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 32469 true tab
nemo      2389 16.9  3.8 1762960 234644 pts/1  Sl+  09:15  13:57 vlc videos/edge_computing.mp4
nemo     29527  3.9  3.7 2736924 227448 ?      Ssl  08:50   4:11 /usr/bin/gnome-shell

使用 ps 和其他命令的搭配

如果你想比较某个用户与其他用户内存使用情况将会比较复杂。在这种情况中，创建并排序一个按照用户总的内存使用量是一个不错的方法，但是它需要做一些更多的工作，并涉及到许多命令。在下面的脚本中，我们使用 ps aux | grep -v COMMAND | awk '{print $1}' | sort -u 命令得到了用户列表。其中包含了系统用户比如 syslog。我们对每个任务使用 awk 命令以收集每个用户总的内存使用情况。在最后一步中，我们展示每个用户总的内存使用量（按照从大到小的顺序）。

#!/bin/bash

stats=””
echo "%   user"
echo "============"

# collect the data
for user in `ps aux | grep -v COMMAND | awk '{print $1}' | sort -u`
do
  stats="$stats\n`ps aux | egrep ^$user | awk 'BEGIN{total=0}; \
    {total += $4};END{print total,$1}'`"
done

# sort data numerically (largest first)
echo -e $stats | grep -v ^$ | sort -rn | head

这个脚本的输出可能如下：

$ ./show_user_mem_usage
%   user
============
69.6 nemo
5.8 root
0.5 www-data
0.3 shs
0.2 whoopsie
0.2 systemd+
0.2 colord
0.2 clamav
0 syslog
0 rtkit

在 Linux 有许多方法可以报告内存使用情况。可以通过一些用心设计的工具和命令，来查看并获得某个进程或者用户占用着最多的内存。

via: https://www.networkworld.com/article/3516319/showing-memory-usage-in-linux-by-process-and-user.html

作者：Sandra Henry-Stocker 选题：lujun9972 译者：萌新阿岩 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

工作量分析

在我们进行这部分开发的时候，接下来我们需要进行相应的功能安排和分类。

简单看来，我需要开发 3 个页面：

1. 首页：首页负责用户默认访问。
2. 列表页：列表页面则是在搜索过程中，如果有多个结果，则进入到列表页面。如果有单个结果，则应该进入到详情页面。
3. 结果页：结果页负责显示命令的具体的翻译结果。

根据实际的工作拆分组件的化，我需要有一个 Layout 组件来负责整体的页面的环境渲染。但是，考虑到组件的复用，于是决定将首页的 Title 进行优化，使首页和详情页保持一致。

在新版的布局情况下，我就可以将顶部的的 title 和底部的 Link 放在最外侧的组件中。

创建 Router & Page

在思考情况后，接下来我们来创建 Router 和 Page。首先，删除 views 下的 About.vue（因为这个页面我们不需要）。然后创建 List.vue 和 Result.vue ，用作后续的开发准备。

创建完成后，修改 router/index.js 中的 routes 部分：

const routes = [
  {
    path: '/',
    name: 'home',
    component: () => import(/* webpackChunkName: "home" */ '../views/Home.vue')
  },
  {
    path: '/list/:cmd',
    name: 'list',
    component: () => import(/* webpackChunkName: "list" */ '../views/List.vue')
  },
  {
    path: '/cmd/:cmd',
    name: 'command',
    component: () => import(/* webpackChunkName: "cmd" */ '../views/Result.vue')
  }
]

完成定义后，我们就可以通过形如 https://tldr.linux.cn/list/ls和https://tldr.linux.cn/cmd/ls 这样的方式来访问具体的命令了。

定义页面

接下来需要编写 Home、List 和 Result 这三个页面。由于这三个页面在内容方面没有太多的可以借鉴的点，所以我们更多关注于使用页面中 <script> 的部分。

<template>
  <div class="home">
        <v-text-field
        v-model="cmd"
        @keydown="onKeyDown"
        autofocus
        ></v-text-field>        
  </div>
</template>

<script>
export default {
  name: 'home',
  data:function(){
    return {
      cmd:""
    }
  },
  methods:{
    onKeyDown: function(e)  {
     
    }
  },
  computed:{
    isLoaded:function(){
        return !this.loaded
    }
  }
}
</script>

上述代码是我在三个页面几乎都会使用到的结构，删除其中的一些无用的代码以后，基本上在每个页面都可以看到。这里我重点说一下其中的一些比较特殊的用法。

首先第一个是在 v-text-field 上加入的 @keydown="onKeyDown" 这个绑定，这个绑定将会帮助实现用户点击回车以后，自动触发事件。这样在用户输入完命令后，按下回车就自动执行后续的操作，而不需要再移动鼠标指针去点击按钮启动搜索。

其次，在 v-text-field 上加入了autofocus ，来实现进入页面后，自动为输入框加入focus，从而实现页面加载完成后，用户就可以输入命令。

这样的一些配置，可以让用户的体验做到最好。

除此之外，我还用到了 computed ，来做数据调整，确保我可以控制内容。

一些小的特性的点

使用骨架图来优化体验

由于我们的应用在列表页面和详情页面存在数据的查询时间，为了让应用在加载的时候，不会因为加载中而退出页面，我加入了 v-skeleton-loader 组件，这样用户在数据查询的时候，看骨架图来缓解用户的焦虑。

在组件层面，我配置了 v-if 来做显示的控制，并将 type 设置为 card,article,card,article 来实现多样化的组件加载支持。

 <v-skeleton-loader
    v-if="isLoaded"
    type="card,article,card,article"
    min-height="800"
    ></v-skeleton-loader>

总结

在这一部分中，借助 Vue 的 method 、onkeydown 和 computed 实现了页面基本逻辑的构建。并借助 Vuetify 的一些基础组件来构建页面。

在这一部分，我想告诉大家的更多是在 UI 的部分，我们在做的时候不仅仅需要考虑的是界面，更多还需要考虑在 UX 侧体验的优化，组件库提供给我们的配置项目，可以优化产品体验。

jrnl 可以创建可搜索、带时间戳、可导出、加密的（如果需要）的日常活动日志。在我们的 20 个使用开源提升生产力的系列的第八篇文章中了解更多。

去年，我在 19 天里给你介绍了 19 个新（对你而言）的生产力工具。今年，我换了一种方式：使用你在使用或者还没使用的工具，构建一个使你可以在新一年更加高效的环境。

使用 jrnl 记录日志

在我的公司，许多人会在下班之前在 Slack 上发送一个“一天结束”的状态。在有着许多项目和全球化的团队里，这是一个分享你已完成、未完成以及你需要哪些帮助的一个很好的方式。但有时候我太忙了，以至于我忘了做了什么。这时候就需要记录日志了。

打开一个文本编辑器并在你做一些事的时候添加一行很容易。但是在需要找出你在什么时候做的笔记，或者要快速提取相关的行时会有挑战。幸运的是，jrnl 可以提供帮助。

jrnl 能让你在命令行中快速输入条目、搜索过去的条目并导出为 HTML 和 Markdown 等富文本格式。你可以有多个日志，这意味着你可以将工作条目与私有条目分开。它将条目存储为纯文本，因此即使 jrnl 停止工作，数据也不会丢失。

由于 jrnl 是一个 Python 程序，最简单的安装方法是使用 pip3 install jrnl。这将确保你获得最新和最好的版本。第一次运行它会询问一些问题，接下来就能正常使用。

现在，每当你需要做笔记或记录日志时，只需输入 jrnl <some text>，它将带有时间戳的记录保存到默认文件中。你可以使用 jrnl -on YYYY-MM-DD 搜索特定日期条目，jrnl -from YYYY-MM-DD 搜索在那日期之后的条目，以及用 jrnl -to YYYY-MM-DD 搜索到那日期的条目。搜索词可以与 -and 参数结合使用，允许像 jrnl -from 2019-01-01 -and -to 2019-12-31 这类搜索。

你还可以使用 --edit 标志编辑日志中的条目。开始之前，通过编辑文件 ~/.config/jrnl/jrnl.yaml 来设置默认编辑器。你还可以指定日志使用什么文件、用于标签的特殊字符以及一些其他选项。现在，重要的是设置编辑器。我使用 Vim，jrnl 的文档中有一些使用其他编辑器如 VSCode 和 Sublime Text 的有用提示。

jrnl 还可以加密日志文件。通过设置全局 encrypt 变量，你将告诉 jrnl 加密你定义的所有日志。还可在配置文件中的针对文件设置 encrypt: true 来加密文件。

journals:
  default: ~/journals/journal.txt
  work: ~/journals/work.txt
  private:
    journal: ~/journals/private.txt
    encrypt: true

如果日志尚未加密，系统将提示你输入在对它进行任何操作的密码。日志文件将加密保存在磁盘上，以免受窥探。jrnl 文档 中包含其工作原理、使用哪些加密方式等的更多信息。

日志记录帮助我记住什么时候做了什么事，并在我需要的时候能够找到它。

via: https://opensource.com/article/20/1/python-journal

作者：Kevin Sonney 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

了解分布式跟踪中的主要体系结构决策，以及各部分如何组合在一起。

早在十年前，认真研究过分布式跟踪基本上只有学者和一小部分大型互联网公司中的人。对于任何采用微服务的组织来说，它如今成为一种筹码。其理由是确立的：微服务通常会发生让人意想不到的错误，而分布式跟踪则是描述和诊断那些错误的最好方法。

也就是说，一旦你准备将分布式跟踪集成到你自己的应用程序中，你将很快意识到对于不同的人来说“ 分布式跟踪 Distributed Tracing ”一词意味着不同的事物。此外，跟踪生态系统里挤满了具有相似内容的重叠项目。本文介绍了分布式跟踪系统中四个（可能）独立的功能模块，并描述了它们间将如何协同工作。

分布式跟踪：一种思维模型

大多数用于跟踪的思维模型来源于 Google 的 Dapper 论文。OpenTracing 使用相似的术语，因此，我们从该项目借用了以下术语：

• 跟踪 Trace ：事物在分布式系统运行的过程描述。
• 跨度 Span ：一种命名的定时操作，表示工作流的一部分。跨度可接受键值对标签以及附加到特定跨度实例的细粒度的、带有时间戳的结构化日志。
• 跨度上下文 Span context ：携带分布式事务的跟踪信息，包括当它通过网络或消息总线将服务传递给服务时。跨度上下文包含跟踪标识符、跨度标识符以及跟踪系统所需传播到下游服务的任何其他数据。

如果你想要深入研究这种思维模式的细节，请仔细参照 OpenTracing 技术规范。

四大功能模块

从应用层分布式跟踪系统的观点来看，现代软件系统架构如下图所示：

现代软件系统的组件可分为三类：

• 应用程序和业务逻辑：你的代码。
• 广泛共享库：他人的代码
• 广泛共享服务：他人的基础架构

这三类组件有着不同的需求，驱动着监控应用程序的分布式跟踪系统的设计。最终的设计得到了四个重要的部分：

• 跟踪检测 API A tracing instrumentation API ：修饰应用程序代码
• 线路协议 Wire protocol ：在 RPC 请求中与应用程序数据一同发送的规定
• 数据协议 Data protocol ：将异步信息（带外）发送到你的分析系统的规定
• 分析系统 Analysis system ：用于处理跟踪数据的数据库和交互式用户界面

为了更深入的解释这个概念，我们将深入研究驱动该设计的细节。如果你只需要我的一些建议，请跳转至下方的四大解决方案。

需求，细节和解释

应用程序代码、共享库以及共享式服务在操作上有显著的差别，这种差别严重影响了对其进行检测的请求操作。

检测应用程序代码和业务逻辑

在任何特定的微服务中，由微服务开发者编写的大部分代码是应用程序或者商业逻辑。这部分代码规定了特定区域的操作。通常，它包含任何特殊、独一无二的逻辑判断，这些逻辑判断首先证明了创建新型微服务的合理性。基本上按照定义，该代码通常不会在多个服务中共享或者以其他方式出现。

也即是说你仍需了解它，这也意味着需要以某种方式对它进行检测。一些监控和跟踪分析系统使用 黑盒代理 black-box agents 自动检测代码，另一些系统更想使用显式的白盒检测工具。对于后者，抽象跟踪 API 提供了许多对于微服务的应用程序代码来说更为实用的优势：

• 抽象 API 允许你在不重新编写检测代码的条件下换新的监视工具。你可能想要变更云服务提供商、供应商和监测技术，而一大堆不可移植的检测代码将会为该过程增加有意义的开销和麻烦。
• 事实证明，除了生产监控之外，该工具还有其他有趣的用途。现有的项目使用相同的跟踪工具来驱动测试工具、分布式调试器、“混沌工程”故障注入器和其他元应用程序。
• 但更重要的是，若将应用程序组件提取到共享库中要怎么办呢？由上述内容可得到结论：

检测共享库

在大多数应用程序中出现的实用程序代码（处理网络请求、数据库调用、磁盘写操作、线程、并发管理等）通常情况下是通用的，而非特别应用于某个特定应用程序。这些代码会被打包成库和框架，而后就可以被装载到许多的微服务上并且被部署到多种不同的环境中。

其真正的不同是：对于共享代码，其他人则成为了使用者。大多数用户有不同的依赖关系和操作风格。如果尝试去使用该共享代码，你将会注意到几个常见的问题：

• 你需要一个 API 来编写检测。然而，你的库并不知道你正在使用哪个分析系统。会有多种选择，并且运行在相同应用下的所有库无法做出不兼容的选择。
• 由于这些包封装了所有网络处理代码，因此从请求报头注入和提取跨度上下文的任务往往指向 RPC 库。然而，共享库必须了解到每个应用程序正在使用哪种跟踪协议。
• 最后，你不想强制用户使用相互冲突的依赖项。大多数用户有不同的依赖关系和操作风格。即使他们使用 gRPC，绑定的 gRPC 版本是否相同？因此任何你的库附带用于跟踪的监控 API 必定是免于依赖的。

因此，一个（a）没有依赖关系、（b）与线路协议无关、（c）使用流行的供应商和分析系统的抽象 API 应该是对检测共享库代码的要求。

检测共享式服务

最后，有时整个服务（或微服务集合体）的通用性足以使许多独立的应用程序使用它们。这种共享式服务通常由第三方托管和管理，例如缓存服务器、消息队列以及数据库。

从应用程序开发者的角度来看，理解共享式服务本质上是黑盒子是极其重要的。它不可能将你的应用程序监控注入到共享式服务。恰恰相反，托管服务通常会运行它自己的监控方案。

四个方面的解决方案

因此，抽象的跟踪应用程序接口将会帮助库发出数据并且注入/抽取跨度上下文。标准的线路协议将会帮助黑盒服务相互连接，而标准的数据格式将会帮助分离的分析系统合并其中的数据。让我们来看一下部分有希望解决这些问题的方案。

跟踪 API：OpenTracing 项目

如你所见，我们需要一个跟踪 API 来检测应用程序代码。为了将这种工具扩展到大多数进行跨度上下文注入和提取的共享库中，则必须以某种关键方式对 API 进行抽象。

OpenTracing 项目主要针对解决库开发者的问题，OpenTracing 是一个与供应商无关的跟踪 API，它没有依赖关系，并且迅速得到了许多监控系统的支持。这意味着，如果库附带了内置的本地 OpenTracing 工具，当监控系统在应用程序启动连接时，跟踪将会自动启动。

就个人而言，作为一个已经编写、发布和操作开源软件十多年的人，在 OpenTracing 项目上工作并最终解决这个观察性的难题令我十分满意。

除了 API 之外，OpenTracing 项目还维护了一个不断增长的工具列表，其中一些可以在这里找到。如果你想参与进来，无论是通过提供一个检测插件，对你自己的 OSS 库进行本地测试，或者仅仅只想问个问题，都可以通过 Gitter 向我们打招呼。

线路协议： HTTP 报头 trace-context

为了监控系统能进行互操作，以及减轻从一个监控系统切换为另外一个时带来的迁移问题，需要标准的线路协议来传播跨度上下文。

w3c 分布式跟踪上下文社区小组在努力制定此标准。目前的重点是制定一系列标准的 HTTP 报头。该规范的最新草案可以在此处找到。如果你对此小组有任何的疑问，邮件列表和Gitter 聊天室是很好的解惑地点。

（LCTT 译注：本文原文发表于 2018 年 5 月，可能现在社区已有不同进展）

数据协议 （还未出现！！）

对于黑盒服务，在无法安装跟踪程序或无法与程序进行交互的情况下，需要使用数据协议从系统中导出数据。

目前这种数据格式和协议的开发工作尚处在初级阶段，并且大多在 w3c 分布式跟踪上下文工作组的上下文中进行工作。需要特别关注的是在标准数据模式中定义更高级别的概念，例如 RPC 调用、数据库语句等。这将允许跟踪系统对可用数据类型做出假设。OpenTracing 项目也通过定义一套标准标签集来解决这一事务。该计划是为了使这两项努力结果相互配合。

注意当前有一个中间地带。对于由应用程序开发者操作但不想编译或以其他方式执行代码修改的“网络设备”，动态链接可以帮助避免这种情况。主要的例子就是服务网格和代理，就像 Envoy 或者 NGINX。针对这种情况，可将兼容 OpenTracing 的跟踪器编译为共享对象，然后在运行时动态链接到可执行文件中。目前 C++ OpenTracing API 提供了该选项。而 JAVA 的 OpenTracing 跟踪器解析也在开发中。

这些解决方案适用于支持动态链接，并由应用程序开发者部署的的服务。但从长远来看，标准的数据协议可以更广泛地解决该问题。

分析系统：从跟踪数据中提取有见解的服务

最后不得不提的是，现在有足够多的跟踪监视解决方案。可以在此处找到已知与 OpenTracing 兼容的监控系统列表，但除此之外仍有更多的选择。我更鼓励你研究你的解决方案，同时希望你在比较解决方案时发现本文提供的框架能派上用场。除了根据监控系统的操作特性对其进行评级外（更不用提你是否喜欢 UI 和其功能），确保你考虑到了上述三个重要方面、它们对你的相对重要性以及你感兴趣的跟踪系统如何为它们提供解决方案。

结论

最后，每个部分的重要性在很大程度上取决于你是谁以及正在建立什么样的系统。举个例子，开源库的作者对 OpenTracing API 非常感兴趣，而服务开发者对 trace-context 规范更感兴趣。当有人说一部分比另一部分重要时，他们的意思通常是“一部分对我来说比另一部分重要”。

然而，事实是：分布式跟踪已经成为监控现代系统所必不可少的事物。在为这些系统进行构建模块时，“尽可能解耦”的老方法仍然适用。在构建像分布式监控系统一样的跨系统的系统时，干净地解耦组件是维持灵活性和前向兼容性地最佳方式。

感谢你的阅读！现在当你准备好在你自己的应用程序中实现跟踪服务时，你已有一份指南来了解他们正在谈论哪部分部分以及它们之间如何相互协作。

via: https://opensource.com/article/18/5/distributed-tracing

作者：Ted Young 选题：lujun9972 译者：chenmu-kk 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出