From 11751aaf81f8a836a6478212fdd0c0f56500cbd6 Mon Sep 17 00:00:00 2001 From: songxianjin Date: Tue, 5 Dec 2017 20:53:14 +0800 Subject: [PATCH 1/3] [Chinese-translation] production\productoncode.chinese.md --- sections/production/productoncode.chinese.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 sections/production/productoncode.chinese.md diff --git a/sections/production/productoncode.chinese.md b/sections/production/productoncode.chinese.md new file mode 100644 index 00000000..fdd0a622 --- /dev/null +++ b/sections/production/productoncode.chinese.md @@ -0,0 +1,18 @@ + +生产环境代码准备 + +

+ + +解释 +以下是影响生产维护和稳定性的开发技巧： + + +* 十二因素指南 – 熟悉十二因素 [Twelve factors](https://12factor.net/) +* 无状态-不在特定web服务器上保存本地数据（请参阅独立项目 - “Be Stateless”） +* 大量使用缓存，但不会因缓存不匹配而失败 +* 测试内存-测量内存使用情况和内存泄漏是开发流程的一部分，比如‘memwatch’这类工具可以极大地简化测量内存使用情况和内存泄漏。 +* 命名函数-最小化匿名函数（即内联回调）的用法作为典型内存测评器慧提供每隔方法名的内存占用。 +* 使用CI工具-使用CI工具在发送生产之前检测故障。例如，使用ESLint检测引用错误和未定义的变量。使用-trace-sync-io标识使用同步API的代码（而不是异步版本）。 +* 日志记录-在每个日志语句中希望以JSON格式记录上下文信息，以便像Elastic这样的日志聚合工具能够搜索这些属性（请参阅独立项目 - “使用智能日志提高可见性”）。此外，还包括标识每个请求的transaction-id 并允许关联描述相同事务的行（请参阅独立项目 - “Include Transaction-ID”） +* 错误管理 - 错误处理是Node.JS生产站点的薄弱环节-许多Node进程由于小错误而崩溃,而另一些进程虽然没有奔溃却一直处于错误状态。设置错误处理策略非常重要，请阅读我的【错误处理最佳实践】(http://goldbergyoni.com/checklist-best-practices-of-node-js-error-handling/) \ No newline at end of file From ab7acb1fdad0960314d9c56dbf936f5938ab665e Mon Sep 17 00:00:00 2001 From: songxianjin Date: Mon, 11 Dec 2017 18:30:05 +0800 Subject: [PATCH 2/3] void --- sections/production/productoncode.chinese.md | 18 ------------------ 1 file changed, 18 deletions(-) delete mode 100644 sections/production/productoncode.chinese.md diff --git a/sections/production/productoncode.chinese.md b/sections/production/productoncode.chinese.md deleted file mode 100644 index fdd0a622..00000000 --- a/sections/production/productoncode.chinese.md +++ /dev/null @@ -1,18 +0,0 @@ - -生产环境代码准备 - -

- - -解释 -以下是影响生产维护和稳定性的开发技巧： - - -* 十二因素指南 – 熟悉十二因素 [Twelve factors](https://12factor.net/) -* 无状态-不在特定web服务器上保存本地数据（请参阅独立项目 - “Be Stateless”） -* 大量使用缓存，但不会因缓存不匹配而失败 -* 测试内存-测量内存使用情况和内存泄漏是开发流程的一部分，比如‘memwatch’这类工具可以极大地简化测量内存使用情况和内存泄漏。 -* 命名函数-最小化匿名函数（即内联回调）的用法作为典型内存测评器慧提供每隔方法名的内存占用。 -* 使用CI工具-使用CI工具在发送生产之前检测故障。例如，使用ESLint检测引用错误和未定义的变量。使用-trace-sync-io标识使用同步API的代码（而不是异步版本）。 -* 日志记录-在每个日志语句中希望以JSON格式记录上下文信息，以便像Elastic这样的日志聚合工具能够搜索这些属性（请参阅独立项目 - “使用智能日志提高可见性”）。此外，还包括标识每个请求的transaction-id 并允许关联描述相同事务的行（请参阅独立项目 - “Include Transaction-ID”） -* 错误管理 - 错误处理是Node.JS生产站点的薄弱环节-许多Node进程由于小错误而崩溃,而另一些进程虽然没有奔溃却一直处于错误状态。设置错误处理策略非常重要，请阅读我的【错误处理最佳实践】(http://goldbergyoni.com/checklist-best-practices-of-node-js-error-handling/) \ No newline at end of file From 82723d0d0d48915b8a7b839fa7ce4360f70460bc Mon Sep 17 00:00:00 2001 From: songxianjin Date: Mon, 18 Dec 2017 10:06:15 +0800 Subject: [PATCH 3/3] [chinese-translation]sections\production\monitoring.chinese.md --- sections/production/monitoring.chinese.md | 35 +++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 sections/production/monitoring.chinese.md diff --git a/sections/production/monitoring.chinese.md b/sections/production/monitoring.chinese.md new file mode 100644 index 00000000..71e6d647 --- /dev/null +++ b/sections/production/monitoring.chinese.md @@ -0,0 +1,35 @@ + +监控 +

+解释 +
+基本来说，监控意味着在生产环境中当发生意外时你能够很容易识别。比如，通过电子邮件或Slack获得通知。 +最大的难题是选择既能满足你的需求又不会破坏储库的比较合适的工具集。我建议，首先定义必须监视的一组核心指标，来保证CPU,服务器RAM,Node进程RAM（小于1.4GB），最后一分钟的错误数量，进程重启次数，平均响应时间在正常状态。然后去看看你可能喜欢的一些高级功能，并添加到你的愿望清单。 + +一些高级监控功能的例子：DB分析，跨服务测量（即测量业务事务），前端集成，将原始数据展示给自定义BI客户端，延缓通知等等。 +要实现高级功能需要冗长的设置或购买诸如Datadog，newrelic之类的商业产品。不幸的是，实现基本功能也并不容易，因为一些测量标准是与硬件相关的（CPU），而其他标准是在node进程内（内部错误）因此所有简单的工具都需要一些额外的设置。例如，云供应商监控解决方案（例如[AWS CloudWatch](https://aws.amazon.com/cloudwatch/), [Google StackDriver](https://cloud.google.com/stackdriver/))能立即告诉您硬件度量标准，但不涉及内部应用程序行为。 + +另一方面，基于日志的解决方案（如ElasticSearch）默认缺少硬件视图。解决方案是通过缺少的指标来增加您的选择，例如，流行的选择是将应用程序日志发送到Elastic堆栈并配置一些额外的代理（例如Beat）来共享硬件相关信息以获得完整的图像。 + +

+###监控示例：AWS cloudwatch默认仪表板。很难提取应用内指标 +
+![AWS cloudwatch default dashboard. Hard to extract in-app metrics](/assets/images/monitoring1.png) +

+ +###监控示例：StackDriver默认仪表板。很难提取应用内指标 +
+![StackDriver default dashboard. Hard to extract in-app metrics](/assets/images/monitoring2.jpg) +

+###监控示例：Grafana作为可视化原始数据的UI层 +
+![Grafana as the UI layer that visualizes raw data](/assets/images/monitoring3.png) +

+###其他博客观点 + [Rising Stack]博客: + +> 我们建议您监听所有服务的这些信号： +> 错误率：因为错误是面向用户的，并且会立即影响您的客户。 +> 响应时间：因为延迟会直接影响您的客户和业务。 +> 吞吐量：流量可帮助您了解增加的错误率和延迟的情况。 +> 饱和度：饱和度告诉你你的服务有多满。如果CPU使用率是90％，您的系统可以处理更多的流量吗？