如何在 Node.js 中更优雅地使用 gRPC：grpc-helper
在上一篇的 gRPC 的介绍以及实践 中，而在文末，我简单介绍了给 Node.js 做的 grpc-helper，但是现在，我觉得得用一篇完整的博客来好好介绍，毕竟还是想要给大家用的，以下我会介绍我实现这个工具的过程，以及我的一些实现思路。
在上一篇的 gRPC 的介绍以及实践 中，而在文末，我简单介绍了给 Node.js 做的 grpc-helper，但是现在，我觉得得用一篇完整的博客来好好介绍，毕竟还是想要给大家用的，以下我会介绍我实现这个工具的过程，以及我的一些实现思路。
在两年前，我提到了怎么去做 API 文档，这在这两年来以来效果不错，问题有，只是都不是很大，因为我们内部都已经形成了习惯。
但是，情况开始变化，尤其是在被 CTO 骂了之后。
gRPC 是个通用、高性能的开源 RPC 框架。它可以高效地连接单个或多个数据中心的服务。另外也可以支持可插拔的负载均衡、追踪、健康检查以及认证。最后，它也能应用于分布式计算的最后一公里来连接各种设备、手机应用、浏览器与后端服务。[1]
这里可以留意下最后一句话，这句话的意思是：你可以使用 gRPC 来取代现有的 RESTful 接口。事实上，已经有很多案例这么做了：以关键词『gRPC iOS』或者『gRPC Android』去 Google 一下就会发现很多案例。
首先，从我们最常见的『安全』网站来说。
我们在 Chrome 浏览器中（其它浏览器类似），假如浏览的是 https 开头的网站，会发现开头会是绿色的：『🔒安全』 字样，点击之后，会有个小悬浮窗口就会告诉你『连接是安全的』，浮窗下面会有三个选项：『证书、Cookies、站点设置』，继续点击证书，就会弹出一个窗口，里面大概会提到这个证书所对应的网址、有效期等。
以 GitHub 的为例：
www.github.com
Issued by: DigiCert SHA2 High Assurance Server CA
Expires: Saturday, June 20, 2020 at 20:00:00 China Standard Time
你看到的正是 HTTPS 协议所需要的 SSL 证书。
好了，作为好学的你，现在应该有几个问题了吧，不急，慢慢看。
之所以想写这个，也是时机到了，因为上周看了一眼自己团队管理的服务器数量，不知不觉已经达到一屏幕都放不下的程度了，好还自己当初强制规范团队统一内网域名格式，不然现在真不知道怎么管理。
其实回想起来，管理内部网络还是不够规范的，因为现在还是允许团队直接连接生产环境内网登录机器的，也就是开发与生产环境没有隔离。这么做显然有点不安全，这当然会在之后有足够精力后会去改正（是的，当初如果一开始做好就不会有这事了），现在团队的日常开发真是到了分分钟都离不开内网的程度，贸然实行严格安全制度必然会引起太多不必要的麻烦。
记得小时候，有次自己用手拿了两根铁丝插进插座（别问为什么，我在探索真理……），于是至今仍然记得那种全身酥麻以及恶心的感觉，但是幸好时间不长，两秒之后就停了，然后我家就停电了——对的：空气开关起作用了，我的小命就这么留下来了。
上上周去旅游了，写了篇自己都觉得比较水的文章，这周补上一篇。 :P
近几个月开始将现有的 Node.js 服务重构为 Golang 服务，其实这个计划去年就开始制定，并且在很长一段时间里面都在准备基础：
用了 GitHub Pages 作为博客已经几年了，而 HTML 博客的域名一直用的是默认的 xizhibei.github.io，之所以没有用自定义域名，也就是考虑到 GitHub 自定义域名不支持 HTTPS。而如果一定要使用，则必须在其它进行一些设置，比如配置 CDN，来将 GitHub Pages 当成源站。
话说，在很久以前的程序界，是没有内存垃圾回收这种说法的，大家习惯于被 C 以及 C++ 的内存问题各种花式吊打。
直到有一天，John McCarthy 大神 1959 年在 LISP 中实现了内存垃圾回收，大家才惊奇的地发现：『居然还有这种操作？』。
正如 iPhone 出来之后重新定义了手机，内存垃圾回收的出现无异于重新定义了高级语言。