[Chinese-translation]apmproducts.chinese.md, detectvulnerabilities.chinese.md and frontendout.chinese.md - add.

sections/production/apmproducts.chinese.md

@@ -0,0 +1,26 @@
+# 使用 APM 产品确保用户体验
+
+<br/><br/>
+
+
+### 一段解释
+
+APM, 应用程序性能监视指的是一个产品系列, 目的是从端到端，也从客户的角度监控应用程序的性能。虽然传统的监控解决方案侧重于异常和独立的技术指标 (例如错误跟踪、检测慢速服务器端点等), 在现实世界中, 我们的应用程序可能会在没有任何代码异常的情况下让用户使用起来感到失望, 例如, 如果某些中间件服务执行得非常慢。APM 产品从端到端检测用户体验, 例如, 给定一个包含前端 UI 和多个分布式服务的系统 – 一些 APM 产品可以告诉您, 一个跨过多个层的事务的速度有多快。它可以判断用户体验是否可靠, 并指出问题所在。这种诱人的产品通常有一个相对较高的价格标签, 因此, 对于需要超越一般的监测的，大规模的和复杂的产品, 它们是值得推荐的。
+
+<br/><br/>
+
+
+### APM 示例 – 一种可视化跨服务应用性能的商业产品
+![APM example](/assets/images/apm1.png "APM example")
+
+<br/><br/>
+
+### APM 示例 – 一种强调用户体验评分的商业产品
+
+![APM example](/assets/images/apm2.png "APM example")
+
+<br/><br/>
+
+### APM 示例 – 一种突出显示慢速代码路径的商业产品
+
+![APM example](/assets/images/apm3.png "APM example")

sections/production/detectvulnerabilities.chinese.md

@@ -0,0 +1,17 @@
+# 使用工具自动检测有漏洞的依赖项
+
+<br/><br/>
+
+### 一段解释
+
+现代node应用有数十个, 有时是数以百计的依赖。如果您使用的任何依赖项存在已知的安全漏洞, 您的应用也很容易受到攻击。
+下列工具自动检查依赖项中的已知安全漏洞:
+[nsp](https://www.npmjs.com/package/nsp) - Node 安全工程
+[snyk](https://snyk.io/) - 持续查找和修复依赖中的漏洞
+
+<br/><br/>
+
+### 其他博主说什么
+摘自博客 [StrongLoop](https://strongloop.com/strongblog/best-practices-for-express-in-production-part-one-security/) :
+
+> ...被用来管理您应用的依赖是强大且方便的。但是, 您使用的依赖包可能存在严重的安全漏洞, 也会影响您的应用。您的应用的安全性仅仅与您的依赖组件中的 "最薄弱的一环" 一样严重。幸运的是, 您可以使用两种有用的工具来确保您使用的第三方库: ** 和 requireSafe。这两种工具在很大程度上都是一样的, 所以使用两种方法都可能过于夸张, 但 "安全比抱歉" 更安全...

sections/production/frontendout.chinese.md

@@ -0,0 +1,41 @@
+# 在node外处理您的前端资产
+
+<br/><br/>
+
+
+### 一段解释
+
+在一个经典的 web 应用中，后端返回前端资源/图片给浏览器, 在node的世界，一个非常常见的方法是使用 Express 静态中间件, 以数据流的形式把静态文件返回到客户端。但是, node并不是一个典型的 web应用, 因为它使用单个线程，对于同时服务多个文件，未经过任何优化。相反, 考虑使用反向代理、云存储或 CDN (例如Nginx, AWS S3, Azure Blob 存储等), 对于这项任务, 它们做了很多优化，并获得更好的吞吐量。例如, 像 nginx 这样的专业中间件在文件系统和网卡之间的直接挂钩, 并使用多线程方法来减少多个请求之间的干预。
+
+您的最佳解决方案可能是以下形式之一:
+1. 反向代理 – 您的静态文件将位于您的node应用的旁边, 只有对静态文件文件夹的请求才会由位于您的node应用前面的代理 (如 nginx) 提供服务。使用这种方法, 您的node应用负责部署静态文件, 而不是为它们提供服务。你的前端的同事会喜欢这种方法, 因为它可以防止 cross-origin-requests 的前端请求。
+2. 云存储 – 您的静态文件将不会是您的node应用内容的一部分, 否则他们将被上传到服务, 如 AWS S3, Azure BlobStorage, 或其他类似的服务, 这些服务为这个任务而生。使用这种方法, 您的node应用即不负责部署静态文件, 也不为它们服务, 因此, 在node和前端资源之间完全解耦, 这是由不同的团队处理。
+
+<br/><br/>
+
+
+### 代码示例: 对于静态文件，典型的nginx配置
+
+```javascript
+gzip on;
+#defining gzip compression
+keepalive 64;
+}#defining web server
+server {
+listen 80;
+listen 443 ssl;#handling static content
+location ~ ^/(images/|img/|javascript/|js/|css/|stylesheets/|flash/|media/|static/|robots.txt|humans.txt|favicon.ico) {
+root /usr/local/silly_face_society/node/public;
+access_log off;
+expires max;
+}
+```
+
+<br/><br/>
+
+### 其它博主说了什么
+摘自博客 [StrongLoop](https://strongloop.com/strongblog/best-practices-for-express-in-production-part-two-performance-and-reliability/):
+
+>…开发模式下, 您可以使用 [res.sendFile()](http://expressjs.com/4x/api.html#res.sendFile) 服务静态文件. 但是不要在生产中这样做, 因为这个函数为了每个文件请求，必须从文件系统中读取, 因此它会遇到很大的延迟, 并影响应用程序的整体性能。请注意, res.sendFile() 没有用系统调用 sendFile 实现, 这将使它更高效。相反, 使用serve-static中间件 (或类似的东西), 在express应用中服务文件，这是优化了的。更佳的选择是使用反向代理来服务静态文件; 有关详细信息, 请参阅使用反向代理…
+
+<br/><br/>