[Chinese-translation] asyncerrorhandling.chinese.md, monitoring.chinese.md - add

This commit is contained in:
matt_jin
2017-12-17 17:03:27 +08:00
parent 2f9fc471c1
commit e5977ab4eb
2 changed files with 74 additions and 0 deletions

View File

@ -0,0 +1,56 @@
# 对于异步的错误处理使用Async-Await或者promise
### 一段解释
回调不能形成一定规模是由于对于大多数的程序员来说不熟悉被迫随处检测错误让人不快的代码内嵌和难以理解的代码流程。通过使用return和throw来控制程序流程promise的库比如BlueBirdasync和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 dont realize how badly you need it, until you reach for it and its 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 dont 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"
摘自博客Bennos
> ……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…

View File

@ -0,0 +1,18 @@
# 监控
### 一段解释
> 在最基本的层面上,监控意味着您可以很*容易地识别出在生产环境中发生了什么不好的事情例如通过电子邮件或Slack通知。挑战在于选择合适的工具集来满足您的需求而不会破坏您的防护。我建议从确定核心的指标集开始这些指标必须被监控以确保一个健康的状态 CPU服务器的RAMnode进程RAM小于1.4gb在最后一分钟的错误量重新启动的进程数量平均响应时间。然后浏览一些你可能喜欢的高级功能并添加到你的愿望清单中。一些豪华的监控功能的例子数据库分析跨服务的测量即测量业务交易前端整合暴露原始数据给自定义的BI clientsSlack通知及其他。
实现高级功能需要冗长的设置或购买商业产品如datadogNewRelic和相似产品。不幸的是即使是基本的实现也不像在公园散步那么简单因为一些度量指标是硬件相关的CPU而其他的则在node进程内内部错误因此所有直接了当的工具都需要一些额外的设置。例如云供应商监控解决方案如AWS CloudWatch谷歌Stackdriver将立即告诉你关于硬件度量但对内部应用程序的行为却无可奉告。在另一端基于日志的解决方案如Elasticsearch默认情况下缺少hardware view。解决方案是用缺少的指标来增加您的选择例如一个流行的选择是将应用程序日志发送到Elastic stack并配置一些额外的代理如Beat来共享与硬件相关的信息以获得完整的画面。
### 博客引用: "我们对于promise有一个问题"
摘自博客 pouchdb.com, 对于关键字“node promises”排名11
> … 我们建议您为所有服务检测这些信号:
错误率:因为错误是面向用户的,并且会立即影响您的客户。
响应时间:因为延迟直接影响您的客户和业务。
吞吐量:流量有助于您了解错误率增加和延迟的上下文。
饱和度它告诉您的服务负载多少。如果CPU使用率是90%,你的系统能处理更多的流量吗?