[Chinese-translation] createmaintenanceendpoint.chinese.md & delegatetoproxy.chinese.md - init.

sections/production/createmaintenanceendpoint.chinese.md

@@ -0,0 +1,37 @@
+# 创建维护端点Create a maintenance endpoint
+
+<br/><br/>
+
+
+### 一段解释
+
+维护端点是一个简单的安全的HTTP API, 它是应用程序代码的一部分, 它的用途是让ops/生产团队用来监视和公开维护功能。例如, 它可以返回进程的head dump (内存快照), 报告是否存在内存泄漏, 甚至允许直接执行 REPL 命令。在常规的 devops 工具 (监视产品、日志等) 无法收集特定类型的信息或您选择不购买/安装此类工具时, 需要使用此端点。黄金法则是使用专业的和外部的工具来监控和维护生产环境, 它们通常都是更加健壮和准确的。这就意味着, 一般的工具可能无法提取特定于node或应用程序的信息 – 例如, 如果您希望在 GC 完成一个周期时生成内存快照 – 很少有 NPM 库会很乐意为您执行这个, 但流行的监控工具很可能会错过这个功能A maintenance endpoint is a plain secured HTTP API that is part of the app code and its purpose is to be used by the ops/production team to monitor and expose maintenance functionality. For example, it can return a head dump (memory snapshot) of the process, report whether there are some memory leaks and even allow to execute REPL commands directly. This endpoint is needed where the conventional devops tools (monitoring products, logs, etc) fails to gather some specific type of information or you choose not to buy/install such tools. The golden rule is using professional and external tools for monitoring and maintaining the production, these are usually more robust and accurate. That said, there are likely to be cases where the generic tools will fail to extract information that is specific to Node or to your app – for example, should you wish to generate a memory snapshot at the moment GC completed a cycle – few NPM libraries will be glad to perform this for you but popular monitoring tools will be likely to miss this functionality
+
+<br/><br/>
+
+
+### Code example: generating a head dump via code
+
+```javascript
+var heapdump = require('heapdump');
+ 
+router.get('/ops/headump', (req, res, next) => {
+    logger.info(`About to generate headump`);
+    heapdump.writeSnapshot(function (err, filename) {
+        console.log('headump file is ready to be sent to the caller', filename);
+        fs.readFile(filename, "utf-8", function (err, data) {
+            res.end(data);
+        });
+    });
+});
+```
+
+<br/><br/>
+
+### Recommended Resources
+
+[Getting your Node.js app production ready (Slides)](http://naugtur.pl/pres3/node2prod)
+
+▶ [Getting your Node.js app production ready (Video)](https://www.youtube.com/watch?v=lUsNne-_VIk)
+
+![Getting your Node.js app production ready](/assets/images/createmaintenanceendpoint1.png "Getting your Node.js app production ready")

sections/production/delegatetoproxy.chinese.md

@@ -0,0 +1,50 @@
+# Delegate anything possible (e.g. static content, gzip) to a reverse proxy
+
+<br/><br/>
+
+
+### One Paragraph Explainer
+
+It’s very tempting to cargo-cult Express and use its rich middleware offering for networking related tasks like serving static files, gzip encoding, throttling requests, SSL termination, etc. This is a performance kill due to its single threaded model which will keep the CPU busy for long periods (Remember, Node’s execution model is optimized for short tasks or async IO related tasks). A better approach is to use a tool that expertise in networking tasks – the most popular are nginx and HAproxy which are also used by the biggest cloud vendors to lighten the incoming load on node.js processes.
+
+<br/><br/>
+
+
+### Code Example – explanation
+
+```javascript
+gzip on;
+#defining gzip compression
+gzip_comp_level 6;
+gzip_vary on;
+upstream myApplication {
+    server 127.0.0.1:3000;
+    server 127.0.0.1:3001;
+    keepalive 64;
+}
+
+#defining web server
+server {
+    listen 80;
+    listen 443 ssl;
+    ssl_certificate /some/location/sillyfacesociety.com.bundle.crt;
+    error_page 502 /errors/502.html;
+    #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/>
+
+### What Other Bloggers Say
+
+* From the blog [Mubaloo](http://mubaloo.com/best-practices-deploying-node-js-applications):
+> …It’s very easy to fall into this trap – You see a package like Express and think “Awesome! Let’s get started” – you code away and you’ve got an application that does what you want. This is excellent and, to be honest, you’ve won a lot of the battle. However, you will lose the war if you upload your app to a server and have it listen on your HTTP port, because you’ve forgotten a very crucial thing: Node is not a web server. **As soon as any volume of traffic starts to hit your application, you’ll notice that things start to go wrong: connections are dropped, assets stop being served or, at the very worst, your server crashes. What you’re doing is attempting to have Node deal with all of the complicated things that a proven web server does really well. Why reinvent the wheel?**
+> **This is just for one request, for one image and bearing in mind this is memory that your application could be using for important stuff like reading a database or handling complicated logic; why would you cripple your application for the sake of convenience?**
+
+
+* From the blog [Argteam](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+> Although express.js has built in static file handling through some connect middleware, you should never use it. **Nginx can do a much better job of handling static files and can prevent requests for non-dynamic content from clogging our node processes**…