通常，系统环境分为生产、测试和开发等多套，测试又可能因为验证不同的业务版本、BUG 部署 N 套， 意味着每套环境都会有一整套系统，从入口网关到大量的微服务节点，还有数据库等等。人力上需要有人去维护它们，无论是用于测试数还是系统的运维工作，每多一套系统都需要额外部署和购买大量资源，其中很多服务节点的版本是相同的，这都大大增加了成本。
为了解决这样的问题，我们可以通过网关路由的方式，比如测试环境，所有的应用都部署在一套环境中，通过 HTTP Header 信息将不同的应用通过路由串联起来，大概如下：
Server A V1 -> Server B V1
Server A V2 -> Server B 其它版本
文章中主要是一些概念，简单记录这段时间对 Istio 的学习。
对于全栈来说，学习 Istio 还是很有必要的，在此过程中还要学习 K8s、Docker 等基本的运维知识，那么在设计 BFF 层时候也会考虑到部署、扩容、金丝雀发布等问题，提升程序的健壮性。
在 JavaScript 流行的今天，各种框架层出不穷，无论是学习前端的 3 架马车（React\Vue\Angular）、还是运用后端的 Node.js 框架（Express\Koa\Egg.js）等，最后你都会前后端通吃，它们被 JavaScript 这门语言串联在了一起，尤其是当你去翻阅大量前端使用的 CLI 工具源码的时候，几乎都有 Express 的影子，所以在 JavaScript 技术栈里，前后端（这里的后端不是指复杂的后端架构和设计）本身并不分家。当然复杂的后端或前端工作并不适合全栈工程师去做，那也是后话了。
这些年来提出了 BFF 层的概念，根据业务的不同，不同公司有自己的设计和实现，比如将纯前端从 Nginx 移到了 Node.js Server 运行环境、服务端渲染（SSR）、生成或者拼接业务数据返回给前端使用（Node.js 微服务、GraphQL 等）…
自己也做过很长一段时间的全栈，用 Node.js 开发后端业务，把数据吐给前端，不需要等着后端同事返回数据或者来回沟通的烦恼。现在做后端必定会遇到微服务的概念，不同的微服务有自己的 SDK 等工具帮助完成相关的注册发现，大多数情况下它们对 Java 的支持度最好，Node.js 有时候并不友善，要完善你不得不去写一些代码，比如熔断、报警等等，也是带来大量的开发测试成本。如果不幸公司内部 Java 组选择了不支持 Node.js 的架构，那么简直是灾难。
微服务的 SDK 基本上和网络通讯相关，下文的网络化可以解决这个问题。
Node.js 创建子进程的方法常用的有如下几种：
child_process
command，并缓冲任何产生的输出，最大缓存 1024*1024 个字节。exec，但默认情况下不会衍生 shell。 相反，指定的可执行文件file 会作为新进程直接地衍生，使其比exec 稍微更高效。和exec一样，它也有最大 1024*1204 个字节的显示缓存。spawn的一个特例，专门用于衍生新的 Node.js 进程。 与spawn一样返回ChildProcess对象。 返回的ChildProcess将会内置一个额外的通信通道，允许消息在父进程和子进程之间来回传递。cluster
之前写了一篇收集 Node.js 应用的内存堆栈快照和 CPU 火焰图文章，其中的架构非常粗糙，但是初步算是满足了现在的监控需求。不过随着业务的增长，单台TCP Server可定无法满足高可用的需求，一旦出现问题那就没办法持续使用了，所以需要一个重新设计和改造。
Update your browser to view this website correctly. Update my browser now