mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-29 16:46:01 +08:00
[Chinese-translation] asyncerrorhandling.chinese.md, monitoring.chinese.md - add
This commit is contained in:
56
sections/errorhandling/asyncerrorhandling.chinese.md
Normal file
56
sections/errorhandling/asyncerrorhandling.chinese.md
Normal file
@ -0,0 +1,56 @@
|
|||||||
|
# 对于异步的错误处理使用Async-Await或者promise
|
||||||
|
|
||||||
|
|
||||||
|
### 一段解释
|
||||||
|
|
||||||
|
回调不能形成一定规模,是由于对于大多数的程序员来说不熟悉,被迫随处检测错误,让人不快的代码内嵌和难以理解的代码流程。通过使用return和throw来控制程序流程,promise的库比如,BlueBird,async,和Q封装了一种标准的代码风格。具体来说,它们支持最受欢迎的try-catch错误处理风格,它允许主流程代码从在每一个方法中处理错误的方式中释放出来。
|
||||||
|
|
||||||
|
|
||||||
|
### 代码示例 – 使用promise捕获错误
|
||||||
|
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
doWork()
|
||||||
|
.then(doWork)
|
||||||
|
.then(doOtherWork)
|
||||||
|
.then((result) => doWork)
|
||||||
|
.catch((error) => {throw error;})
|
||||||
|
.then(verify);
|
||||||
|
```
|
||||||
|
|
||||||
|
### 代码示例 反模式 – 回调方式的错误处理
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
getData(someParameter, function(err, result){
|
||||||
|
if(err != null)
|
||||||
|
//做一些事情类似于调用给定的回调函数并传递错误
|
||||||
|
getMoreData(a, function(err, result){
|
||||||
|
if(err != null)
|
||||||
|
//做一些事情类似于调用给定的回调函数并传递错误
|
||||||
|
getMoreData(b, function(c){
|
||||||
|
getMoreData(d, function(e){
|
||||||
|
if(err != null)
|
||||||
|
//you get the idea?
|
||||||
|
});
|
||||||
|
});
|
||||||
|
```
|
||||||
|
|
||||||
|
### 博客引用: "We have a problem with promises"
|
||||||
|
摘自博客pouchdb.com
|
||||||
|
|
||||||
|
> ……And in fact, callbacks do something even more sinister: they deprive us of the stack, which is something we usually take for granted in programming languages. Writing code without a stack is a lot like driving a car without a brake pedal: you don’t realize how badly you need it, until you reach for it and it’s not there. The whole point of promises is to give us back the language fundamentals we lost when we went async: return, throw, and the stack. But you have to know how to use promises correctly in order to take advantage of them.
|
||||||
|
|
||||||
|
### 博客引用: "The promises method is much more compact"
|
||||||
|
摘自博客gosquared.com
|
||||||
|
|
||||||
|
> ………The promises method is much more compact, clearer and quicker to write. If an error or exception occurs within any of the ops it is handled by the single .catch() handler. Having this single place to handle all errors means you don’t need to write error checking for each stage of the work.
|
||||||
|
|
||||||
|
### 博客引用: "Promises are native ES6, can be used with generators"
|
||||||
|
摘自博客StrongLoop
|
||||||
|
|
||||||
|
> ….Callbacks have a lousy error-handling story. Promises are better. Marry the built-in error handling in Express with promises and significantly lower the chances of an uncaught exception. Promises are native ES6, can be used with generators, and ES7 proposals like async/await through compilers like Babel
|
||||||
|
|
||||||
|
### Blog Quote: "All those regular flow control constructs you are used to are completely broken"
|
||||||
|
摘自博客Benno’s
|
||||||
|
|
||||||
|
> ……One of the best things about asynchronous, callback based programming is that basically all those regular flow control constructs you are used to are completely broken. However, the one I find most broken is the handling of exceptions. Javascript provides a fairly familiar try…catch construct for dealing with exceptions. The problems with exceptions is that they provide a great way of short-cutting errors up a call stack, but end up being completely useless of the error happens on a different stack…
|
||||||
18
sections/errorhandling/monitoring.chinese.md
Normal file
18
sections/errorhandling/monitoring.chinese.md
Normal file
@ -0,0 +1,18 @@
|
|||||||
|
# 监控
|
||||||
|
|
||||||
|
|
||||||
|
### 一段解释
|
||||||
|
|
||||||
|
> 在最基本的层面上,监控意味着您可以很*容易地识别出在生产环境中发生了什么不好的事情,例如,通过电子邮件或Slack通知。挑战在于选择合适的工具集来满足您的需求而不会破坏您的防护。我建议,从确定核心的指标集开始,这些指标必须被监控以确保一个健康的状态 – CPU,服务器的RAM,node进程RAM(小于1.4gb),在最后一分钟的错误量,重新启动的进程数量,平均响应时间。然后浏览一些你可能喜欢的高级功能并添加到你的愿望清单中。一些豪华的监控功能的例子:数据库分析,跨服务的测量(即测量业务交易),前端整合,暴露原始数据给自定义的BI clients,Slack通知及其他。
|
||||||
|
|
||||||
|
实现高级功能需要冗长的设置或购买商业产品如datadog,NewRelic和相似产品。不幸的是,即使是基本的实现也不像在公园散步那么简单,因为一些度量指标是硬件相关的(CPU),而其他的则在node进程内(内部错误),因此所有直接了当的工具都需要一些额外的设置。例如,云供应商监控解决方案(如AWS CloudWatch,谷歌Stackdriver)将立即告诉你关于硬件度量但对内部应用程序的行为却无可奉告。在另一端,基于日志的解决方案如Elasticsearch默认情况下缺少hardware view。解决方案是用缺少的指标来增加您的选择,例如,一个流行的选择是将应用程序日志发送到Elastic stack,并配置一些额外的代理(如Beat)来共享与硬件相关的信息以获得完整的画面。
|
||||||
|
|
||||||
|
### 博客引用: "我们对于promise有一个问题"
|
||||||
|
摘自博客 pouchdb.com, 对于关键字“node promises”,排名11
|
||||||
|
|
||||||
|
> … 我们建议您为所有服务检测这些信号:
|
||||||
|
错误率:因为错误是面向用户的,并且会立即影响您的客户。
|
||||||
|
响应时间:因为延迟直接影响您的客户和业务。
|
||||||
|
吞吐量:流量有助于您了解错误率增加和延迟的上下文。
|
||||||
|
饱和度:它告诉您的服务负载多少。如果CPU使用率是90%,你的系统能处理更多的流量吗?
|
||||||
|
…
|
||||||
Reference in New Issue
Block a user